Issue Details

When I run an NI-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.

Solution

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 NI-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 error 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 timing 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 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 readout 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.

Case 3: Reading two tasks running at different rates, using one acquisition loop

This error can occur if two tasks sharing an acquisition loop have different sample rates. The reason that this error presents itself is that the DAQmx read is a blocking call. One DAQmx read will take longer to read the same number of samples, while that longer read is occurring the other task's buffer is filling up. 

• Make sure each DAQmx Read in the loop has the same read rate. For example, one task reads 3000 Samples / 3000 Samples/s = 1s, and the second task in the loop reads 100 Samples / 100Samples/s = 1s. Each DAQmx Read will take 1s, so the buffer won't fill up every iteration.  

Note:  Remember always to read back the Sample Rate of each task by using a DAQmx Timing property node >> SampClk.Rate. This is important to confirm that the Actual Sample rate used by the card is exactly what the user specified. Otherwise, there could be an overflow error because there will be some samples that are not being read and will be accumulated in the buffer. For example, this is common with M Series cards if you chose a sample rate that they can't achieve exactly, like 30000 S/s, the card will run at 30030.03 S/s. This means that if you read 30000 Samples in the DAQmx Read function in the acquisition loop, there will be 30.03 samples being accumulated in the buffer every iteration.   


Note: DSA modules can coerce to specific sample rates.

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:
 

The number of samples read per DAQmx Read can be configured using the the DAQmx Read VI. Consider whether you should be reading 1 Sample per read or N samples. Select the correct choice using the different polymorphic instances of the DAQmx Read VI .

Setting the sample rate and read rate to be the same does not guarantee that they will operate at the expected speed. This inconsistency can occur when there are multiple operations in the while loop, which can delay the time of execution. This will cause DAQmx read to operate slower than specified, which will lead to overflow. To verify the speed that the loop is operating, you can use loop benchmarking techniques shown in the figure below:
 
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. Please refer to the DAQmx Timing (VI) Help for more information. 

Buffer Monitoring with DAQmx Property Nodes
During 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, functions will execute as soon as they have received all of their inputs, regardless of the position on the block diagram. To avoid this uncertainty in the order that functions execute, error wires can be used to enforce dataflow.

In a continuous DAQmx task, data is written to the buffer until a DAQmx Stop Task VI executes. The PC buffer starts filling with data when DAQmx start executes. Code without enforced dataflow may create a delay between when data is acquired and read. This can cause the buffer to overflow and the initial data being overwritten, causing Error -200279.

The code snippet below is an example of code without enforced dataflow, the result is that that we can't be sure when the DAQmx Start VI will execute compared to the Open/Create/Replace file VI. Measurements could be filling up the buffer while a file is selected, meaning that there is danger of a PC buffer overwrite.
 
An ideal example is shown in the snippet below, here the error wire forces the DAQmx Start Task VI to execute after the Open/Create/Replace File VI.