Timing of DAQmx Acquisition Vi and data write

Question

I am acquiring data from a DAQ rack, using a 6251 PCI card. after acquiring a data set, i write it to a binary file. afterwards, i do a small calculation on one channel value and apply a condition on this value. the outcome of which is connected to the while loop surrounding the acquisition. So i (1.)grab 100 points, (2.) write, calc. and cond., and (3.) start over again. I stuck millisecond timers in between steps 1, 2, and 3 to determine if i was incurring much delay. So, if i have no delay, and i'm sampling at 100 Hz, the differences between the millisecond timing values (stuck into an array) should be
1000
0
0
1000
0
0
1000
0
0
etc.
This is usually the case. However, sometimes i get something like this
900
100
0
900
100
0
or
980
20
0
980
20
0
So if i measure a delay as a result of the writing/calculations/conditing, this time is subtracted from the acquisition time interval. I don't really understand this at all. Why a delay after the acquisition would speed up the acquisition, i have no idea. My only guess is that i start writing/calculating/conditioning before acquision has finished, but why would it do that? I've attached basically the setup. Any help would be great.
Attachments:
Concept.vi ‏61 KB

Answer 1

...what is the "hw?"
That's short for "hardware." Specificially, in a buffered acquisition the data is sent into your memory buffer at regular times regulated by a hardware clock found in your data acq board. Your software interacts with this memory buffer via 'Read' calls.
...worry about delay?
That'll depend on your app. As you've described it, you Read 1 second worth of data all at once then do some processing and storage. As long as you can do that processing and get back around the loop in less than one second, then the processing is not a bottleneck. The speed is being regulated by the amount of data you request and the time it takes to acquire it.
If this behavior is sufficient for you, then no, you don't have to worry about the delay.
Other apps may need to read smaller amounts of data and make decisions more quickly than once per second. Or they may need to instantly read the most recent data without waiting for any and then quickly make a decision. These sorts of apps might cause you to worry about the processing time.
-Kevin P.