This content is not available in your preferred language.

The content is shown in another available language. Your browser may include features that can help translate the text.

Error -200279: Unable to Keep Up with Acquisition in DAQmx

Updated Sep 9, 2019

Reported In


  • LabVIEW


  • NI-DAQmx

Issue Details

When I run a DAQmx application in LabVIEW using DAQmx Read or the DAQ Assistant Express VI to acquire data continuously, I get the following error:

Error -200279 occurred at DAQmx Read (Analog 1D Wfm NChan NSamp).vi

Possible reason(s):
The application is not able to keep up with the hardware acquisition.
Increasing the buffer size, reading the data more frequently, or specifying a fixed number of samples to read instead of reading all available samples might correct the problem.


This error is caused by a PC buffer overflow. The PC buffer is the buffer that exists on a computer between the DAQ hardware and LabVIEW's application memory. It is written to continuously by hardware, but is only periodically read from by LabVIEW. This can often lead to a mismatch in read rates. Typically, data is overwritten in the DAQmx PC Buffer because either the read rate is slower than the sample rate, or the DAQmx PC Buffer is too small to hold the data required by the DAQmx task.

Case 1: Read Rate Is Slower Than Sample Rate

This error is often the result of the read rate for the continuously sampled DAQmx application being slower than the sample rate of the DAQmx task, causing samples to build up in the DAQmx PC Buffer until an overwrite occurs. The sample rate is the rate specified via the DAQmx Timing VI property below:

When troubleshooting this error, the first step should be to ensure that the read rate and the sample rate for your application are the same.

Since the read rate for your application depends on both the number of samples you are requesting per DAQmx Read, as well as the number of times that the DAQmx Read function is called in a second, you can adjust the read rate by explicitly controlling the number of samples required by the DAQmx Read, or by explicitly controlling the number of times that the while loop containing your DAQmx Read executes in a second using nodes such as Wait (ms):

Note: DAQmx Read will automatically wait until the requested number of samples are available, so it is usually only necessary to control one of these factors in a particular application.

If the while loop is performing more slowly than expected, you may need to implement a Producer/Consumer architecture in order to move other processes, such as logging, post-processing, analysis, and user interface functionality outside of the acquisition loop.  

If increasing the while loop performance is not an option, you may need to lower the sample rate for your application instead.

Note: Do not use Highlight Execution with code that contains a DAQmx Read, since it will slow down the execution and cause a buffer overflow.

Case 2: PC Buffer Is Too Small to Hold Task Data

Another reason for this error is that the DAQmx PC Buffer is too small to hold the amount of data required by the DAQmx task, causing an overwrite in the DAQmx PC Buffer before data has been acquired at all.

Occasionally, this error can be resolved by simply increasing the size of the host side data buffer manually. However, if the error is occurring because data is not being read out of the DAQmx buffer fast enough (Case 1 above), increasing the buffer size will only delay the occurrence of the error, and will not eliminate it completely.

Additional Information

The read rate for your DAQmx task is determined by two factors -- the number of samples acquired per read, and the number of reads per second:

Even if you set the read rate and sample rate to the be same, your program may not be able to perform at speed you expect. This can occur when many operations are executing inside the while loop, causing each iteration to take longer than expected. This will result in the DAQmx read not occurring as often as expected, and samples piling up in the buffer. You can use loop benchmarking techniques, such as those shown below, to verify that the while loop is actually performing at the speed you expect:

Additional Troubleshooting Considerations:

Finite Sampling vs. Continuous Sampling
Some applications may not require continuous sampling and may only need a finite number of samples to be available at read. If this is the case, you may consider setting the DAQmx Timing sample mode to Finite Samples instead of Continuous Samples. In this configuration, every loop cycle will wait some time before samples are available (i.e., reading 100 samples at 1 kHz would mean you wait 0.1 seconds at read). This would mean that samples are lost between reads and that samples will not be available as soon as the read is called. However, this should mitigate the error unless you are experiencing Case 2 in the above solution.

Buffer Monitoring with DAQmx Property Nodes
During a continuous, buffered acquisition, the buffer can be monitored to gain more information about how the current configuration affects the buffer. If the number of available elements continuously increases during the acquisition, take one of the actions listed above to avoid eventually overflowing the buffer. To monitor the amount of data available in the buffer, use a DAQmx Read property node to read the Status:Available Samples Per Channel property.

Controlling LabVIEW Dataflow to Avoid Overwrite Errors
LabVIEW is a dataflow language, meaning that a VI or structure can execute as soon as it has received all of its inputs, regardless of its position on the block diagram. Often it is useful to use error wires as an input to ensure that a VI or structure will not execute before another. If an error wire connects VI A to VI B, then B will not have all of its required inputs until after A executes and the error cluster is passed from A to B.

In a continuous DAQmx task, data is written to the buffer from the time that the DAQmx Start Task VI executes until a DAQmx Stop Task VI or DAQmx Clear Task VI executes. Between the time that the DAQmx Start Task VI executes and when the first DAQmx Read executes, the DAQmx PC buffer is being filled with data. If this interval is too long, then the buffer may be completely filled and the initial data will be overwritten before the DAQmx Read VI takes it out of the buffer, causing Error -200279.

The code snippets below show a common scenario in which dataflow execution can cause a buffer overflow error. In the first snippet, you can see that there is no guarantee that the DAQmx Start Task VI will execute after the Open/Create/Replace file VI (which will generate a pop-up dialog), so measurements will be filling up the buffer while you select a file, meaning that there is danger of a PC buffer overwrite.

To avoid this issue, per the below example, connect the error input and output terminals of each function to ensure that the DAQmx Start Task VI executes after the Open/Create/Replace File VI has finished executing.

Sample Rates with Dynamic Signal Acquisition (DSA) Devices
National Instruments DSA devices use a 24-bit delta-sigma analog-to-digital converter (ADC) that maximizes signal integrity by shaping noise and reducing distortion. These specialized ADCs use a master timebase that is divided down by discrete integer multiples to achieve several available sample rates; as a result, all DSA devices have a limited number of available sample rates. 

For example, the NI-9234 has a total of 31 possible sample rates, with a minimum sampling rate of 1.652 kS/s. The number and value of available sample rates varies by DSA device and should be specified in your device specifications manual.

If the sampling rate for the NI-9234 device is set below the minimum rate using a DAQmx Timing VI or Property Node, the actual sample rate will be coerced up to the minimum rate available for the device in the background of the DAQmx API. Consequently, you may have designed an application with a read rate appropriate for a much lower sample rate than is actually occurring, which could lead to Error -200279.  

If you are using a DSA device for your acquisition, always consider the possible sampling rates and design your application appropriately.

Note: Consider using a DAQmx Timing property node and reading the Sample Clock:Rate property to verify which sample rate is actually being used by the device, regardless of the rate set at the DAQmx Timing VI.


Not Helpful