Retriggerable Tasks in NI-DAQmx using PFI (USB 6001 card)

[titi_nicolas]

The only solution I found was to program myself a software triggering function.

It's not very difficult to do.

But it's a pitty that the card does not support this (very basic and useful) feature.

[Kevin_Price]

One little trick that can help *some* is to make use of the DAQmx Task State model and "commit" the task before you start it.  That'll make subsequent stops and restarts a little bit faster because the stop will only revert back to the committed state the task was in just prior to being told to start.  (The default behavior would have been to revert back to the unreserved state, leaving more overhead on the next start.)

In LabVIEW, you'd call DAQmx Control Task with a "commit" action as the last DAQmx call before your main code where you'd repeatedly start, read, and stop.

-Kevin P

[rbarth]

Have a follow-up question to the DAQmx Task State model approach.  If the start/wait-until-done/stop sequence is inside a loop:

1. Should the DAQmx Control Task with the "commit" action be used outside the loop prior to starting the loop (for me, right after setting the trigger source)?

2. Does the task wire need to be on a shift register?

Thanks!

-Ryan

[BertMcMahan]

1- Yes, commit before you start the task.

2- Probably not, but it's good practice to do so anyway. It's a by-ref wire but there are some corner cases where a shift register saves you, generally in an error situation. (For example: if you're using a For loop instead of a While loop, and the For loop doesn't execute due to upstream errors, a tunnel will output a blank task and you'll lose the reference. A shift register will output whatever is at the input, and you won't lose the reference.)

[rbarth]

Sounds good.  Just wanted to double-check that I wasn't missing anything.

Thanks!

Ryan

[BertMcMahan]

No prob. Just to explain, here's the task state model:

Committing gets you all the way to the "Committed" state on the right. Starting the task from there just shifts to Running. If you go from Create to Run, you have to Verify, Reserve, and Commit before anything happens, which is quick but not instantaneous. You only have to Commit once, which is why you do it before the loop. Additionally, there are implicit backwards transmissions (see https://www.ni.com/docs/en-US/bundle/ni-daqmx/page/mxcncpts/taskstatemodel.html)

Basically, if you're at Verified, then immediately Start, when you Stop the task it will go to Committed, but then will automatically go back to Verified. So if you Start again, you still have to Reserve and Commit each time you want to Start.

If you manually go to Committed, then Stop the task, you stay at Committed and you don't have to repeat any of that each time you restart the task.