Stuck in Error -200279

[Ken_Brooks]

My program involves several DAQ tasks that run in lockstep, after the fashion of the "Multi-Function-Synch AI-AO" example. Works very well in general, but if anything ever interrupts the flow of the program, I get permanently stuck with error -200279. Here is the precise report:

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

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
Requested Value: Current Read Position
Property: Offset
Requested Value: 0

Task Name: Analog input

And once I am in this state, the only way I can find to get out of it is to kill and restart all my tasks. Surely there is a better way? How do I resynchronize so that the computer quits asking for old samples and gladly accepts the ones that are there NOW?

Here are a couple of reliable ways to bring on this problem: 1. Hit a breakpoint while debugging. This is very exasperating, when you can't use a breakpoint without destroying the very operation you're trying to debug. 2. The user presses a button that opens a file dialog. Even though my main program consists of several parallel loops, and the file dialog is called from a DIFFERENT LOOP from the one that is doing the data acquisition. That's a problem anyway. How can I bring up a file dialog without stopping my DAQ flow in midstream?

Help eagerly appreciated. This problem is stopping my program from being the industrial-strength job that my scientist users need.

Thanks,
Ken

[Fred_V]

Hi Ken,

While I'll have to check to see why dialogs called in other loops cause your DAQmx code to stall, you should be able to handle the -200279 error explicitly within your code.

If you unbundle the error cluster and check to see whether the error value is -200279, you can clear the error and your code will continue executing.

That said, this KnowledgeBase article discusses the file dialog as a cause for this error, and suggests establishing the file path before the DAQmx code runs.

I hope this helps, 

[Ken_Brooks]

The situation is crazier than I told you. The file dialog is called, not from another loop in the same VI, but from a DIFFERENT VI ENTIRELY, running in a subpanel. And the DAQ loop is running the whole time, from way upstream, it would be weird and inconvenient to stop and restart it just for this.

You mentioned clearing the error. But it isn't a problem of clearing the error. The error is not carried in a shift register; it is being issued afresh every time around the DAQ loop. So what I really need is some way to clear the buffer flow situation inside of DAQmx, so that the next read call will be happy to read what is there, instead of complaining about what is no longer there. The article you quoted has a piece of sensible advice:

"A DAQmx Read Property Node must be used to obtain the amount of data remaining in the buffer. Set the property to Status»Available Samples Per Channel and attach an indicator to the output."

That's nice for seeing what is going on inside, but now I need a way, once the error has occurred, to CHANGE what is going on inside.

Thanks,
Ken

[Mcdan · Accepted solution]

Ken,

You can specify to DAQmx which samples in the buffer to read.  By default, DAQmx will read relative to 'Current Read Position'.  What you are seeing is that unread data starting at 'current read position' got over-written with new data.  Essentially the data that was at 'current read position' no longer exists, and trying to read from this location causes you the error you are seeing.  DAQmx does allow you to specify where it reads data from.  You can use the DAQmx Read Property Node to specify what DAQmx Reads Relative to, as well as an offset from there in the buffer.  It is possible that if you detect this error, you could read relative to 'most recent sample' for one read.  This would essentially throw out all the data in the buffer between 'current read position' and the most recent sample in the buffer, but would allow your application to continue, provided it is equipped to deal with gaps in the data.

Hope that helps,

Dan

[afmstm]

I have also run into this same issue, and the suggestions so far seem like real ugly hacks!

Ken has stated the problem well - when this error occurs, there is no obvious way to just reset everything and keep going.

I am using VB6 - Dan, can you let me know which DAQmx C API function to look at?  I've scanned the help and can't find anything.

Thanks,

Van

[Mcdan]

Van,

I think the thing that is difficult about restarting after a buffer error automatically, is that the data the user is requesting (by default value of read position and offset) really does not exist any more.  As such, we don't want to just return different data without some mechanism for notifying a user (which we do with an error code).  If a user were for instance doing an FFT, it really isn't appropriate to just drop old data and pick up newer samples.

