Problems with buffer overflows (-200361) on NIDAQmxBase

[darrenh]

Hi all,

I am rather new to NI and have run into a frustrating issue. We are developing an application which will run on Linux and sample data from a USB-9215A at 50kS/s (this is an ideal rate for the project and about half the device capability). The inital development was done in Windows (by our partners) using NIDAQmx and utilises callbacks to read the data when the buffer is ready. This works fine. However while porting it to Linux we discovered we can only use NIDAQmxBase. We can only do continuous reads in a loop with this driver and now we have -200361 device buffer overflow errors! The Linux system is running minimal services and has a cpu load of <5%. From reading other posts this appears to be not uncommon. It would seem development of NIDAQmx was discontinued for non-Windows OS's.

Is this the case?

The Base version appears to quite "crippled" in comparison.

Darren

[Dan_K]

Hello Darren,

DAQmx Base is a cross platform driver intended to allow for development across multiple OSes. It is true that it does not have the same depth of functionality as DAQmx, but this is offset by it's ability to work in a variety of operating systems.

Now, in terms of your error, I thin kit would be best to take a look at the code you are currently using. This type of error most commonly occurs due to improperly defining the read buffer or not pulling enough samples off of the device per loop iteration. A good first step would be to run a piece of example code that ships with the driver without changing any of the hardware settings.

Since I do not know which ADE you are using I will direct you to where you can find the relevant example in LabVIEW and C API.

In the LabVIEW Example Finder:


For the C API (in Windows):


Please let me know if you have any problems with running these examples or if you have any further problems using the USB-9215A in DAQmx Base.

[darrenh]

Dan_K,

Thanks for quick response. We are using the C API for this project. The contAcquireNChans.c in the examples runs fine. However it is using 5000S/s. Our code runs fine at this rate too. If we increase the sample rate to 50kS/s in the example code it fails periodically with the -200361 error as well (not as often as our code though). I noticed the input buffer in the example is created 100 times larger than the samples/chan to read.

Is there a rule of thumb for determining the optimal size of the input buffer?

We were able to reduce the instances of the error in our code by keeping the sample rate at 50kS/s but reducing the samples read per call of the readAnalogF64 function. The cost here is the cpu utilisation increases. This may be adequate for our needs but it's certainly not ideal. For the record the test machine has a 1.5GHz core2duo/1GB ram running Linux kernel 2.6.26 SMP.

Darren

[Dan_K]

Hello Darren,

The key here is to keep your loop rate fast and to read small groups of samples. I would recommend trying to read 500 samples per iteration and to set up a buffer (in the DAQmxBaseTiming function) of 2000 samples at least. This would give you some leeway for responding to other tasks or user interaction without causing an immediate buffer overflow.

This would entail reading your data and placing it into some sort of queue for processing in a separate thread. This is important as you will need to keep your loop iteration time at 1 ms or less (preferably less to reduce single processor use).

[darrenh]

We had spent some time tinkering with the samples/channel parameter over the last couple of days, we are presently reading in blocks of 500 as it happens. This resulted in us successfully reading about 98% of samples without the error occurring. We were then able to reliably achieve 100% by tweaking some thread scheduling parameters.

Thanks for your help.

Darren