USB-6008 OEM Hanging Up, Freezing Randomly in Windows 7

[ssteiner4]

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.  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).  I observe that when this happens at least one of the DAQs has spontaneously hung up (blinky LED is off) and outputs no more readings.  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 or on a separate machine running Windows XP with DAQmx 9.2.2 using all of the same DAQ-connected hardware.  I have tried using DAQmx 9.3 and DAQmx 8.9.5 on the Windows 7 Home Premium 64-bit Lenovo IdeaCentre and get this disconnecting then freezing behavior.  I'm not sure if this is a problem with  DAQmx or what but

- It's not the hardware

- It is not the program I'm running (working in Windows XP on two machines even with DAQmx 9.2.2, 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 or how DAQmx interacts with Windows 7

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

[ssteiner4]

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.  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).  I observe that when this happens at least one of the DAQs has spontaneously hung up (blinky LED is off) and outputs no more readings.  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 or on a separate machine running Windows XP with DAQmx 9.2.2 using all of the same DAQ-connected hardware.  I have tried using DAQmx 9.3 and DAQmx 8.9.5 on the Windows 7 Home Premium 64-bit Lenovo IdeaCentre and get this disconnecting then freezing behavior.  I'm not sure if this is a problem with  DAQmx or what but

- It's not the hardware

- It is not the program I'm running (working in Windows XP on two machines even with DAQmx 9.2.2, 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 or how DAQmx interacts with Windows 7

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

[Joe_S]

Hello ssteiner4,

Thank you for posting, I can see how this issue would cause frustration.  It sounds like you have tried a lot of steps in troubleshooting already, so let me get a little more information before we proceed with more troubleshooting.

First, you said that you can control the digital I/O on the device from Measurement & Automation Explorer, but the analog input fuctions and "Reset Device" fail.  If there is an error message that pops up, could you provide a screenshot of that error?

Second, could you create and provide a MAX Technical Report? (Go to File » Create Report... , then select Technical Support, and follow the dialog)

Third, I do not believe that the DAQmx driver version 8.9.5 will support Windows 7.  I would recommend sticking with the latest version, which should be 9.3.

Also, I don't know if you said you tried this or not, but did you test the program with the card plugged directly to the computer?  It may help to remove the "middle man", aka the USB Hub.  Let me know.

Regards,

Joe S. 

[Metal]

I am having a similar issue as well, though I only get freezes when I reset the hardware using NationalInstruments.DAQmx.Device.Reset(). This does not on any Windows XP machine, and actually, it works on every Windows 7 machine I've tried it on except for two Samsung laptops we use for demos. We were using the 9.5.2 driver in the past, but on these particular laptops, this call was causing a BSOD every time, so we updated to 9.6, which now causes the hanging issue on the same call.

I was able to fix the issue for a short time by updating the chipset driver, but after a few minutes, our software started hanging again on the Reset function. It was at this point that I realized both PCs that were having issues were Samsungs, and after further investigation, it looks like both laptops use the same Intel chipset and same USB controller. So I'm thinking (I cannot confirm this though without the help of NI) that perhaps there is an incompatibility between DAQmx and this particular Intel chipset or the USB controller

Here are my relevant hardware specs:

Chipset: Intel(R) 6 Series/C200 Series Chipset

USB Controller: Intel(R) 6 Series/C200 Series Chipset Family USB Enhanced Host Controller

Please let me know what I can do to get this fixed. This is not a problem with our code, and for some reason my device serial numbers will not get me direct support, so I am turning to the forums for assistance on this matter.

[Jarryd]

I am currently running into the same issue. Also running a Windows 7 environment.

I would like to know whether there has been a solution to this problem.

Your assistance would be greatly appreciated.

[amcmahon]

I believe I am also encountering this problem; the symptoms match exactly what is described.  Our setup is using an OEM USB-6343 with Windows 7 64-bit and the latest DAQmx drivers (9.7).  The PC has an Intel DH77DF motherboard, so most likely a similar/related USB controller to the Intel one mentioned above (I'm not at that PC to check specifically at the moment).  I am going to try operating on a different machine on Monday to try to confirm whether this is just a USB controller problem or if there's more to it.  Has anyone made and progress or have any recommendations for a workaround or fix?

Thanks much for any input!

[FixedWire]

had similar issues with the non OEM USB-6009 and ended up just moving up to a 6361 device. Not what we wanted at all.

[Eric-E]

Hello,

Although this may not solve everyone's issue, for best results the most recent version of DAQmx for your operating system is recommended. Here is a chart that outlines which OS corresponds to which DAQmx version. I hope this helps.
http://digital.ni.com/public.nsf/allkb/B0D5630C0A50D5C6862578E800459248?OpenDocument

[Sparkman2]

I have had a similar issue with a USB-6501 that I use to control an array of 36 relays using 8 DO lines. Recently, the relays stayed as instructed for over 15 hours until I started using my computer for other tasks. I am convinced that the issue is related to connecting the USB-6501 through a 7-port hub as I have monitored every other possibility and can find no other causes. I am currently running some additional tests with the 6501 plugged into the direct port of the computer and all seems stable so far. The communications loss is never long enough for the system to respond by indicating that the USB device has been disconnected such as when one would unplug the unit, but I have run out of other possibilities.

[FixedWire]

Ensure you are connected to the best port. USB 2.0 has different throughput standards. i.e. full, high etc

Manufacturers cheapen out on the ports many people will only run a mouse on the USB port, not a daq. I've seen the CPU go to 70-80% when the onboard controller couldn't handle the data coming in. At which point Windows will do what Windows wants.

[Siv2016]

Yes, I was having this problem too with the use of the USB-6008 DAQ, Labview2013 with the latest NIDAQ drivers and Windows 7 64bit OS. Since Labview was running in a rough-EMF environment(several 2-5 HP 240VAC motors frequently turning on and off), I figured it was a transient-induced problem. But it wasn't. After much experimentation with trying to clean up the local electrical environment, I turned to the USB-6008 and how it connects via USB 2.0 to the computer. In this case, the Windows 7 64 bit computer contains a Gigabyte GA-X58A-UD3R motherboard that utilizes an Intel LGA-1366 processor. Almost all of the USB ports on this motherboard are connected to the Intel ICH10R Southbridge chip, but fortunately this motherboard comes with two NEC/Renasas USB 3.0 ports that are instead connected directly to the PCI buss, not the ICH10R Southbridge. I tried unchecking the 'allow the computer to turn off device to save power' checkbox in the adjustments one can make to the USB Root Hub that services the 18 Intel USB ports through the ICH10R Southbridge - a suggestion that others have made that worked for some folks, but didn't for me. However, plugging the USB-6008 NIDAQ into the NEC USB 3.0 port solved the freeze-up problem. My guess is that using a NI PCI based DAQ card would have worked too, because it too would have avoided using the ICH10R Southbridge, but that was not an option, not having such a device locally to use. Why the combination of Windows 7 64 bit OS and the use of Intel USB 2.0 ports connected to the Southbridge turned out to be a troublesome combination for the USB-6008 is unknown, at least to me, but if you are having similar freeze-up problems with NI USB-based DAQs, then you might want to look into finding another way to connect your NI USB device to your computer other than through the USB ports connected to your computer's Southbridge, especially if Windows 7 64 bit OS is in the mix as well. Possibly the use of a PCI-based USB card would be something pretty easy and inexpensive to try...