Analog Output Buffer Systematically Drains During Continuous AO Streaming – NI 9260 in cDAQ-9185

[derFliXX]

Hi everyone,

I'm working with a NI 9260 analog output module in a cDAQ-9185 chassis, connected to my PC via Ethernet. The goal is to continuously stream a generated waveform to an AO channel.

Here’s how the system is structured:

• A generator loop runs every 10 ms, generating a 10 ms waveform snippet (100 samples at 10 kHz).
• Every 10 snippets are combined into a 100 ms chunk (1000 samples).
• This chunk is then passed via a queue to an output loop.
• The output loop writes the chunk to the AO task using DAQmx Write (autostart = false, regeneration disabled), only when an element is available in the queue (queue timeout = 0).
• The AO task is configured with DAQmx Timing to run at 10 kHz, with continuous samples, and a buffer size of e.g. 10,000 or 50,000 samples.
• Before starting the task, the buffer is prefilled with multiple chunks (e.g. 10×1000 samples = 10,000 samples).

The system initially works as expected, but:

• The output buffer fill level decreases linearly over time, even though the generator loop runs slightly faster than 10 ms on average.
• An underflow error occurs after a predictable duration, depending on the number of prefills.
• The latency between waveform generation and AO output is high when the buffer is heavily prefilled (e.g. several seconds), but decreases over time as the buffer drains.
• The behavior is independent of chunk size: for example, writing 2000 samples every 200 ms results in the system lasting twice as long before underflow, but the buffer still drains at the same rate.
• The queue is usually empty or contains only one element, but is consistently being filled.
• The write loop is only triggered when a chunk is available in the queue.

Eventually, the AO task fails with either error -200621 or error -200018, seemingly at random.
Here is the full error message for -200621:

---

Error -200621 occurred at SimApp.vi

Possible reason(s):
Onboard device memory underflow. Because of system and/or bus-bandwidth limitations, the driver could not write data to the device fast enough to keep up with the device output rate.
Reduce your sample rate. If your data transfer method is interrupts, try using DMA or USB Bulk. You can also reduce the number of programs your computer is executing concurrently.

Task Name: unnamedTask<12>

---

System details:

• LabVIEW version: 2018
• NI-DAQmx driver version: 20.1
• Device: NI 9260 in cDAQ-9185
• Connection: Ethernet

Has anyone encountered this kind of systematic buffer drain during AO streaming, even when the data rate should match the configured sample rate?
Are there known limitations or considerations when streaming AO data to a cDAQ device over Ethernet?

Any insights would be greatly appreciated!

Greetings, derFliXX

[santo_13]

Why are you streaming samples? can it not be pre-determined?

[derFliXX]

I'm streaming the samples because I want the signal to be generated as close to real time as possible. The parameters that define the signal can be adjusted during runtime, so the waveform needs to be built dynamically rather than precomputed. This allows for flexible, responsive behavior during simulation.

[derFliXX]

Btw - added the full blockdiagram if this helps.