Stuck in Error -200279

[Ben]

---

@Ken Brooks wrote:

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

---

No not reall y in a Windows environment. I ussualy set the buffer to be able to handle upto 30 seconds worth of data since opening an Excel SS can take that long and if done while acquiring... error.

So increase the size of the buffer and read everything that is there, more often.

Ben

[deskpilot]

I was planning to post a new topic before I came across this one. I have a fairly robust acquisition VI that has started throwing this code randomly. It has done it on multiple computers (Vista and XP) using multiple different types of hardware (PXI, SCXI, Compact Daq). This is a Labveiw based program that runs an AI loop at an average of 21 Hz. I can run for hours with almost no measured variance in the loop rate. The data sample rates, depending on the system, are between 100 Hz and 5 kHz. The program running at 5 kHz seems to produce the error slightly more often, but it still pretty random. It has done it while no one is touching the computer, and after the task has been running awhile (ten minutes), but for less time than it sometimes runs (hours).

The only changes that I have made since the program was utilized for about two years without ever seeing the problem are: upgrading from LV 8.6 to LV2009 and LV2010, and I was also forced to install antivirus software on these computers that aren't connected to any networks.

It has now happened often enough that I have to do something or risk being crucified if it happens at the wrong time (as yet it hasn't).

I currently have default settings on read relative to (current), buffer size, and overwrite mode (overwrite). I have contemplated the idea listed above. After detecting the error, switch the read to a most recent sample with offset of -1, then switch back to a current read that acquires all samples in the buffer. I was hoping somebody on this thread has actually tried this successfully so that I know I'm not going to go chase my tail because the switching takes too long? I'm also not sure this property is settable while the task is running?

I also have not tried increasing the size of the buffer. I did not think I could set it 30 seconds long without overflowing memory, but I will give that a try. I still don't understand how a 2 second buffer can overflow without anybody doing anything on the computer?

[Danny_Funk]

deskpilot,

This is a common programming problem and there is a lot of good documentation on what causes it and how to fix it.

Why Do I Get Error -200279 from my DAQmx Read VI or Property Node?

If you are still having problems after reading through that article, can you post your code to help us get a better idea?

Regards,

Danny F

[deskpilot]

The following are things I am sure of:

1.The problem does not occur because of a delay between start task and read. It occurrs only after running for minutes to hours.

2. There is not a continuous build up in the buffer. While monitoring buffer size, it is always steady for long periods of time.

3. Excess processing in the acquisition loop is not the culprit. I have a 45 ms wait in the processing loop and have an alarm set if the loop takes 50 ms or more to execute. On the first read, or during alot of screen interaction, it may jump to 70 ms for one or two loops. Otherwise it does not alarm until the error pops up.  

The fix under discussion in this thread, of switching to a single point acquisition, and then switching back to a regular buffered acquisition seems to be the only fix, although an ugly one. It is not acceptable for my application, but then again it is more acceptable than the acquisition shutting down entirely. I will experiment with increased buffer size, but assume I will run into the not enough memory problem before this helps. The error is so difficult to duplicate, I really can't rely on this because I'll never know for sure if it fixed it.

I have submitted this program to NI for help before due to an unrelated problem. The problem ended up being hardware related, and they made no suggestions toward streamlining the code. I'll admit it can be difficult to look at, and so am not inclined to post it again. I'm not going to guarantee that it is bulletproof, but I'm confident that there is no simple programming correction to be made.

I would really like to know, at this point, how to make the error recoverable. Is there any example code that someone has worked out for this (such as the aforementioned temporary single point acquisition switch)?

[afmstm]

Revisitng this topic because it is again causing problems.  The code snippet I suggested earlier has a problem:  it introduces a random phase shift of the input data relative to the clock that is used to drive a simultaneous output. 

Previous code snippet for the error handler:

   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 comment "resynch everything" is not correct, it just resynchs the AIRead to the latest (random) position.

What I mean by this is that suppose the system is set up with both AO and AI channels, and read/write is controlled by a clock.  The AO and AI remain in step forever (they have identically sized buffers).  If the 200279 error occurs (for instance in our case if the CPU is too busy or the USB bus is overloaded), then the above code does indeed clear the 200279 error and restarts the AI, but now the AIData() array is out of step with the AOData() array.  In other words, a given index into the two arrays gives values that are not taken/written at the same time.  

I can fix this by stopping the clocks, restarting both the AI and AO, and then restarting the clocks.  They are now resynchronized.  Unfortunately, in doing this my sample is destroyed by the sudden stop/start of the AO.

What I need is a simple way to resynchronize the indices that DAQmx is using to read/write from/to the buffers. I must not mess with the AO process, but I need the AI to "catch up" with the AO.  

Ideas?

Thanks,

Van

[HollyBerry]

Hi Van,

How do you have your tasks set up? Do they share a sample clock? Are there any triggers?

If they are synchronized on the same sample clock, you could try to do the read off a trigger from the AO measurement. You can also set delays in your trigger in order to create the phase you would like. 

This white paper has a lot of information about synchronization with DAQmx. It's quite lengthy so I would recommend skimming it to find the parts that are relavent to your setup.