Rif.: DAQ acquisition

[fra009]

Hi everyone,

I am using a 9188 cDAQ and I'm acquiring more signals at different rate using DAQmx functions. I would like to get the measurements synchronized and be able to create an XY graph with correlated signals in order to know what was the value of one measurement when another one is at a certain value. I don't really know how to do that synchronization; for now I'm using a while loop for every signal to read an array of different lenght, couse I don't want to stress the PC with a buffer too wide. I thought I could write also timestamp in the acquisition, and use interpolate function to set a signal based on other signal's time, but then I don't know how to correlate them at last.

Does anyone know how can I do that?

Thank you very much for your attention.

Best regards 

Francesca

[Mlandi]

Hi Francesca,

to perform syncronized acquisitions on multiple cSeries modules you need basically to use a common timebase and a start trigger. In this way you will be able to perform an HW syncronization.

My suggestion is to read the following documents, instead of using timestamps that have less precision being a software syncronization.

http://www.ni.com/product-documentation/4322/en/

http://www.ni.com/tutorial/5376/en/

You will also find some examples of DAQ syncornization at the following path:

C:\Program Files (x86)\National Instruments\LabVIEW 2015\examples\DAQmx\Synchronization

Regards 

[fra009]

Hi Mlandi,

Thank you very much for your reply but I don't think that those examples could help me, maybe I didn't explain very well my situation: I'm acquiring an analog channel at a costant rate and a digital channel at variable rate with implicit mode (that stands that the rate depends on the input signal's rate), but in your examples channels are acquired at the same rate. At the end I would like to create an XY graph that correlates both channels, in X the digital one and in Y the analog one. Sorry if my first explanation was not so clear.

Best regards

Francesca

[Kevin_Price]

I'd venture to say you're probably closer than you think.  Thoughts on correlating a constant rate acquisition to one with a variable rate:

1. You need to establish a common reference time point for both tasks.  Most commonly this would be a start trigger signal.  Note however that for counter *input* tasks, you'll need to use a special "Arm Start" Trigger rather than the standard Start Trigger.  In LabVIEW, you need to access it through a DAQmx Trigger property node.

2. You need to calculate time for your variable rate task by summing up the time intervals implicit in the intervals you're measuring.  You need a continuous record for summing so even if you're only interested in pulse widths, you should measure semi-periods to create a continuous time record.  The pulse widths you care about will be every other value of the measurement data.

3.  You can put both sets of data on the same XY graph once you've produced separate time arrays for the two data sets.

-Kevin P

[fra009]

Hi Kevin, thank you for your advice; I've another questions now:

What should be the source of the trigger?

However I would like to create the XY graph offline in a TDMS Viewer, so how can I do that if each couple of elements of both arrays that I've saved were taken at different moments? I supposed to do an interpolation but they also have a different array size couse I'm reading them in two separate while loop and with different input of number of samples. Maybe I'm reading in a wrong way, but I decided to do that in order to avoid an overload of the Host PC. Do you think there's another solution?

Thank you very much in advance.

Best regards

Francesca

[Kevin_Price]

1. Trigger source - On desktop multifunction boards, I like to use a DO line that doubles as a PFI line.  My acquisition tasks are configured to be triggered by the PFI line, but I can also create the pulse myself with a simple DO task.  This way I don't need any physical wiring.  I'm less familiar with cDAQ, but would look for a similar ability.  Worst case, you just physically wire from a DO to a PFI.

2. You *can* piece together a timestamp array for your implicitly-timed counter measurement which will give your variably-spaced sample times.  In fact, you probably *must* do that to have any chance of overlaying that measurement on an XY graph with another waveform.   You may need to calculate a cumulative running time from your counter measurement in your program so you can store that time data as its own TDMS channel.

Interpolation could be an option too, but you'd have to first generate the variably-spaced time array anyway.  All you'd be doing is turning a usable set of exact measurements into a different-sized usable set of approximate measurements. 

-Kevin P

[fra009]

Hi Kevin,

Thank you very much for your help. I've attached you a VI, if I understood what you mean it should be setted the right way, isn't it? But when I run It I get an error (the screen is also in the zip), could you give a look at that please?

Thank you in advance.

Best regards

Francesca 

[Kevin_Price]

It's a decent start, but I'm afraid you're more than just a couple minor tweaks away from your goal.  I only have time for a few "hit and run" comments now:

1. 1st and foremost: *some* cDAQ modules might support a feature available on X-series desktop boards: constant sampling rate for freq measurement.  Sorry I didn't think of this earlier.  If your module supports this, then you don't need to be stuck with Implicit Timing and can just share the AI Sample Clock between both tasks to get sync.  If not, then continue reading...

2. It appears that you've taken an example program meant for something else and worked to adapt it for your purposes.  That can be a really good idea, but I'm not sure the example you started from was close enough to your needs to be a great starting point.  

   I often advise starting from separate and more minimal example programs for each of the tasks, then adding exactly what's needed to coordinate and sync them.  This lets you test and learn incrementally, which will pay dividends down the road.  

Here, I'd grab 1 example for triggered analog input, 1 example for counter pulse measurement, and 1 example for counter pulse generation (preferably one that lets you change freq on the fly).   Add an arm start trigger to the pulse measurement task and configure it to measure in terms of high and low time.  

3. As you read the pulse measurements, you'll need to accumulate a sum of the intervals being measured to create timestamps for the sample times.  You don't have anything like that in your code, nor is there anything related to TDMS or other file output. Each loop iteration reads a chunk of data and overwrites the previous data -- it isn't being accumulated or preserved anywhere.

   These are among the reasons I say you're farther away from being done than just a few tweaks.

4. The pulse generation task in your code looks overly complicated.  It isn't clear what you're trying to do with it.  I'd dump all of it, and just open a separate pulse generation example program if you're just looking to generate a pulse train that your other counter task can measure.

-Kevin P

[_kb · Accepted solution]

Hello all,

Just to make sure we're not overcomplicating things, I'd like to clarify the objective with OP.

Francesca,

Is time truly relevant for your application? That is, will your x-axis plot time (i.e. in seconds) or simply the number of times the digital signal has gone high?

If you only want to know what the analog signal looks like when you see a digital transition and you don't care how much time passes between each of those transitions, you could just use the digital signal as the sample clock for your analog input.

If you do indeed care about how much time passes between each point on your plot, ignore my post entirely -- Kevin's suggestions are right on.

[Kevin_Price]

I agree with Kyle -- if you don't truly need a time record but only need to see the correlation between AI and Counter input, you can use the signal being measured by the Counter as an external sample clock for your AI task.   And that *would* be a simpler approach.

-Kevin P