buffer overflow conditions

[dmacg]

I am working on a Macintosh running OSX 10.9.x (Mavericks) to be compatible with the current drivers for Macintosh (I am using NIDAQmxbase 15.1). I have an application that is receiving one channel of data at 33 kHz from an USB-6009 device. Every so often, the background task that is handling the DAQ task of reading (using DAQmxBaseReadAnalogF64 to transfer data), gets an error from DAQmxBaseReadAnalogF64 of -200361. This error is described as a buffer overflow error but I am confused as to which buffer is overflowing. One description indicates that it is the device’s on-board data buffer but other descriptions point more to it being the DAQtask’s computer memory (circular) buffer. Which does it refer to?

If it is the device’s on-board memory, is there a command that rapidly clears the device’s on-board memory so that I can intercept the error condition, clear the internal pointers that manage the device’s memory and probably let the DAQtask know that it may re-read the device data stream? (without re-starting the DAQtask itself, which would work but is slow).

If it is the DAQtask’s input buffer memory, how may I clear this error condition and continue with acquisition? (again, without re-starting the DAQtask).

I notice that there is a command, DAQmxSetReadOverWrite, that provides a means to disregard overflows associated with the DAQtask’s input buffer. My application linker doesn’t seem to understand this command (meaning that it generates a linker error during compilation). Is it not relevant to the 6009?

As a side question, on a Mac with 4 CPUs: if my application’s delegate is on the main thread (1 CPU), and it uses a background task (on a requested second CPU) that manages the DAQtask-reads, is the DAQtask itself running on another thread that uses a third CPU?

[crossrulz]

How often are you reading the data?  How many samples are you reading at a time?  Can you supply some code for us to debug?

[dmacg]

I have attached some code. A continuous DAQtask is setup and started outside of the acquisition loop. Then an application-based background task is started that contains the DAQRead command. Basically, the DAQmxBaseReadAnalogF64 command is reading 1000 samples each iteration of the background task so that with a sample time of 30 microseconds, it is 30 milliseconds worth of data. When the background task is completed, it triggers a routine in the app delegate that sets a flag that is checked by a repeating software timer running at a rate of once every 10 milliseconds (maybe this is a flaw?). The background task is complete at this point and therefore re-started as soon as timer routine detects there is waiting data.

It has been a few months since I wrote the code and because the overflow occurs only rarely (maybe once every 60 minutes of data stream, somewhat randomly), I have only just come back to the issue to troubleshoot. In writing this response, I sense some problems but I originally wrote the code to use a so-called pingpongbuffer within the background task so that the background task was only created only once and would post to the delegate when one of its two pingpongbuffers was ready. Because of the way Apple has changed how background tasks move messages, for reasons not clear to me, this didn't work stably. Thus the current solution, which I consider less than ideal.