I'm working on an application (L/V 2011) that must sample hours of data out an AO port at 120 s/sec. The I/O device is a USB-6218, which will not do 'hardware timed on demand' AO. The problem: the output stream must pause on demand, and sometimes the output level changed during that pause period, then restarted where it stopped in the data stream. The output buffer size is set to 120 so it shouldn't take more than a second to empty out, but I'm seeing things in the buffering that puzzle me. As you'd expect, if the data is 'chunked' (120 sample array) out too slowly it causes an underflow error (no data in the buffer). However, if the data is written too rapidly, there's no overflow; something seems to store it, up to at least 10 K samples. If a Pause occurs, all that data is lost!? Help says the DAQmx Write property SpaceAvail shows “the amount of available space in the buffer.” Since the system acts as if there is an unlimited buffer, I’m not sure what SpaceAvail is showing. And tests using it to set the 'chunk' size show a distorted waveform, indicating data is lost. So my questions: 1. Why is there no overflow error; where is that data going? 2. What does the SpaceAvail property show? 3. Anyone have suggestions for a better design? Jim

Jim, There is indeed multiple layers of buffering that occur when doing analog output. For a USB device this includes: 1) DAQmx Buffer. You can/have set the size of this buffer. 2) USB Transfer Buffers. You can get/set information about these buffers via the USB Transfer Request Size and USB Transfer Request Count properties. These properties are buried deep in the DAQmx channel property node. 3) Each device has some amount of memory dedicated for buffering USB transfers as they arrive. There is no way to configure this. 4) Analog Output FIFO. You should be able to query this via the 'Onboard Buffer Size' property in the DAQmx Buffer property node. In order for data to get from your program to the device's output, it must travel through all of these layers of buffers. Since DAQmx attempts to be proactive in preventing the FIFO on the device from becoming empty and causing error, the data written is pushed as far through this buffering process as is possible. As such, as soon as data is written, it will get transferred to the USB transfer buffers and eventually on to the device. As such, there becomes space available in the buffer for more of the data you've written and DAQmx will move that data along as well. CurrWritePos is always relative to the first sample you write, and will increment for each sample written. Buffer size has no bearing on how it is calculated. When you stop/start a DAQmx task, it does discard all of the data in these buffers. This is by design. To me, it sounds like you should take the following approach: 1) Use a pause trigger to pause your output. This way you will avoid stopping and starting the task, and you will not lose all of the buffered up data. - There is no software pause trigger, so the source will need to be an actual signal. You can make this happen by using DIO on your device to write a digital line high or low depending on whether you would like to pause or not. Wire this digital line to a PFI line, and use the PFI line as your pause trigger source. 2) Write less data at a time. If DAQmx fills up all the layers of buffering, you end up with a long delay between writing data with DAQmx write, and actually seeing the data on the output channel. To do this, you'll need to tell DAQmx not to regenerate data from the buffer (Regeneration Mode property in the DAQmx write property node), then implement a loop which periodically writes data to the buffer. By limiting the amount of data written to the device, you should be able to limit how much data gets buffered up in all of the intermediate buffers. Hopefully that provides some insight into what you're seeing. Please let me know if I've been unclear. If I have time I may write up an example of my two step approach above. I hope that helps,Dan

Multifunction DAQ

AO buffering problems

Solved!

As an alternative for future readers, below's a snippet of how I tend to prefer to do these things. My method routes the signal within a task context. When the task is cleared, the routing will not persist to cause mischief for other tasks. The method shown previously using "Connect Terminals" routes the signal within a device context. The routing *can* (and often does) persist after tasks are created and cleared.

Just an FYI, each method has its merits, I just have found that I usually prefer the task context with auto-cleanup.

-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.