LabVIEW
More 8451 lockups
Well, a 6year bump to an old thread....
Regaurdless, you need to suspect the USB connection itself.
Here is an old FAQ article I wrote after learning painfully how to keep reliable device connections
In this topic we will discuss some of the common problems that have been observed using USB devices with LabVIEW on Windows operating systems. Many of these points are also applicable to other environments but the examples will be use the Windows 7 OS.
FAQ 1 : My USB device stops working unexpectedly.
The first thing to look at is the OS power saving options. There is a global trend towards developing "Green" electronics and energy star ratings are getting fairly common. "If its not being used shut it off" is nothing new. Cavemen learned how to bank a fire to preserve energy that would otherwise be wasted. Likewise, the Windows OS has a power saving feature to shut down power to the USB hubs when no user activity is present. In Automated systems this feature can cause problems since removing USB hub power will shut down the USB device. Solution: Use the device manager to change the USB hub Power Options.
FAQ2: I set the power options and my device connection is still unreliable: Remember, those computer USB ports are often the cheapest that can be mounted on the chassis and share the PC system power supply to supply USB Power. Most uses of USB are temporary connections like a thumb drive or a camera. These connections do not require high reliability since the user is right there interacting with it. Power surges and fault tolerance at worst cause the operator to retry the data transfer. Automated systems require a bit more robustness. Solutions:
1) ALWAYS use an external self powered hub. Perform your engineering due diligence and inspect the devices specifications too- If you can't find them for that device that should clue you to seek an product from a vendor that WILL publish their specs.
2) High noise environments require the use of ferrites on the USB cable- and don't buy the cheapest cable either! The cheap ones are poorly shielded.
3) PROTECT the HUB connections- If you have a USB2.0 device and Joe User plugs in a 1.0 device in a open slot managed by the same hub- Bingo every port on the hub may back convert to USB1.0. WORSE there are a lot of damaged or marginally engineered USB devices out there. Joe User's device may cause power fluctuations when it is inserted or removed from the hub just don't let it happen!
FAQ3: I am testing USB devices and the OS can't find them anymore.
This is a Plug-n-Play feature that deserves some exposure. When you connect a P-n-P device the OS remembers its serial number in a HKEY (Hive-Key) registry entry. This is helpful when (for example) you want a specific instrument, Say an NI-USB-6008, to show up as a DAQmx Device with VISA Alias "MyDAQ1" every time it is plugged it. On the other hand, If you want to test a line of USB-Serial converters this can be problematic since the P-n-P driver will mount the first serial number as "COM3" and the next as "COM4" add infinitum until the enumerator controller in the registry and VISA recognized aliases get used up. Solution: Use the Windows registry API and the Hardware Configuration API in LabVIEW to clear unused VISA Aliases and HKEY entries. Speak with your staff IT professional about HKEY structure and possible side effects before developing a plan to edit registry entries.
Jeff·Þ·Bohrer escribió:
Well, a 6year bump to an old thread....
Regaurdless, you need to suspect the USB connection itself.
Here is an old FAQ article I wrote after learning painfully how to keep reliable device connections
In this topic we will discuss some of the common problems that have been observed using USB devices with LabVIEW on Windows operating systems. Many of these points are also applicable to other environments but the examples will be use the Windows 7 OS.
FAQ 1 : My USB device stops working unexpectedly.
The first thing to look at is the OS power saving options. There is a global trend towards developing "Green" electronics and energy star ratings are getting fairly common. "If its not being used shut it off" is nothing new. Cavemen learned how to bank a fire to preserve energy that would otherwise be wasted. Likewise, the Windows OS has a power saving feature to shut down power to the USB hubs when no user activity is present. In Automated systems this feature can cause problems since removing USB hub power will shut down the USB device. Solution: Use the device manager to change the USB hub Power Options.
FAQ2: I set the power options and my device connection is still unreliable: Remember, those computer USB ports are often the cheapest that can be mounted on the chassis and share the PC system power supply to supply USB Power. Most uses of USB are temporary connections like a thumb drive or a camera. These connections do not require high reliability since the user is right there interacting with it. Power surges and fault tolerance at worst cause the operator to retry the data transfer. Automated systems require a bit more robustness. Solutions:
1) ALWAYS use an external self powered hub. Perform your engineering due diligence and inspect the devices specifications too- If you can't find them for that device that should clue you to seek an product from a vendor that WILL publish their specs.
2) High noise environments require the use of ferrites on the USB cable- and don't buy the cheapest cable either! The cheap ones are poorly shielded.
3) PROTECT the HUB connections- If you have a USB2.0 device and Joe User plugs in a 1.0 device in a open slot managed by the same hub- Bingo every port on the hub may back convert to USB1.0. WORSE there are a lot of damaged or marginally engineered USB devices out there. Joe User's device may cause power fluctuations when it is inserted or removed from the hub just don't let it happen!
FAQ3: I am testing USB devices and the OS can't find them anymore.
This is a Plug-n-Play feature that deserves some exposure. When you connect a P-n-P device the OS remembers its serial number in a HKEY (Hive-Key) registry entry. This is helpful when (for example) you want a specific instrument, Say an NI-USB-6008, to show up as a DAQmx Device with VISA Alias "MyDAQ1" every time it is plugged it. On the other hand, If you want to test a line of USB-Serial converters this can be problematic since the P-n-P driver will mount the first serial number as "COM3" and the next as "COM4" add infinitum until the enumerator controller in the registry and VISA recognized aliases get used up. Solution: Use the Windows registry API and the Hardware Configuration API in LabVIEW to clear unused VISA Aliases and HKEY entries. Speak with your staff IT professional about HKEY structure and possible side effects before developing a plan to edit registry entries.
Hi We are having problems with this module, it was working well during the last year, but currently is failing hanging out the application, then is necessary unplug and plug again, others close the LabVIEW application and others restart NIMax or restart the computer, it has been painful, because it is used in line running 140 units per hour.
We have tried different computers, windows XP, Win7 and Win10, NIMax version 13 and 15, Drivers for NI8451 (different versions) but still the same (The software is under LabView 2013.)
As clue when it start communication, fail like the I2C data can't be retrieved, it fail showing error -301708 on function "NI 845x I2C Run Script.vi :6110001"
