LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

AI DAQmx error -200279

Solved!
Go to solution

I'm running a loop with an N-Chan AI Read vi, outputting its values into a queue that is read by other parallel loops.  During program operation though, when other loops process their queues and (from what I can tell) occupy processor time, the AI Read loop returns error -200279, saying:

 

Error -200279 occurred at AI Read.vi:7

Possible reason(s):

Attempted to read samples that are no longer available. The requested sample was previously available, but has since been overwritten.

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.

Property: RelativeTo
Corresponding Value: Current Read Position
Property: Offset
Corresponding Value: 0

Task Name: _unnamedTask<13>

 

I'm pretty confused as to why this error keeps popping up.  Does anyone know what the root cause of this error typically is?

0 Kudos
Message 1 of 7
(3,893 Views)

Update:

 

Before running the task, I changed the input buffer size to 1000, and changed the overwrite option to not overwrite samples that have not been read yet.  I can't seem to replicate the error at this point, but I'm not sure why the buffer would be overflowing.  Will provide more updates as they come.

0 Kudos
Message 2 of 7
(3,886 Views)

Update:

 

While monitoring the Available Samples Per Chan value, I found that doing anything (as little as grabbing the title bar of the window of any running VI) makes the value increase.  I don't have any event structures in place that wait for a window grab event, but nonetheless, grabbing a VI window title bar bogs down the performance of the AI Read loop.  No solution yet, I'll keep updating as I go along.

0 Kudos
Message 3 of 7
(3,883 Views)

Update:

 

Changing the priority under VI properties to a higher or time sensitive setting has helped decrease the build up of samples in the task and increase performance of the loop, but it seems that there are more issues possibly related to the number of visible items on a VI front panel.  I have a number of objects that toggle their visibility based on which item is selected in a menu, and when objects with graphs are displayed, I notice performance dropping and samples accumulating.  No solution yet.

0 Kudos
Message 4 of 7
(3,876 Views)

Found that if I hide the graph to which samples are being written while I have another menu-selected graph displayed (not necessarily having samples written), then performance increases.  Not sure why this is happening, but I'm calling that a solution for now, unless anyone can illuminate the issue further.

0 Kudos
Message 5 of 7
(3,874 Views)
Solution
Accepted by topic author Jeanius

Hi Jeanius, I believe this article can explain your problem.

Alejandro C. | National Instruments
Message 6 of 7
(3,856 Views)

Perhaps a better question is: ok, I know what is causing the -200279 error, how do I recover from it without having to restart the entire system?

0 Kudos
Message 7 of 7
(3,775 Views)