USB 6009 overflow error on continuous mode after restart of VI

[Danfromsb]

I just realized I misspoke on an earlier comment.  The Dell desktop is a T1500 not a T3500.

[Sampler]

Jim_S,

I've got two USB 6009 OEM boards, one inside a small Intel Atom machine, and another one hooked up to my Dell Latitude E6500.

My laptop is running Windows 7, the Atom machine is running Windows XPe. Both are using the exact same version of the DAQmx software.

On my Latitude, the test panels lock up immediately when I start capturing continuously  at 48000Hz (regardless of the samples per cycle), on my Atom machine the test panels *seem* to work fine at 48000Hz, but if I plug a USB CD-Rom drive into the machine while it's running my application it throws that internal buffer exception and corrupts the state of the driver (my software cannot recover from that exception).

I'm perfectly fine with it throwing an exception (I understand that if the USB bus is busy, it has no choice but to run out of internal memory), but this particular exception cannot be recovered from. Attempts to stop the tasks or reset the device all seem to block indefinently -- and that is the problem.

Also, Just as a note, the Latitude is running on AC power, and I've tried a couple different USB cable lengths (one of which was about 2' in length), and the USB ports are 2.0 or higher.

[Sampler]

Oh, one more thing to note, I'm using the latest (since last Monday, I think) version of the NI-DAQmx software (NIDAQ922f0.exe).

[Jim_S]

Hello Sampler,

I have some questions or things you can try about both machines. I have broken them up below to make it easier to look at.

Dell Latitude E 6500 Questions:

1.) Have you tried the same USB-6009 on both machines to ensure that we don't have a problem with the 6009?

2.) Have you tried the taking a lower sampling rate on this machine to see if you can get any sampling rate to work? This would be a good test to see if the driver or software is giving you problems.

3.) Have you tried different USB ports?

4.) Have you tried using a USB memory stick or something to see if it can access these?

Atom Machine:

When the error occurs with the USB CD-ROM drive is plugged in, have you tried removing it to see if you can then access the USB-6009? I am pretty sure that the CD-Rom is taking over the bandwidth of the bus and completely shutting out the USB-6009. Since the USB-6009 is trying to send data at the same time, it could put the hardware in a bad state to insert the CD-Rom driver when acquiring data.

[Sampler]

>> Dell Latitude E 6500 Questions:

>> 1.) Have you tried the same USB-6009 on both machines to ensure that we don't have a problem with the 6009?

No. I'll guess I'll have to try that next. I believe the issue is the same on both boards, but since I can immediately see the error in the test panels on MAX, this would be a quick way to rule out a hardware defect.

>> 2.) Have you tried the taking a lower sampling rate on this machine to see if you can get any sampling rate to work? This would be a good test to see if the driver or software is giving you problems.

I can get it sampling at a lower rate; it works at 40000, I think even 42000. But for how long? I've had it lock up (from a DaqException) while sampling at 8000 (but not in the test-panel).

>>3.) Have you tried different USB ports?

Yah. I had been switching between the two on the right side of this laptop, and just tired it with some of the USB ports on the left side.

>>4.) Have you tried using a USB memory stick or something to see if it can access these?

Ooops, I didn't mean to imply that the USB-CDROM causes the exception every time. The test panel test @ 48000Hz DOES cause a lockup 100% of the time, but inserting a USB device doesn't cause a lockup 100% of the time (on neither the laptop nor the atom box). Right now I can't remember if it was the Latitude or the Atom board that threw immediately after the insertion of the USB device.

>>Atom Machine:

>>When the error occurs with the USB CD-ROM drive is plugged in, have you tried removing it to see if you can then access the USB-6009? I am pretty sure that the CD-Rom is taking over the bandwidth of the bus and completely >>shutting out the USB-6009. Since the USB-6009 is trying to send data at the same time, it could put the hardware in a bad state to insert the CD-Rom driver when acquiring data.

I'm going to do a 24h test on the Atom board right now to make sure what I'm telling you is accurate (about which box is doing what), because it may have been the Latitude machien that locked up when the USB-CDROM was inserted.

[Sampler]

>> Dell Latitude E 6500 Questions:

>> 1.) Have you tried the same USB-6009 on both machines to ensure that we don't have a problem with the 6009?