The functions you're looking for in the C API will be DAQmxSetReadRelativeTo and DAQmxSetReadOffset.  These methods should allow you to seek around in the buffer and skip over any over-written samples.

Hope that helps,

Dan

[afmstm]

Hi Dan,

Agree with you in general.  In our specific case, we need to recognize the error but then immediately move on and get the next available data.  What I think I understand from earlier in the thread is you need to manually move the RelativeTo and Offset to the most recent data and then continue.  Here's what I have tried, and it seems to work.  This is placed in the error handing code (essentialy in the DAQmxErrChk, so you have to worry about recursion because of calls to DAQmxErrChk).

     Case -200279

         ' Force DAQmx to read the most recent sample in the buffer

         DAQmxErrChk (DAQmxSetReadOffset(ByVal AITaskHandle, -1&)) 
         DAQmxErrChk (DAQmxSetReadRelativeTo(ByVal AITaskHandle, DAQmx_Val_MostRecentSamp)) 
         ' now read just one value to resynch everything
         DAQmxErrChk (DAQmxReadAnalogF64(AITaskHandle, -1, 1#, DAQmx_Val_GroupByChannel, AIData(0), 1&, sampsperchanread, ByVal 0&))
         ' now reset DAQmx to read from the current position from now on
         DAQmxErrChk (DAQmxSetReadOffset(ByVal AITaskHandle, 0&))
         DAQmxErrChk (DAQmxSetReadRelativeTo(ByVal AITaskHandle, DAQmx_Val_CurrReadPos))

The only problem is I don't really know if this is working as expected!  Not sure how to really tell.

Van

[Mcdan]

Van,

That seems like a reasonable way to handle the -200279.  To verify that it is working as expected, I think you could do something like the following:

1) Set reference voltage to some known value 1.

2) Clock in (Buffer Size + 10) worth of data (probably best to use an external sample clock here, so you can issue pulses on your command).

3) Set reference voltage to some known value 2.

4) Clock out some additional sample clock pulses (this number should be less than (buffer size - 10).

5) Since you haven't read yet, you should be in the -200279 condition.

6) You can adjust read offset and relative to from this condition to find the point in your buffer where data changes from value 1 to value 2, and make sure that you're seeing that where you'd expect.

Depending on what hardware you are using, this might be complicated by a few other factors, but I think this would be a good general procedure to use.  Let me know what hardware you're using, and I'll see if I can think of any reason why a test like this wouldn't work.

Hope that helps,
Dan

[afmstm]

Dan,

One last twist on the code snippet above, is that it takes time to execute, and during that time, it's possible for the error to happen again during high speed acquisition that relies on DAQmxRegisterEveryNSamplesEvent callbacks.  I think (but have not proven) that the callback function continues to be called, each time producing another error.  So you get a cascading error (sort of recursive) that crashes the program, presumably with a stack or heap overflow (hard to tell in VB6).  I've not found a way to stop this by for instance using a flag to indicate to the callback function that an error exists, and therefore to just exit.

Therefore, this approach on its own works fine for slow rates but does not work if the callbacks are happening too fast. 

I have found the only way to recover from the -200279 error when using callbacks under these conditions, is to stop the AI task and restart it.  Any pending events are discarded by the stop task.  This is of course, a rather blunt approach, but it is at least reliable. 

If you have any better ideas, please let me know!

Van

[Ken_Brooks]

Thanks, Dan. DAQmx Read Property Node proved to be a very good solution. Took me a little while to figure that out, because there were a lot of other ramifications going on. But this clears up the error, quickly.

That led to the discovery that my program then actually generates a PERIODIC error -200279. I have seen periods of 4 seconds, 8 seconds, and 9.5 seconds, depending on the details of my settings. Very steady and predictable. Strange, huh? But that's probably beyond the scope of this thread.  🙂

Ken