I have a cDAQ chassis with five modules. I have written a large VI to control it and acquire data but the time stamps seemed a bit strange so I have put together a simple VI to examine the problem.
It sets up one channel with 2 Hz sampling rate and displays the time stamps when DAQmx Read returns a waveform.
The task is set to start immediately but the first Read gets no points, even if one waits ?? seconds between task Start and Read.
t0 in "data 2" is 0.5 sec (1 sample) after "Time 1" i.e. the first Read seems to triggered the data acquisition (not the Task Start vi). The time difference between Time 1 and Time 2 is 5 seconds, as one would expect from the Wait(ms) timer.
Increasing Wait_1 to 10 seconds gives 20 samples from the second Read i.e. the first sample should be at 16:50:00.729 - 10 seconds = 16:49:50.729, NOT the 16:49:56.22 timestamp in data 2. It seems to have started acquiring data half-way through the initial 10 second wait.
The difference between the data2 and data 3 timestamps seems OK (10 seconds, for the 20 samples in data2) but I cannot see why the first point in data 3 (t0 = 16:50:06.22) should be later than the time of the Read request, Time 3 = 16:50:05.738. Surely the data in the buffer should start 9 or 10 sample periods before Time 3, rather than 0.48 seconds later?
In my application, a few seconds does not matter much - it is more of an annoyance.
1. Like you, my initial reaction is surprise at the results you show.
2. You haven't identified your specific cDAQ device -- it's possible that the 'data 2' t0 anomaly in your 2nd run is due to an unusually long startup time needed by your device.
I don't know the cDAQ family all that well, but seem to recall some kind of similar slow startup on an older 24-bit NI temperature DAQ board.
3. Here's a real grasping-at-straws thought: is it possible that the error wire that *appears* to be coming out of DAQmx Start might be running *underneath* it? If so, DAQmx Start might be producing an unseen error which isn't passed along, thus requiring the DAQmx Read functions to invoke auto-start?
Not sure how much this would explain. With a continuous task, I wouldn't expect each auto-start to conclude with a an auto-stop (the way it might for a finite task). But I don't honestly know for sure.
4. Try targeting the same code to another module that does general purpose AI, see if you get similar behavior. Again, no specific theory, just looking for clues that might point to this being a module-specific oddity.
Yes, it's quite surprising. The RTD module was an NI 9216; the chassis is the NI cDAQ-9178 (i.e. USB not ethernet). I have wondered if there is a firmware update for the chassis but I couldn't find one (or even any way of telling the current firmware version).
I've checked the diagram wiring - the error wires are properly connected.
If I do the same test with a voltage input module (NI 9220) I see much the same result:
Using the same wait times as before (a) 5000 ms, acquisition appears to start about 4.5 seconds after the DAQmx Start call.
(b) setting 10 sec for Wait 1, the first read still returns nothing but
and t0 for the third read is after the time when Read is called (should be 5 seconds beforehand).
I then read this thread: Start Task VI slow which mentioned the Control Task vi. I added this just before Start Task and tried three settings (verify, reserve, commit) - none made any difference.
FWIW, I got much more expected-looking results running on a desktop PCIe-6341. All the t0 times are offset backwards by an expected amount relative to the simple Time readings.
a) 0 initial wait
Even with 0 wait, I got 1 immediate sample for the 1st read. One thing I noticed that I hadn't ever investigated closely before - the t0 value appeared to subtracted 1 sample interval from the current time. My theory: after task start, the 1st sample clock is issued more or less immediately so there's 1 sample available by the time we get to the Read. Interestingly, DAQmx nevertheless decides to offset the t0 time backwards, basically acting as if the task waited for 1 full sample interval before taking the 1st sample. I haven't previously looked closely at this odd little off-by-1 discrepancy.
b) 5 second initial wait
So I looked up your RTD module and, sure enough, it uses a Delta-Sigma converter which has built-in filtering that *will* induce some delay. I didn't have any luck finding detailed info about this delay from the alleged downloadable "manual", but other Delta-Sigma devices usually have a delay that's mostly dominated by the digital filter stage that delays the data by a fixed # of samples.
It makes sense that such a delay would show up as a startup symptom only -- once the first sample makes it all the way through, all the others will be equally spaced by the sample interval.
Try your 9220 device again and give the results more scrutiny. The 9220 has an SAR style converter without a corresponding built-in filter and delay. I would expect it to behave much more similarly to my desktop board, though I wouldn't be shocked if a 1st Read after 0 wait produces 0 samples. Long story, but I believe that USB devices often don't initiate data transfer unless they have >= some threshold # of bytes to deliver. 1 sample may not be enough.
It might also be instructive to experiment with higher sample rates on your 9216 device. (A higher rate means the fixed # samples delay would get shorter in time.)
Long story, but I believe that USB devices often don't initiate data transfer unless they have >= some threshold # of bytes to deliver. 1 sample may not be enough.
You could play around with the properties Kevin suggested to see if it makes a difference.
Look in the Channel Properties to find them.
Ah! Thank you (both) - I didn't realise there were properties like this that one could tinker with.
I'll have a play with them and see what difference it makes.
Looking at my test with the 10 second delay though, I would still expect some data from the first Read - there should be more than enough samples. More to the point, the TimeStamp is meant to be the time of the first data point in the waveform, not the time when Read is called.
It looks as though this is a bug (as opposed to me doing something wrong).
Agreed that something odd is going on. Not yet sure if it's a bug but not ruling it out either. In the course of your tinkering about, try things like:
- observe what happens in software-timed (aka "on demand") mode with no call to DAQmx Timing
- look for differences in behavior between the two modules mentioned. Delta-Sigma converters will typically induce a delay, and it could be a long one at low sample rates.
- try requesting different *specific* #'s of samples instead of the -1 for "all available"
Having another look at this after a few busy days. My channel properties node doesn't look like yours. I only get:
Maybe my DAQmx version is out of date? Looking in Package manager, it says DAQmx is version 18.5.0 but i think there's a 19.1 now (http://www.ni.com/documentation/en/ni-daqmx/latest/daqmx-prop-ref/daqmx-task/). It doesn't show an update though. Also, I don't know why, it shows Measurement and Automation Explorer 18.5.0 as being installed but I cannot find it in my Start menu....is my installation messed up?
I doubt that DAQmx 18.5 is the problem, I don't think there's any need to install 19.1
I get different "Start Menu" behavior on different systems around here, some of them make it hard to find LabVIEW or MAX in the menus. Most systems here are Win 10 and I just type "labv" or "max" and let Windows point me there.
The last 4 properties you show are all the ones under the last sub-category I see, "General Properties." There are many other channel-specific sub-categories in the list above "General Properties" for Analog, Digital, and Counter channel types. Are you *sure* you don't have those other sub-categories?
Ah - yes, the cDAQ chassis is now on my rig; I was using editing the VI on my desktop PC and it wasn't connected. Having plugged it in, I get: