DAQ loop timing

[GReaper]

Hello NI folks (and Merry Christmas!),

Yes, it's Christmas Eve and I'm working in LabVIEW.  The therapy sessions start next week. 🙂 

Anywho, I have a DAQ timing issue that has been bugging me and want to get some opinions.
In the attached VI I have two daq loops.  The loop is the stripped down gist of my program. 
I'm reading from some NI hadware (instrumented test subject info) and also from a UDP port
(machine control info).

In the actual program the chart updating is not uniformly smooth.  That got me thinking about
the implied delay time that would be in my DAQ loop.  The top loop uses what I call an
"implied" delay based on the sample rate (currently set to 5 Hz).  The bottom loop uses
an "explicit" delay by reciprocating the sample rate, mult. by 1000 and feed into a
Wait Until Next ms Multiple VI.

So the big question: What will the times be at t1 and t2 in each of these loops for the first
2 or 3 iterations?

Thanks for any help!

Cheers,

[Margaret F.]

Hi Greg,

I hope you get to take some time off soon! 

To provide some insight for your question....

The top loop does not get its timing from the 5 Hz you give the timing function. As of now, the top loop is running as fast as it can and its up to Windows to determine how fast that will be. In DAQmx, a buffer is filled at a rate of 5Hz with the number of samples you determine in "Samples to Read." When the buffer is full, the DAQmx Read in the While loop reads that buffer at a rate of whatever timing is implemented in the loop. In this case there is none, so the loop iterates as quickly as it can.

In the bottom loop, the loop will iterate when the system clock reaches a multiple of the constant you have wired to the Wait Untill Next ms Multiple. 

If you are interested in trying to synchronize the two loops, I would recommend implementing a Wait Until Next ms Multiple in the top loop and giving it the same constant that you are using in the bottom loop.

Hope this helps!

Happy New Year!

[GReaper]

Thanks Margaret.

That does shed some light.  As for synchronizing the two loops, there is really one loop, I was just showing two flavors of the same one.  It sounds like the bottom loop is the critter I need to go with to ensure my data is acquired at the 5 Hz (in this example) rate.

Another permutation of this:  If the 5 Hz rate I specified tells DAQmx how fast to fill the buffer and my buffer is currently 1 sample long, then I could tell DAQmx to acquire at a faster rate and let the Wait Until Next MS Multiple inside that loop ensure each 1 pt. buffer is acquired at my 5 Hz. rate.  Does that make sense?

The big picture here is I want to grab 1 sample from all the specified NI channels as fast as possible, grab the data I need off UDP, merge the two data sets, plot and log.

Cheers,

[Margaret F.]

Hi Greg,

I see what you're saying and I think that is a viable solution. You will have to consider though that since we are working in Windows here, a loop running at 5Hz is variable since Windows is not deterministic like a real-time enviroment would be. The general idea sounds promising though.

Have a great day!

[Vineet_A.]

Hello,

As long as you have enough processor bandwidth to run faster than 5Hz (and you probably do) the DAQmx Read VI should eventually become the slowest thing in the loop.  One option might be to discard data from the first few iterations until the loop time has settled.

One way to monitor how fast your loop is actually going is by adding the tick count function to the bottom of your loop.

Regards,

Vineet A.