Analog data acquisition with NI USB 6008 stalls on some Windows7/x64 machines

[Ray 2]

Hi,

we have built a product around the NI USB-6008 OEM. The device is controlled by our application (written in C) through the DAQmx driver (version 9.2.2). Recently, we are seeing problems when the application executes on particular Windows7/x64 machines or when the NI USB-6008 is connected through an USB hub.

Based on our application I have written a test program which shows different results depending on the PC platform and whether a USB hub is used or not. The test program and the complete result files are attached to this post.

We see following behavior:

1) Desktop PC Windows7/x64, no USB hub

The program works correct. Also, if the test program is started multiple times in a row no errors occur.

2) Desktop PC Windows7/x64, Dell Monitor 2408 WFP as USB hub

The test program fails. Although the actual data acquisition works, a following call to DAQmxStopTask() fails with the error -50405:

...

Call GetRealSamplesAvail() after reading samps

GetRealSampleAvail result: 0

Calling  DAQmxStopTask()

DAQmx Error: NI Platform Services:  No transfer is in progress because the transfer was aborted by the client. The operation could not be completed as specified.

Task Name: _unnamedTask<0>

Status Code: -50405, Read voltages  (DAQmxStopTask), -50405

If the test program is started again it hangs in DAQmxResetDevice(). The function DAQmxResetDevice() returns with the error -50405 when USB is unplugged.

3) Desktop PC Windows7/x64, USB hub (EXSYS EX-1177, www.exsys.ch)

Same behavior as in 4)

4) Dell notebook Latitude E6410, Windows7/x64

Usually, after an USB enumeration the test program works correct. In most cases however, the second or third call of the test program (after an USB enumeration) fails. We get a timeout since DAQmxGetReadAvailSampPerChan() reports zero as the number of available samples. It seems that the data acquisition process has not been started correctly.

…

Task is in complete state, ok

Calling DAQmxStartTask()

AcquireAInWhenAvailable()

Calling GetRealSamplesAvail()

GetRealSampleAvail result: 0

Calling GetRealSamplesAvail()

GetRealSampleAvail result: 0

.. and so on till timeout (see i<tmax_ms/200)

If the test program fails all following runs will fail as well. The only way to recover is to unplug USB.

We have not seen any problems on Windows XP.

For failure 2) (monitor hub) there is the workaround to directly connect to the PC. Therefore, we could live with this behavior.

However, operating the device on a notebook (see 4) is a real issue, since most of our customers are going to upgrade to such a platform.

Has anyone an idea how we can operate reliably the USB 6008?

Thanks for your help

  Ray

[TSP]

Hello Ray,

I do not believe in a software problem within in your product.

It can be that the power supply by the USB hubs doen't ensure the 4.10 to 5.25 VDC and 80 mA, that are required for the USB 6008.

Hope this helps you!

Kind regards,

TobyS

[JSA]

I'm seeing almost identical symptoms on a USB-6008 device (OEM) we use in our products.  Different error codes, oddly enough, but it definitely seems related to going through a hub, in which case it works intermittently.  I had not until now thought to check under Windows XP (this is all under Windows 7) because the issue seemed external to the PC (i.e. the hub or cabling or NI device itself).

Have you gotten anywhere with this Ray?  I haven't poked around yet to see if anyone else is complaining.  I just saw this thread from Google.

[Ray 2]

Hi,

unfortunatelly, we have no solution at this point. We think that the problem is related to the USB  hardware (maybe driver?) in the mentioned DELL notebook. However, we have no proof.

When you search the forum you will find a few similar enties, I hope one of them will help

Cheers

  Ray

[rootabegax]