No. I'll guess I'll have to try that next. I believe the issue is the same on both boards, but since I can immediately see the error in the test panels on MAX, this would be a quick way to rule out a hardware defect.

>> 2.) Have you tried the taking a lower sampling rate on this machine to see if you can get any sampling rate to work? This would be a good test to see if the driver or software is giving you problems.

I can get it sampling at a lower rate; it works at 40000, I think even 42000. But for how long? I've had it lock up (from a DaqException) while sampling at 8000 (but not in the test-panel).

>>3.) Have you tried different USB ports?

Yah. I had been switching between the two on the right side of this laptop, and just tired it with some of the USB ports on the left side.

>>4.) Have you tried using a USB memory stick or something to see if it can access these?

Ooops, I didn't mean to imply that the USB-CDROM causes the exception every time. The test panel test @ 48000Hz DOES cause a lockup 100% of the time, but inserting a USB device doesn't cause a lockup 100% of the time (on neither the laptop nor the atom box). Right now I can't remember if it was the Latitude or the Atom board that threw immediately after the insertion of the USB device.

>>Atom Machine:

>>When the error occurs with the USB CD-ROM drive is plugged in, have you tried removing it to see if you can then access the USB-6009? I am pretty sure that the CD-Rom is taking over the bandwidth of the bus and completely >>shutting out the USB-6009. Since the USB-6009 is trying to send data at the same time, it could put the hardware in a bad state to insert the CD-Rom driver when acquiring data.

I'm going to do a 24h test on the Atom board right now to make sure what I'm telling you is accurate (about which box is doing what), because it may have been the Latitude machien that locked up when the USB-CDROM was inserted.

[Sampler]

>> 2.) Have you tried the taking a lower sampling rate on this machine to see if you can get any sampling rate to work? This would be a good test to see if the driver or software is giving you problems.

[Sampler]

I can get it sampling at a lower rate; it works at 40000, I think even 42000. But for how long? I've had it lock up (from a DaqException) while sampling at 8000 (but not in the test-panel).

[Sampler]

Hmm, this isn't good...

I borrowed a board from our lab (same board, USB 6009 OEM) that was being used on Window XP on an old version of the NIDAQmx software (I think 8.7?). On the laptop in our lab, MAX's test-panels could sample at 48000Hz.

I took the board over to my Latitude E6500 (Windows 7 64-bit) started up MAX and tested it, and could not get it to sample at 48000 (lower sampling rates (around 40000) worked though)). So it worked on Windows XP but not on Windows 7.

Now here's the problem, when I gave the board back (to be ran on Windows XP), it no longer sampled at 48000.

I think when my Latitude E6500 said it was installing drivers for the board, it updated the firmware on it. Is this true?

[bmkessler]

Hi,

I thought I would check in to see about the updated progress on this problem.  No progress on my end getting the Dell Vostro working.

I also was somewhat confused when the Windows 7 plug-and-play installed the 6008 driver and "USB firmware loader."  Is that supposed to occur everytime the device is detected?  Can I manually update the firmware on the board?

Regards,

Brian

[Sampler]

I just tried the board on my atom XPe machine (it has the same version of the NIDAQ as the board would have updated to), and it still didn't work.

This is very weird because the board that's already on the atom machine is able to start sampling at 48000.

[Sampler]

After letting the little atom machine run over night, I checked on it this morning to find the system completely locked up (couldn't even move the mouse).

I'm going to let it run over the weekend in the Test Panels to show (indisputably) that the driver is simply no good on any of the machines so far.

Just a note: There isn't any power savings mode on this build of XPe that I put togethor -- hibernation is disabled, HDD and monitor poweroff are disabled, and there's not even a firewall.

[Sean_F]

Hi Brian,

The 6008 should automatically update it's firmware. If you look under device manager, you should see it under Data Acquisition Devices. If it has an exclamation mark, right click and select update driver » browse my computer for driver software » let me pick from a list of device drivers on my computer » USB-6008. Also, what sampling rates fail for you? The USB 6008 is only spec'd at 10 KHz.

Sampler, rather than use Test Panels to acquire data for such an extended period of time, have you had any success using a shipping example in labVIEW?

As for everyone else having problems with some Dell PCs in Windows 7, I'm going to escalate the issue to R&D to see if they make any further recommendations.

Best,

Sean F.