DAQmx Tasks in Loops

[Penultimate_Airbender]

I have a simple question. I'm trying to write a channel multiple times using a loop but the program is really slow. The LabVIEW Help for DAQmx Start Task VI says 

"If you do not use the DAQmx VI and the DAQmx Stop VI when you use the ... DAQmx Write VI multiple times, such as in a loop, the task starts and stops repeatedly. Starting and stopping a task repeatedly reduces the performance of the application."

If I read that right, it says NOT using Start and Stop = starting and stopping repeatedly = slow. Is this a typo or am I misunderstanding? 

[JÞB]

You read that correctly! 

Now, I suppose that you want an explanation.   Read THIS! 

What you really want to understand is who the DAQmx State Transition diagram is navigated by explicit commands and how that differs from implied commands.

In either case some things need to happen to the task;

• Verified - the task itself is creatable, the device exists and has some channels
• Reserved- none of the hardware resources needed (Clocks, trigger routes, etc..) are reserved for another task
• Commit- a preflight check, power up ADCs, DACs, make routes, etc...)
• Run, make data move from memory to wires or vice versa
•  

When you call DAQmx Start Task you will go to Run state (or throw an error) making all state transitions implied along the way.  But, when a finite Task completes what state will you transition back to?  DAQmx attempts to transition back to the last explicitly commanded state.  Theterefor, if you call a DAQmx Write.vi instance on a task in the verified state, the task will reserve, commit, run then uncommit and unreserve every loop iteration.  An explicitly committed task will return to the committed state and be flight ready on each loop iteration.   A task that is reserved will perform somewhere in between and a task that is created and cleared in each loop really performs poorly. (Although, a task doesn't actually unreserve via until sometime after Clear Task runs..garbage cleanup adds a little sand in that gear train)

Clear?

[Penultimate_Airbender]

So I should explicitly commit the task before Starting the task and entering the loop to be sure I return to the committed state when using Stop.

In the loop, should I use (Start - Read - Stop) or Start before, Read in the Loop, Stop and Clear after? If I don't Stop in the loop, it won't return to a verified or reserved state right?

[JÞB]

Reads are fairly simple. Lets go through a finite task first. Start starts moving ADC conversations to the read buffer. (As long as trigger conditions are met) Read waits for the number of samples to exist in the buffer then returns those samples and the Task goes back to whatever state . The Start vi isn't really necessary because the Read.vi will auto start the task. So, youwant 1 finite record? Just use the Read.vi. but, let's say you want multiple triggered records, like an Oscilloscope? Configure the task and triggering then commit outside the loop. Read in the loop ( no Start needed) Again let's assume you want a continuous record, like logging a lab temperature to file. Configure and Start outside the loop and Read in the loop ( send the data on a queue to the display and logging loops)

These are exactly how the DAQmx Finite and DAQmx Continuous Measurement and Logging project Templates demonstrate those actions!

So, what do you want your Task to accomplish? There is no 1 answer.