What a breath of fresh air to read this thread! I have been BANGING MY HEAD AGAINST THE WALL for the past week with a USB-6008 OEM plugged into a hub running on a Windows 7 64-bit machine giving me similar problems.  I am using a Visual Basic program that has worked fine performing multi-week measurements for years on a dozen different machines that has been freezing up on this Windows 7 configuration.  The program hard hangs within 0-20 min of starting up for periods of 20-30 sec with sub-second instances of responsiveness followed by more hard hang repeating over and over (force closing doesn't work).  The only solution to get the program responsive again has been to physically unplug the DAQ and plug it back in, after which everything works fine for a random amount of time until it happens again.  If the hang occurs and I manage to exit the program in the brief instances of responsiveness, restarting the program without physically unplugging and replugging in the DAQ puts the program back into the same hard hang state, again only responsive once the DAQ is unplugged.  Similarly, opening MAX to diagnose the DAQ I can see the DAQ is there and I can even control its digital IO ports, but analog input functions fail and so does "Reset Device". I find that the hard hang occurs at the point in my program when I call the DAQmxReadAnalogF64 function--calling with "DAQmxErrChk DAQmxReadAnalogF64" per the sample code I can't even get into the DAQmxErrChk subroutine before the system hangs--although immediately after the the DAQ is unplugged it will proceed on into this subroutine and generate a -50405 error, which I can't tell is coming from the DAQ seizing or from having unplugged the DAQ to unfreeze the system.  My program calls this function in a timer loop and has had no problem in the past.

I have done a mindnumbing parametric differential trial-and-error study to figure out what is causing this. I am using an Elecom 10-port hub with a 5-VDC 5-A power supply and have tried other power supplies and hubs.  I can guarantee that every device is getting more than enough access to power and proper voltage.

The following have no effect on the symptoms:

- Changing the hub to a different model

- Changing the hub power supply

- Changing the hub to another of the same model

- Removing the hub power supply

- Having other things plugged into the hub

- Having nothing else plugged into the hub

- Having another DAQ plugged in

- Not having another DAQ plugged in

- Changing the hub USB cable

- Changing the DAQ USB cable

- Switching out the USB-6008 OEM for another brand new USB-6008 OEM

The problem does not seem to be occurring on Windows XP running DAQmx 8.6 with all of the same hardware.  I am using DAQmx 9.3 on a Windows 7 Home Premium 64-bit Lenovo IdeaCentre.  I'm not sure if this is a problem with  DAQmx or what but

- It's not the hardware

- As far as I can tell it is not the program I'm running (never had the problem before and have spent the past 5 days ripping apart the program and trying various compensations to no avail)

- It might be DAQmx or a driver problem

- It might be a Windows 7 problem

NI folks PLEASE look into this further... I have no working solution and do not know where to turn, and it sounds like others are having some similar problems.

[dblok]

I'm having the same issue trying to run 5 USB-6008's on a D-Link USB hub on Windows XP.  Anyone from NI have an answer?

[rootabegax]

Hi dblok,

I do not believe your issue is the same as what we've been talking about in this thread.  Our problem is definitely isolated to Windows 7 with hub behavior.  Having five DAQs plugged into one hub draws a lot of power and is most likely the origin of your problem.  Make sure you have an externally powered hub and that your power supply can provide at least 2 A of current.  We found a ten-port USB hub that came with a 5 A power supply that worked for us.  Beware, not all hubs are high quality, and not all hubs come with a power supply large enough to power 5 DAQs.  For diagnostics, could you try to see how many DAQs do work on your hub before the problem starts?  Could you try two powered hubs plugged into two different ports on the computer?

Regards,

Stephen

[dblok]

I have a 7 port D-Link DUB-HZ hub with a 3A supply.  I did connect 2 of the 5 directly to the PC and I still had the same problem.  Once I connected all 5 into the PC and moved my keyboard/mouse to the hub, the problem went away.  I would leave the 5 connected to the PC, but eventually I was going to run 10 USB-6008's so definately needed a hub.

What was the model number of the 10-port hub you used?  Will I have better luck if I use a PCI card with expansion USB ports instead of the hub?

[rootabegax]

Hi dblok,

I would like to correct a previous statement:  it is believed that this problem is isolated to 64-bit Windows 7.

What version of Windows are you using?  Is it XP 64-bit or 32-bit?

You will likely have the same problem on our 10-port hub--the hub did not fix our problem (it fixed other power problems we had though).  The manfacturer is "Elecom", it is made and sold in Japan and about $100 but comes with a 5-A power supply.  We bought it through Amazon.

How are you using the DAQs?  Are you using LabView or your own software?  What tasks are you performing with the DAQs?

Our problem was exacerbated by the presence of three factors:

- Windows 7 64-bit

- A hub (any hub)

- Repeatedly opening and closing an analog read task

(We called this the "triangle of doom".)

Replacing Windows 7 64-bit with Windows XP 32-bit solved it for diagnostics as did removing the hub, but for the eventual application (where we needed both Windows 7 64-bit and hubs) we rewrote our software to open a continuous analog input streaming task and use an event-driven handler to extract the data instead of opening the analog input channel, reading the data, then closing the channel and repeating (although this approach works fine in Windows XP 32-bit with or without hub and in Windows 7 64-bit only if you aren't using a hub).

If you can use a PCI card instead of a hub, I think it's worth a shot.  At least in Windows 7 64-bit, there seems to be some issues with the way Windows performs 64-bit addressing of USB hubs, although most of these issues in principle have been addressed with hot fixes and BIOS updates from various manufacturers.

What version of DAQmx do you have installed, and have you updated your BIOS?  Have you tried another PC?

Regards,

Stephen

[dblok]

We are using XP 32-bit with LabWindows/CVI & NI-DAQ 9.2.3.  I am opening and closing an analog read task repeatedly which I am probably seeing a similar problem you were.

I have not tried updating the bios or running the program on another PC yet.  I may try this afternoon on my laptop.