Why is the DAQmx Read VI so slow?

Question

Hello everybody.
I'm using Labview 8.5.1. and NI DAQmx 8.6 and I'm wondering what the DAQmx Read VI is actually doing.
What I want to measure is a 1kHz signal. To do this, I'm using a VI similar to the attached one (a pulsed 1kHz signal serves as trigger and as sample clock).
The time the DAQmx Read VI needs to perform is 250ms longer than the acquisition time you would expect (e.g. instead 100ms to measure 100 samples at 1kHz the time is usually around 350ms, for 1000 samples it is ~1250 ms). The time does not depend on the number of channels in the task.
So my question is what actually happens when the DAQmx Read VI is called. What I would like it to do is: Wait for the next trigger signal, then acquire the specified number of samples, then read the samples from the buffers and return them. Is there any way to force this behaviour?
Thanks a lot for your answers, I highly appreciate any help!
Solved!
Go to Solution.
Attachments:
daqmxAcquisitionTime.PNG ‏20 KB

Answer 1

Rene,
For your application and hardware, you should be using DAQmx Control Task.vi to commit your task before your while loop.  Inside the loop, then you'd start/read/stop the task.  DAQmx uses a state machine to control task configuration and run time.  As written, when you cal DAQmx Read, DAQmx will see that you have a task which has never been configured.  As such, it will look at all the settings you make on the task, verify their correctness, reserve all resources necessary, write the configuration to hardware, then start your task.  Once the data specified has been read, it will unwind this state machine to put the task back in an unconfigured state.  As such, every time you call Read, DAQmx if going through all of it's state transitions.  If you were to commit your task before the loop, DAQmx would not re-verify your settings or need to re-program hardware each time through your loop.  That being said, there will still be some addition time each iteration of the loop where you will need to stop and restart your task, and during this time you could miss a trigger.
If it is truly not acceptable for you to miss a trigger, you might consider moving to a design in which you continuously read data, and then use software triggering to  keep track of the relevant sections of data.  One other alternative would be to look at the X Series line of DAQ devices, as these devices support retriggering in hardware (ie... They can retrigger without you needing to stop and restart your task).
Hope that helps,
Dan