NI-DAQmx Analog Output: Error Code 200016

[lindseyr]

I want to write one second of data - read from a file - to my DAQ-6036E card as analog output. It should then repeat with minimal delay. I use the waveform for timing and write a fixed number of samples. This usually works for about 160 seconds before I get error code 200016 - something about On-board device memory underflow . The sampling rate is at 500Hz - half the maximum of the card, and there are no other programs running on my system. What could be causing this error? Do I have to adjust timing parameters, buffer lengths, etc to fix it?

[AlanArmstead]

Are you using LabVIEW?? If so, what version? The error indicates that your program is not putting data into the buffer fast enough. You should make sure you are not opening and closing your file inside your loop, and basically try to have as little code in your loop as possible. Would it be possible to read your entire file in before you start he analog output, so you have all of your data and your program wouldn't be slowed by file i/o. You can also increase the size of your output buffer. In LabVIEW, All Functions>>NI Measurements>>DAQmx Data Acquisition>>DAQmx Advanced Task Options pallette. Use the DAQmx Configure Output Buffer.vi.
Alan A.

[lindseyr]

I am using LabVIEW version 7.1. The error comes in the WaitUntilDone VI. The operation of writing to the DAQ card is done in a Sub-VI that has no file i/o in it, and there is no file i/o in the loop. I just read in the entire dataset at the start and then send a subset of that array into the Sub-VI everytime the loop is run. The only other code in the loop is some time-indexing and stop-checking. Is putting in the WaitUntilDone.vi after the DAQwrite.vi enough or could my loop be going faster than the Sub-VI or DAQWrite? I also tried changing the Output buffer length from 1 to 10 times the number of samples in each loop. The frequency of the error did not change. Do you know what the default value is for this buffer?

[AlanArmstead]

Hello,
You can find out the size of the buffer that DAQmx sets. It is a property node on the afore mentioned palette: All Functions>>NI Measurements>>DAQmx Data Acquisition>>DAQmx Advanced Task Options palette, and it is called DAQmx Buffer Property Node, and the property is called Output Buffer Size. Take a look at the attached example. I have included the property node that I just mentioned. This is just a modified shipping example, found at Help>>Find Examples in LabVIEW. See if you can run this example without getting the error. If it does, you might want to use this one as a model, and build off of it.
-Alan A.

[lindseyr]

The error still persists using the example. Can you tell from this if the error/buffer underflow is happening on the DAQ card itself, or on the computer I am using? I also don't have the property node that you added. There is no such property node in my version of LabVIEW I guess because it didn't accept the node. Otherwise the example worked fine.

[Mcdan]

lindseyr,

This error generally occurs when your devices AO Timing engine sends an update pulse to the AO Channel but there is no data available for the device to write. There are several reasons why this may occur. The first is that the device has output all of the data written into the buffer. In this case there simply is no more data left for the device to write. If this is the problem, one thing which may help solve it is to allow the driver to regenerate the samples that have been written to the buffer (use DAQmx Write Property Node->Configure->RegenMode). Set this to Allow Regeneration. If this stops the problem, then you know that you are running out of data in your buffer. If this does not correct the problem, then it is possible that your system cannot transfer data from the buffer to the device fast enough. The 6036 has no AO FIFO, which means that data must be transferred from the buffer to the device every time a point is written. The speed at which you can do this can be very system dependent. To test this, you may want to try and run your application with a slower update rate. If you are able to sustain your generation at a lower rate, it may be that your system cannot transfer data between the buffer and your device fast enough.

Hope this helps,
Dan