Sync AI and Period measurement

[Eyal S.]

Hi, I'm using an external clock for voltage measurements and at the same time I'm measuring the period measurement of the external clock. In other words I'm trying to get a time stamp every time I make a voltage measurement with an external clock.I've attached the code.I'm using one counter to filter high frequency bursts and than using the internal output of that counter as an external clock for the voltage measurements. I also connected the output of the same counter physically to a second counter used for period measurements.The Voltage measurements and the period measurements are supposed to be synchronized but the buffer size at the end of the measurements is sometimes the same and sometimes the period measurements buffer is bigger by one. The buffer size should always be the same but for some reason is not. I have no idea why that is happening. If someone can help me figure out what is going on that would be great.Thank you,Eyal


Sync_AI_Period.vi:
http://forums.ni.com/attachments/ni/250/41504/1/Sync_AI_Period.vi

[Corby_B]

Hello Eyal S. Thanks for your post!I see that you want to get the time stamp of every sample taken from your AI task with the external clock. The best way to do this is to change your DAQmx read to waveform mode. This will "attach" the time component of the signal. So what you can do is then parse the information using the "Get waveform components.vi" from the waveform function palette and that will have a delta T or time component. This will allow you to associate each sample with a time stamp. Let us know if this is what you were looking for. To change the DAQmx read simply select Analog >> Single Channel >> Multiple Samples >> Waveform.Have a great day Eyal S.Cheers!Corby_Bhttp://www.ni.com/support

[Eyal S.]

Hi Corby_B,Thank you for your reply.Unfortunately it doesn't seem like the waveform mode will do the work for time stamping when using a non frequency constant external clock.   My buffer is bigger than 1 and dt is an integer therefore I can't get all the information I need (also in this case I don't even understand what dt is referencing since it does not seem to depend on the external clock ).I think the only solution is to get the time stamps via a different counter which leaves me with the synchronazation problem.If you have any additional thoughts or suggerstions that would be great,Eyal

[Kevin Price]

You're actually *really* close.  You did a good job at sequencing the task starts to make sure both the analog and period tasks were started *before* the retriggerable pulse task (which filters high freq bursts).  Thus, your data acq tasks truly *are* in sync.
The place where you can be off by 1 (or maybe more, depending on sample rate and system speed) is in your calls to DAQmx Read.  Without dataflow dependency, there's no predicting exactly when the two calls happen relative to one another.  In real life, one will be called slightly before the other.  Both calls have the implied request to read all fresh samples because the quantity to read was left unwired.  Whichever Read happens to occur later *may* find an extra sample or two there.
The fix is simple.  Go ahead and continue reading all fresh samples on *ONE* of the tasks.  Then do an array size on the output data and request *that* number of samples from the other task.  This guarantees that you always request the same amount of data from each task on each cycle of the loop.  Your earlier config work already did the hard part of sync'ing up the sample clocks for the tasks, guaranteeing that common index #'s into the arrays represent measurements that are truly simultaneous in real time.
(Alternately, you could simply specify a desired # of samples to read from both tasks.  The downside is that you can no longer control you loop timing this way.  I prefer your way with specified loop timing.  My small tweak will then keep your data lined up.)
I would also specifically advise that you *don't* do Waveform reads.  Since you apparently expect a variable-rate external clock, the "dt" part of a waveform is at best meaningless and at worst very misleading.  Stick with array reads, as you have been doing.
-Kevin P.