DAQmx Start Task VI slow

[aputman]

---

@chadt wrote:

Like this:

https://forums.ni.com/t5/Example-Programs/Measuring-Execution-Time-of-a-Code-using-LabVIEW/ta-p/3511...

---

Did you do something like this specifically around the Start Task VI and it returned 800ms?

[chadt]

Update: Today Start Task VI is taking 100 ms to execute. This is still too long.

[aputman]

Can you explain why you are focused on this VI taking too long to execute?  Your acquisition doesn't start until after this VI executes.

[chadt]

---

@aputman wrote:

Can you explain why you are focused on this VI taking too long to execute?  Your acquisition doesn't start until after this VI executes.

---

It's part of a much larger program and other things are executing simultaneously/before/after, we need it to execute at the correct time with respect to everything else. Manually adding a delay to ensure it has executed is problematic for other reasons which are difficult to explain here. I think it's reasonable to expect that Start Task.vi should execute in less than a ms.

[chadt]

---

@aputman wrote:

---

@chadt wrote:

Like this:

https://forums.ni.com/t5/Example-Programs/Measuring-Execution-Time-of-a-Code-using-LabVIEW/ta-p/3511...

---

Did you do something like this specifically around the Start Task VI and it returned 800ms?

---

Yes, I did. Today it is taking about 100 ms.

[Kevin_Price]

Typically, more goes on during DAQmx Start than you might expect.  See this brief summary of the DAQmx Task State Model.  Internal to the driver, the task goes through several distinct state transitions from unverified-->verified-->reserved-->committed-->running.  Task buffer memory allocation is one thing that comes to mind that might (at least sometimes) be fairly time consuming.

You can do yourself a favor by pre-committing the task using DAQmx Control Task during your config stage.  Then you have only a single fast transition left to do when you call DAQmx Start.   (Pre-committing is commonly recommended for Finite Sampling tasks that require fast turnaround from stopping to re-starting.)

-Kevin P

[chadt]

---

@Kevin_Price wrote:

Typically, more goes on during DAQmx Start than you might expect.  See this brief summary of the DAQmx Task State Model.  Internal to the driver, the task goes through several distinct state transitions from unverified-->verified-->reserved-->committed-->running.  Task buffer memory allocation is one thing that comes to mind that might (at least sometimes) be fairly time consuming.

You can do yourself a favor by pre-committing the task using DAQmx Control Task during your config stage.  Then you have only a single fast transition left to do when you call DAQmx Start.   (Pre-committing is commonly recommended for Finite Sampling tasks that require fast turnaround from stopping to re-starting.)

-Kevin P

---

Thanks very much for this, and you make a good point. I added in the Control Task VI a few days ago and now the time is down from 800 ms to 100 ms. Which is a big improvement! 100 ms is still a bit too long for us, though. I'll read through the link you provided and see if I can find anything else to improve the situation.

[chadt]

---

@chadt wrote:

Update: Today Start Task VI is taking 100 ms to execute. This is still too long.

---

I should have mentioned that I added in the Control Task Vi and I think that is the source of the improvement.

[Kevin_Price · Accepted solution]

I looked at the screencaps in msg #1, I must have skipped over them before.  I'm still on LV 2016 though so couldn't look at actual code.

It appears that you call DAQmx Timing to configure the sample rate and buffer size *after* you commit the task.  If that's not producing an error then it's probably unwinding the task state back from "committed".  It'll be better to commit the task *after* the call to DAQmx Timing.  Give that a try and see if speed improves.

Calls to DAQmx Start are normally pretty fast, though not necessarily less than 1 msec.  However, 800 or even 100 msec are definitely not typical.  Here's some benchmarking where the pre-commit helped reduce loop timing for repeated start/stop cycles from 4 msec to 1.

I'm not familiar with your particular DAQ device.  I see filtering mentioned which *might* add a delay from task start until the 1st sample is available.  But I wouldn't be expecting the actual call to DAQmx Start *itself* to be unusually slow.

-Kevin P

[chadt]

---

@Kevin_Price wrote:

I looked at the screencaps in msg #1, I must have skipped over them before.  I'm still on LV 2016 though so couldn't look at actual code.

It appears that you call DAQmx Timing to configure the sample rate and buffer size *after* you commit the task.  If that's not producing an error then it's probably unwinding the task state back from "committed".  It'll be better to commit the task *after* the call to DAQmx Timing.  Give that a try and see if speed improves.

Calls to DAQmx Start are normally pretty fast, though not necessarily less than 1 msec.  However, 800 or even 100 msec are definitely not typical.  Here's some benchmarking where the pre-commit helped reduce loop timing for repeated start/stop cycles from 4 msec to 1.

I'm not familiar with your particular DAQ device.  I see filtering mentioned which *might* add a delay from task start until the 1st sample is available.  But I wouldn't be expecting the actual call to DAQmx Start *itself* to be unusually slow.

-Kevin P

---

Thanks again! I moved Control Task VI to after the sample rate and buffer size configuration, so the task is 'committed' after we set the sample rate and buffer size. This took the Start Task VI time down to 50 ms. Which is still a big improvement over 100ms. 

To get it all working in the end, I moved the 'start' to its own state in the state machine, since 50ms could still be problematic, and now my script won't ask for 'measure' until 'start' is complete and everything is synced, so I shouldn't miss any triggers. 

Thanks so much for your help. Getting the Start Task timing down to 50 ms was critical for getting everything to work together nicely. Having an 800ms delay in our experimental rep rate would have been completely unacceptable, but we can live with 50ms here and there, which is in the range I'd expect for any big software program.