USB 6210 times out with 200284 on RHEL5 using nidaqmxbase 3.6 while trying to sample continuously.

[ase-tom]

I'm trying to sample four USB 6210 devices that are attached to a Red Hat Linux 5 laptop that has nidaqmxbase 3.6 installed. Continuous sampling works for a varying period of time and then eventually one of the USB devices times out. I've attached the modified NI example program.

Here's the results of running the program:

$ time ./contAcquireNChan
Example will halt automatically.
1Asked for 2048 points, Acquired 2048 samples. Total 2048
data0[0] = 1.238437    data1[0] = -1.036236
2Asked for 2048 points, Acquired 2048 samples. Total 4096
data0[0] = 1.739391    data1[0] = 0.098561
3Asked for 2048 points, Acquired 2048 samples. Total 6144
data0[0] = 1.120739    data1[0] = -0.881173
4Asked for 2048 points, Acquired 2048 samples. Total 8192
data0[0] = 1.735681    data1[0] = 0.118811
1Asked for 2048 points, Acquired 2048 samples. Total 10240
data0[0] = 0.131031    data1[0] = 0.130702
2Asked for 2048 points, Acquired 2048 samples. Total 12288
data0[0] = 0.063706    data1[0] = 0.064035
3Asked for 2048 points, Acquired 2048 samples. Total 14336
data0[0] = 0.157415    data1[0] = 0.156758
4Asked for 2048 points, Acquired 2048 samples. Total 16384
data0[0] = 0.059962    data1[0] = 0.059304
    .
    .
    . More of the same
    .
1Asked for 2048 points, Acquired 2048 samples. Total 17057792
data0[0] = 0.124124    data1[0] = 0.123795
2Asked for 2048 points, Acquired 2048 samples. Total 17059840
data0[0] = 0.060089    data1[0] = 0.059760
3Asked for 2048 points, Acquired 2048 samples. Total 17061888
data0[0] = 0.155772    data1[0] = 0.148870
4Asked for 2048 points, Acquired 2048 samples. Total 17063936
data0[0] = 0.058318    data1[0] = 0.058318
1Asked for 2048 points, Acquired 2048 samples. Total 17065984
data0[0] = 0.122808    data1[0] = 0.122808
2Asked for 2048 points, Acquired 2048 samples. Total 17068032
data0[0] = 0.060746    data1[0] = 0.061733
DAQmxBase Error -200284: <err>Some or all of the samples requested have not yet been acquired.

To wait for the samples to become available use a longer read timeout or read later in your program. To make the samples available sooner, increase the sample rate.

real    2m53.456s
user    0m32.001s
sys    0m8.689s

Is continuous sampling of USB-6210 devices supposed to be possible? Any suggestions for what to do to fix this?

Any suggestions would be appreciated.

Thanks,

-Tom

[dbell0971]

Hi ase-tom,

Here is a detailed description of the 200284 error and possible causes:

Why Do I Get Error -200284 from my DAQmx Read VI?

It seems odd though that it would acquire 17000+ samples before timing out, does it timeout after the same number of samples every time?  I've also seen this error thrown in underflow cases.  

Thanks,

David B

National Instruments

Applications Engineer

[Calmor]

I'm having the same timing out issue with an Ethernet device - the 200284 errors occur occasionally but not regularly enough to troubleshoot.  I just wrote another post.  I meet all of the timeout criteria by a factor of 100 and still sometimes get this error.  I'm using Measurement Studio, with a task built in MAX, using NI's sample code, and memory optimized asynchronous reads.  I'll sometimes get 100,000 samples before it flags the error, sometimes 1,000 samples.  It always at least starts up and runs.  I need 10 samples at 100Hz sample rate, and the test needs to run for 5 hours at least. 

It's been driving me nuts for a while. 

The one oddity I did find in troubleshooting was that in MAX, running 99 samples at a sample rate of 100Hz and a timeout of 1s, I did get a 200284 error after about 15 minutes of operation for seemingly no reason on a virtual (simulated) DAQ device.  It almost seems to be just a random occurrence, but it stops the task and causes me to reset my test program.

[ase-tom]

