LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

usb-485/4 loses communication, ports reassigned

I am running some devices using a USB-485/4 adapter.  The program (Labview 2012, Windows 7) reads and/or writes the devices once per second.

 

On two occasiions, the communication seems to stop; the values being read are wrong, but there is no error.  For instance, and oven that is holding at 100C and reading that on the Yokogawa controller in it, Labview is reporting to be at 74C.  

 

When I stop the program and try to restart, the program can't find the COM ports.  Using NI DaqMax, I see that the COM ports assigned to the USB-485 have changed -- i.e., they used to be COM11, 12, 13, 14 and became COM7, 8, 9, 10.  Resetting the COM port target in the Labview software the programs then ran fine again.

 

Later, rebooting the computer reset the device back to the original COM port assignments.  This has now repeated a few days later.

 

What is happening?

0 Kudos
Message 1 of 11
(5,773 Views)

Time to pull out the FAQ's againSmiley Very Happy


 

USB Plug-n-Play Devices (Windows)

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.

 


Pay especial attention to FAQ2.  Get the right HUB, and don't let "Joe User" start sticking his grubby phone charger (or what-not) in the system!


"Should be" isn't "Is" -Jay
Message 2 of 11
(5,764 Views)

Since Labview is reading these ports once per second this does not seem likely, does it?

0 Kudos
Message 3 of 11
(5,759 Views)

@Hoard wrote:

Since Labview is reading these ports once per second this does not seem likely, does it?


What doesn't seem likely?  That the OS goes green without giving a darn about processes other that user interaction? (It Will) That the HUB is potentially suscepted to power surges and or noise? or that someone can add or eject a PnP device that interupts communications?


"Should be" isn't "Is" -Jay
0 Kudos
Message 4 of 11
(5,754 Views)

The comment posted in the first reply was that the USB hub can go to sleep if not used; I would certainly be surprised if reading and writing once per second is counted as an unused condition causing it to go to sleep.

 

No other USB devices were plugged in or removed when the two probelms occured.  In addition to the USB-485/4, there are 3 USB cDAQ chassis each with 8 modules in use (also read/written once per second each).

 

The system has run for weeks at a time, but recently I have had these two instances of the USB-485/4 stopping, and a couple instances of one of the cDAQ units apparently losing communication -- might or might not be a related problem.

0 Kudos
Message 5 of 11
(5,738 Views)

As a previous poster implied, Windows may or may not feel that a continuously accessed port is "active".

 

Another possiblity might be along the lines of a problem I had, with a usb-485 port as described here

 

USB serial port changes comm number

 

Where the ultimate issue was with the motherboard's USB ports.

 

Good Luck!

Putnam
Certified LabVIEW Developer

Senior Test Engineer North Shore Technology, Inc.
Currently using LV 2012-LabVIEW 2018, RT8.5


LabVIEW Champion



0 Kudos
Message 6 of 11
(5,724 Views)

The problem continues and has gotten worse.  We have tried a number of things.  Here is an update:

In a large application, a furnace controller (Yokogawa) communicates with Labview via a USB-485/4 adapter.  Although this has been in use for several years and used to run reliably for as long as a week, recently we get loss of communication after a few hours running.  When this happens, we get error 1073807360 “unknown system error” at 0xBFFF0000 when trying to write a command to the controller. This has happened with two different USB-485/4 modules, and with the USB-485 adapter plugged in to different USB ports (one on a 4-port PCI card, one on the computer motherboard).

When this has happened, I have tried to reset the USB-485 box by unplugging its power; this did not allow communication to resume.  I also tried unplugging the USB cable from the USB-485 box and replacing it; this causes Labview to stop working; all modules report “Not Responding”, and I have to force the programs to close.  After doing so, I opened NI-MAX.  It reports the USB-485 device is present with 4 ports.  However, looking under Serial and Parallel the port used for the Yokogawa communication is not listed.  The USB-485 lists the 4 ports at COM5, COM6, COM3, COM4 (in that order); the serial and parallel section shows COM3 and COM4 but not 5 and 6. 

Rebooting the computer allows all the programs to run again.

Another issue is present, and may or may not be related.  We are running 3 cDAQ units (temperature, voltages, currents) that communicate via USB.  There is a 4-port USB PCI board in our host computer; 3 ports run the cDAQs, 1 normally runs the USB-485 adapter.

Our main program has a one second timed loop (execution takes ~450 msec) and in each loop reads the buffer contents of each cDAQ.  The cDAQs are initialized to take continuous data at 2 Hz.  Each loop they are read with “-1 samples” – i.e., to read all data in the buffer.  On most loops I get two data samples per channel as expected.  Occasionally I get 4 samples; presumably a slow main loop.  On some cycles, one of the cDAQs (which one varies) will return no data (NaN in all values).  This should never happen since we read once per second on a two hertz sample.

0 Kudos
Message 7 of 11
(5,574 Views)

We replaced the USB PCI card, and the problem of lost communication is gone.  Apparently it was a USB problem although no errors got generated.

 

The other problem, of NaN values in reads from cDAQ modules, was not fixed by changing the USB card.  However, we have fixed it by program modifications: prevent possible parallel calls (we read three units; before there was nothing to force an order, now they are forced to run sequentially), and use a property node to check how many samples are available and read that number of samples.  No more NaN values.

0 Kudos
Message 8 of 11
(5,520 Views)

In response to FAQ3. (

0 Kudos
Message 9 of 11
(5,474 Views)

My earlier post was premature; the communication with the Watlow EZ-Zone controllers has not been fixed.

 

The system runs for 1-3 hours, then gets the same "undefined error" and fails to read.  This failure occurs on each of two sets of Watlow controllers, on two different COM ports of the USB-485/4 adapter.

0 Kudos
Message 10 of 11
(5,467 Views)