From 11:00 PM CST Friday, Feb 14th - 6:30 PM CST Saturday, Feb 15th, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

1 Msample DAQmx analog output buffer size limit

Solved!
Go to solution

Some of this stuff is probably pretty system dependent and variable, but I did a quick trial run myself with a desktop PCIe board and found that I had to call DAQmx Control Task with a "reserve" or "commit" to force the buffer allocation to actually take place.  Even so, the Write still required the majority of the time.

 

Note though that if you "commit", subsequent stop/start cycles will be more efficient due to the DAQmx Task State Model.  Probably only in the realm of single digits worth of msec though, so maybe negligible if you need to write different data into the buffer before restarting.  (If you stop and restart without writing different data, the task will just start over with the buffer of data you wrote previously.)

 

 

-Kevin P

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
0 Kudos
Message 11 of 12
(284 Views)

This is interesting! I could reproduce your findings with my board: when reserving the buffer first and commiting it, the loading time drops from 160 ms to 110 ms for a 16 MB buffer, which is quite substancial.

 

Relative to re-triggering the same task with or without reloading the buffer I must be doing something wrong but I cannot seem to achieve it properly: when restarted the task immediately exits at the wait until done. Here is a snapshot of my updated test VI in case you can point me out to my mistake.

 

Capture.PNG 

0 Kudos
Message 12 of 12
(267 Views)