DAQmx AI Read Performance Degrades

[wbdoyle]

Hypervisor 2.1f2, DAQmx 9.2.3, on RT2010 with a PXI-4224 AI card

From test to test DAQmx reads become longer and longer. A test is defined as:

• Create task
• Start task
• Loop for N frames in a software timed TCL. 1 sample per channel per frame at 200Hz.
• Clear task

Each frame grows by ~200us from test to test.

• Tests are run back to back in the same application instance, i.e. application started only once
• When the same code is used on a PXI-6255 AI card the issue is NOT observed
• Frames measured with CPU ticks on the RT controller
• Resetting card in MAX has no effect
• Restarting the RT target fixes the issue until read times grow too large again
• Cannot post code

Any ideas? Try new DAQmx version?

[Travis_Ann_N]

Hi wbdoyle,

How are you collecting your data? Are you appending to an array each time you get more samples? If so, it could be taking that long to reallocate memory each time. Instead, I suggest pre-allocating the necessary memory. 

Regards,

Travis Ann

[wbdoyle]

During a test where I collect 1 sample per N channels per frame. The array for a given frame is used and written out somewhere else. So data does not accumulate over time.

Additionally the read times are constant for a given test until the task is cleared and a new test is started.

It is strange that I see with a PXI-4224 and not the PXI-6255 using the same code.

[Travis_Ann_N]

Have you always seen this behavior in this card or has it been working correctly and suddenly changed? If the later, what was the change? It may be some default setting in the 4224 that is causing data to be building up. And possibly the 6255 doesn't have that setting. Also, do you have any other E series cards that you can try other than the 4224? 

Regards,

Travis Ann

[wbdoyle]

After further investigation this also appears to affect the PXI-6255 to a lesser extent. After carefully reading the LabVIEW help topic "Task Creation and Destruction" it appears my tasks are never 'destroyed' until my application exits even if I call 'clear task'.

This this is a RT target that remains on and running my application indefinitely which means my tasks are not 'destroyed' until we force a reboot.

Our design requires tasks to be created for each test then cleared at the end of the test. Tests can be conducted repeatedly until the RT is rebooted. Our design also requires I/O to be reconfigurable from test to test so I cannot simply reuse the task and avoid 'clearing tasks' for every test. Last note is memory usage is static and I never see errors or anything related to the resource being reserved. This at least confirms my sequence of DAQmx calls is valid.

Any other ideas?

[wbdoyle]

I have also looked at timing using the RT execution trace toolkit. I can watch the DAQmx execution time grow by inserting a user event before and after the read.

For a given test (create task, add channel, start, read N samples, clear) I can read as many samples as I want with constant read times. The next test the read time grows. Tried DAQmx 9.5 with no improvement.

If it has any bearing, the thread tasks are created is not the same thread that tasks are used and cleared.

[Brian-G]

Hi wbdoyle,

If you use the DAQmx Clear Task VI within each loop the DAQmx Task will clear from memory and release any resources it has reserved.  The following is from LabVIEW Help:

"DAQmx Clear Task (VI):  Clears the task. Before clearing, this VI aborts the task, if necessary, and releases any resources the task reserved. You cannot use a task after you clear it unless you recreate the task.

If you use the DAQmx Create Task VI or the DAQmx Create Virtual Channel VI within a loop, use this VI within the loop after you are finished with the task to avoid allocating unnecessary memory. Refer to Task Creation and Destruction for more information about when to use this VI."

If you are properly clearing your tasks between each test they will be destroyed and should not cause any more delay.  Can you try to run your program and only output the acquired data to an indicator, instead of writing it to an array?  Or run the example Cont Acq&Graph Voltage-Int Clk.vi from the NI Example Finder and see if this still results in an increase in execution time.

If you are able to post your RT Execution Trace Toolkit results, that would be helpful.  Also, are you able to post a screenshot of just the part of code that includes the data acquisition?  Please include the PXI chassis/controller or MXI card you are using as well.  Thanks.

Brian