usb hub serial problems

[LV_Pro]

This is strictly speaking not a LabVIEW problem, per se, but it is causing me problems with my LabVIEW code. I'm building (and building, and building) a test system that has a USB6221 Daq card, two USB -RS485 adapters and a USB based Zebra printer. Originally I had most of these connected to a D-Link DUB-H7 powered 7 port hub, but I've slowly been moving things around to try and resolve an intermittent problem. Initially it showed up with MAX suddenly opening a new instance, but since I've moved the 6221 off of the hub to an actual USB port on the computer that seems to haved gone away. I also instituted some code that looks for the specific error mentioned in that thread and resets the DAQ card. Now the bigger problem seems to be that I'm loosing a connection to the USB-RS485 serial adapters, which then are seen as new com ports when Windows sees them again. In other words they start out as COM4 and COM5 with suitable VISA alias names, and suddenly I get a VISA error telling me that the resource no longer available and when I check in MAX I see COM 11 and COM 13  or something. I've begun to suspect that the hub may be glitching, have run all the USB cables away from anything remotely "noisy", such as power supplies (wall wart) used to power my transducers, a relay box (that hasn't been activated at any time when the errors occured). I've suggested that to my customer getting a UPS to power the hub and transducer power supplies, but want to get any ideas you folks might have. As it is I don't have the beginnings of a reliable system that I could expect to run for a full shift, much less longer periods. 

[Mark_Yedinak]

We recently have begun to see a similar problem with our USB devices. In our case we are communicating with printers. We have the necessary driver files (.inf) created and everything works as expected. Most of our products use a serial number so they are always uniquely identified. However one of the newer lines of printers does not use a serial number and as you have observed they can switch the port they are assigned during use. Since our tests actually reset the printers multiple times during testing this is a real issue. We are in the process of investigating if there is a way that we can scan the list of active devices and glean from the list what the new port number is so we can reconnect. If you come up with any solutions please post them. I will do the same.

[Ben]

Two thougths com eto mind.

Power. If you are using bus powered devices, then you maybe overloading the power.

There was recently (sorry I can't find the link) a message posted to this board that talked about a update to windows for issues with USB ports.

Ben

[LV_Pro]

What a pain! I have heard that Windows 7 has improved its USB connectivity, but that isn't an option. I'm really suspecting my particular powered hub, just read some reviews online where others report it loosing connection. For somethings, like the mouse and keyboard (which were moved to the hub to free up ports for the DAQ and printer) this isn't a problem, but I haven't come up with a way to look for new, unidentified, comm ports and use them. As it is RS485 to my two units I guess I could use one, but since one is using MODBUS and the other not it would get uglier quickly.

The only bus powered devices now on the hub are two USB-RS485 EasyLinc ES-U-3001-M adapters, and the keyboard and mouse. If you happen to remember the link, please drop me a note, Ben. Tell Mike I'm going to be back up on the hill where he and I met.

Message Edited by LV_Pro on 11-24-2009 10:57 AM

[Henrik_Volkers]

I have no reference to it, but i remember some discussions about similar problems. One solution suggested was:

Every USB device has a unique ID and you can tell windows (somehow) to assing THIS ID to THAT driver and THAT comport.

Might be that it was something driver specific, possibly the FTDI chip. So if your adapters run with the FTDI chip take a look at the FTDI KBs.

[Coq_Rouge]

The problem caused by USB to serial converter comports jumping around all the time is a pain. But it is related to the OS, not to Labview. The only solution I have is to label each USB to serial converter so it end up in the same USB port all the time 

[Henrik_Volkers]

LV_Pro,

do you still run the USB-RS485 adapters with that mentioned hub? Have you tried to get rid of that hub?

I once had problems with USB adaptors on a labtop that wanished after using a PCMI-USB card .....

And as longer as i think about, a solution for upcounting com ports is pointed out by FTDI .... IF your adaptor uses FDTI chips.

http://www.ftdichip.com/Documents/AppNotes/AN_132_Re-Assigning_COM_Port_Numbers_Using_Registry.pdf

[BlueTwo]

Hi Putnam,

I have spent a lot of time messing with USB hubs and devices, feelin' your pain! I have found the D-Link 7 port hub you mention to be very robust, after trying a number of other ones that caused us endless issues. As mentioned previously, external power is important. If the adapters you are using are FTDI based and you are looking at coding to them directly (via their DX22(?) drivers), then as has also been mentioned it is straightforward to open the device by name/location/serial number etc. (or at least it is for their 232 offerings).

I would be inclined to look at the adapters/devices/code/drivers rather than that hub (which has not been problematic for us) that has been my experience anyway.

Cheers,

Blue 

Message Edited by BlueTwo on 11-25-2009 09:17 AM

[LV_Pro]

On Wed. 25th I swapped out the usb hub, having noticed that morning that I lost the comms (when it happens it isn't just one, it is both). I had, during this process, moved the keyboard and mouse from the PC's connector to the hub and Wed. morning I noticed that the light on the keyboard would go out for a while, with no one near the keyboard, like it was loosing its connection to the PC. We ran the ports on the new hub for a few hours before I left, not a comprehensive test but it had gotten to the point that I was getting errors pretty often before we did it. Both the hubs are powered hubs. I had been having the additional problem of my DAQ unit (USB6221) dropping out, had put code in to detect it and force a reset, restart if it did, but didn't have a good way to do that with the serial ports. I won't know whether this really helped for a while, my customer is going to be out of town much of the week...

Not sure how I would "label" the serial ports, really not happy with this whole deal. It is getting harder to build test robust test systems using off the shelf PC's and trying to sell my smaller customers on paying $10K for the computer and boards (say a PXI solution) is going to be very hard, particularly in this economy, and particularly when my profit tends to be the software side.

[LV_Pro]

Still having issues, was at the customer's site on Saturday, trying to get this system released before the end of the year when my program stopped communicating with the blower moter controller. Discovered that both of my serial ports, originally on Comms 5&6 were now apparently 16&17. Had to shut down my program and disconnect/ reconnect the usb hub to get Windows (Vista, home edition) to reinstall them as their correct assignments. This is with a new hub. In a previous post it was suggested that modifying the registry would allow me to specify the comm addresses. Does anyone know whether this forces Windows to retain these assignments, is there a way to tell Windows to leave the serial ports where they are? I can't have this in my production system, if nothing else it forces them to "hard" shutdown the blower by walking around the end of the wind tunnel and pulling the master disconnect, not a very elegant method! I don't have a way to move them off of the hub, there aren't any usb ports left with keyboard/mouse, Zebra printer, NI USB DAQ, USB photometer (internal LabJACK DAQ) and the two USB-Serial adapters. I had moved the NI USB DAQ to one of the motherboard's usb connectors, and it seems not be "glitching" (original symptom that I noticed was multiple instances of MAX being launched). I'm going to swap out one of the USB-Serial adapters tomorrow, we have one that hasn't been connected, but would like to know whether there is a way to tell Windows not to reassign them to new comm #'s if it thinks there is a glitch.

Thanks!