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

[Chris-NI]

Hi Tom and Jim,

Currently, R&D has reproduced this same issue in LabVIEW, but they have not identified a root cause.  However, they found that the more often you call software reads, the longer it takes for the timeout to occur.  For instance, rather than reading 100 samples every second at a 100 Hz sampling rate, read 10 samples 10 times per second, or even 1 sample 100 times per second.  Of course, this does not prevent the timeout, it only delays it from happening.

If you need your test to run for a long time, hopefully there are certain periods of time where you can have brief pauses in data without missing critical information.  Perhaps you could programmatically stop and restart your task every x period of time at a known safe time when it is okay to miss a few samples.

We'll need to wait and see if R&D has a better work-around once they discover the root cause, but this is the best we have for now.  Ultimately, a driver update will need to be issued to correct this.

Keep an eye out for the next driver update as we will release which CARs were addressed in the driver readme.

Regards,

[ase-tom]

Hi Chris,

Thanks for the update. When would a new driver update come out? Are driver updates on a regular release schedule?

I appreciate your efforts and the efforts of the R&D group. I've already got a version of our software running as you described. It take a sample, restarts the cards, takes a sample, restarts the cards, etc. We were hoping to get a multi-threaded continuous sampling version going that could gather data, write it to disk, and display it to the screen without missing any samples. We have this multi-threaded version working with PCI 6210 cards using NIDAQmx and we were hoping to get the same results with the USB 6210 cards using NIDAQmxBase.

I'll keep an eye out for the new driver and hope the fix makes it out soon.

Thanks again,

-Tom

[dbell0971]

Hi Tom,

Chris will be out of the office for the next couple of weeks, so I'll step in and keep an eye on this issue.  Whenever R&D finds the source of this issue I'll be sure to let you guys know here.  

We don't have regular driver releases for our Linux drivers or for DAQmxBase; I'm also not sure when we have another update lined up for DAQmxBase. If I get any info from R&D about this issue or the release of a new driver, I'll post it here.  Feel free to post back here if you have any questions.

Thanks,

David B

National Instruments

Applications Engineer

[dbell0971]

Hi all,

I have heard back from our R&D developers for DAQmx Base and wanted to discuss their findings with you.

The error occurs when transferring data from the USB device to the user memory using DAQmx Base.  Due to this issue, it will not be possible to use USB DAQ devices at full speed with DAQmx Base.

Because this issue stems from the way DAQmx Base is architected, it will be difficult for our developers to fix, and currently there are no plans to implement a fix for this issue.  Our best recommendations right now are to either use a PCI device or to switch to a Windows machine.

Tom, it sounds like you’ve been able to make your application work with a PCI version of the 6210, will you be able to continue using PCI?

Thanks,

David B

National Instruments

Applications Engineer

[John_Amery]

Sorry to hear this news... I've been tracking this post since my USB-6211 has the same problem. It randomly stops at any point which is independently of any other parameters. I've tried to build up a histogram on how long it takes to stop and it turns out the deadtime is randomly distributed. 

-John

[Calmor]

David,

Does this only apply to sampling at full-speed? 

John - are you also running Linux, or do you have a Windows box?  The histogram analysis you mention is interesting...

[John_Amery]

Hi Jim,

I'm running on a MAC with the same problem. And yes I'm using the full speed with DAQmx Base.

-John

[Calmor]

Thanks John.  I'm curious too and have been following this as well, as I have an Ethernet NI cDAQ device running Windows, sampling far below the maximum rate, and still have these -200284 errors at what seems to be a random basis.  If I have a moment, I'll try to do an analysis of the timeouts and see if I have the same random distribution you're seeing.

[John_Amery]

Just to compare with someone else's setup: USB-6211, channel: AI1 and AI9 for differential mode, sample rate 250k (full speed), platform: MAC OS X, software: DAQmx Base with labview 8.5. With our test, the error-200286 shows up at sample rate lower than 1K. 

We also have a USB-6008 which can work well in this setup so it would be my guess that the problem may only exists USB-62XX or higher series. The PCI series may free from this error from previous threads.

-John

[John_Amery]

Maybe there is one way to make it work. Now I assume there is some problem in the data transferring between the DAQ and PC memory which as claimed is not fixable at this point. Then we can identify the error handling routines which in my case is DAQmx Base read and I believe it may apply to most cases in these threads. Put previous whole codes in a while loop and use the error-200284 as the condition (run continuously). So basically every time the DAQ crashes it restart again. As long as the timeout is relatively short, there is really no data missing during the process. If you dislike run continuously, you may add an upper level structure (a while loop, for example) and use some global variables to stop it. 

I've tested up to 1 hour and it works well:)

-John