Hi David B.,

Thanks for the 200284 error list. I've gone through this list before I posted and I didn't find anything that explained my problem.

The clock being used is the internal clock, so that shouldn't be causing the timeout.

The timeout is 10 seconds which is a huge amount of time to allow the device to get 2048 samples per channel.

The device is set to scan at the maximum rate for the number of channels selected.

The timeout is random. It has happened after a few minutes to as long as 30 minutes when using this test case. The real program that I'm using times out much, much faster - usually on the order 10 scans or less. The reason I posted the program that takes longer to timeout was to illustrate that this problem is happening using a National Instruments provided sample program that was modified to run with four USB devices rather than the original single USB device. If it happens with sample programs, it doesn't seem to be a product of my specific program.

The rest of the debugging suggestsions seem to be Windows specific which are much help since I'm running Linux.

I'm not sure where to go next since this seems like a pretty simple program.

Any additional help would be much appreciated.

Thanks,

-Tom

[Calmor]

For me, it seems to be an issue with the DAQ driver code or some communications issue.  I agree that the events appear to happen randomly.

This weekend we ran two tests:

Test 1:

1-hour duration

10 samples on 17 channels, continuously sampling

100 samples per second (should optimally achieve 0.1s per sample group)

Timeout set to 10 seconds (100x optimal sample period)

We had three -200284 errors during this test, had to restart the test each time.

Test 2:

5-hour duration

10 samples on 18 channels, continuously sampling

20 samples per second (should optimally achieve 0.5s per sample group)

Timeout set to 10 seconds (20x optimal sample period)

We had zero -200284 errors during this test.  This is highly uncommon.

I am on Windows but am also using the NI sample code, almost direct copy-and-paste, for asynchronous (threaded) sampling in Measurement Studio.  PC never exceeds 40% CPU utilization.

I'm starting to wonder if the timeout could occur if the data on one channel doesn't change at all throughout the sample period, and is therefore considered incomplete.

Until I can solve this with NI, I'm going to attempt to code the software to kill and restart the task gracefully.  I'm thankfully in a position where missing a little bit of data will not cause major problems (monitoring the operation of an HVAC unit, where things change very slowly).  I'm already sampling overkill at 2 to 10 groups of 10 samples per second.  If you're logging 2048 samples per channel, it doesn't sound like you're in the same position.

Jim

[ase-tom]

Hi Jim,

I appreciate that you are having difficulties too, but unfortunately for my target application, missing scans is unacceptable so I will not be able to restart the tasks to solve the problem.

Continuous sampling is supported by this device, but it just doesn't seem to be working consistenly.

-Tom

[Calmor]

Hi Tom,

It's unfortunate that you're not in the same boat, but I'm also following the answer to this story closely; restarting the task is a very hackish workaround and won't be very graceful.  My cDAQ also supports continuous sampling, and I'm not even close to stressing its theoretical limits, so I'm not happy with having to cobble together something that sort-of works.

I run Linux at home but unfortunately not at work, and am curious about your setup.  Is the DAQ code done in C++?  Is your software all terminal-based or did you do a GUI frontend for it?

Thanks!

Jim

[ase-tom]

Hi Jim,

Yes, my real application is C++ and terminal based, no GUI front-end. It is just meant to sample the data as fast as possible and write it out to disk without missing any scans.

-Tom

[Chris-NI]

Hi Tom and Jim

Just to rule out a simple case, can you both confirm for me that you are not running your application through a virtual machine?

One troubleshooting step that may help is to perform an I/O trace, which may catch if something strange is happening in the driver calls:

I/O Trace in Windows

I/O Trace in Linux

I've looked over your code and it does seem quite straight-forward.  I am leveraging some resources here to try to get ahold of a Linux box where I can try to reproduce this with four 6210s so that our R&D team may investigate this behavior further.

I will update when I know more.

Regards,

[Calmor]

Chris,

Thank you for your help!  I can confirm I am running on a native install, no virtual machines.  My setup is different, but I'm getting the same results. 

I will certainly investigate using I/O Trace to see if I can pinpoint the causes of these errors.  I appreciate the links.

Jim