usb hub serial problems

[craigc]

Hi LV_Pro

I have the same issue on my system with an USB to RS485 adapter, which dissapears and then reinstalls itself under a different COM port.  I have been pointed to a guy within our company and he says that it can be forced to re-install on a designated COM port by modifying the .inf file for that device.  It is on my "to do" list but have more pressing matters at the moment.  That information might be enough for you to trawl through your .inf files though if you wish.

Thanks

Craig

[JÞB]

Device Events

D-link Hub

the U

Frankly, You are witnessing a pretty common problem.  I have address the issue several times both on the forum and in my real job.  I believe that this is becoming something that needs to be addressed by an expansion of the USB 2.0 spec or in the DAQmx API.  Until then. there are work-arounds and provisos that can offer a high reliability USB connection.

[JÞB]

This link here Provides a detailed experiment to resolve the issues of USB connection reliability and please forgive the evident frustration of the OP.

[LV_Pro]

The problem with the link is that it seems to be addressing a problem where the NI USB-DAQ "hickups" (get reinstalled, or whatever is happening). I dealt with that problem, putting ferrite beads on the usb cable, moving it to a motherboard USB rather than the hub, upgrading the DAQmx version and putting in the code that resets if it detects that particular error message. Unfortunately that is no help for the USB-Serial problem. As to there being work arounds, etc., if you know of them ...   This project is really getting ugly, the customer doesn't care that it "isn't my software", just that their new test system isn't working. And their engineer that was my primary point of contact quit and moved to Florida, just missing the onslaught of winter.

[JÞB]

Putnam

Sorry the links were not too helpful.  I understand the frustration under time constraints and in front of the customer.  It does get a bit ugly when going USB- RS232/422/485.  As far as "work arounds, etc., if you know of them"... Well.... In a word nope.   CCI is in a similar market for a good USB-'data' solution as well.  Frankly, this issue has caused us to engineer avoiding usb-serial interfaces on several systems despite the apparent "ease" of plugging n' playing on the USB resources.  

Do you have the freedom to utilize another connectivity solution that is more robust?  If so I've had good outcomes with several PCI and PXI to serial interfaces.

[LV_Pro]

Well, I guess if I get the test system up and running, get their initial buy in, and then, after it has run for a bit (hopefully more than an hour or two!) Maybe I can get buy in for some other. Of course, I need to open up the PC and see if there are any slots available, not necessarily a given at this point in non-industrial PC's. Argh!!!!! And I'm not making pirate sounds, more like that made by "Joseph of Arimethea" in Monty Python's "Holy Grail".

[craigc]

Hi LV Pro,

I believe the problem I am seeing is to do with the 3rd party Device Driver as it completely dissapears from the system and the only way to get it back again is to uninstall amd re-install from the system.  When it does this it always goes to a different but predictable COM port.  This may be because the COM port it was originally on is already taken in the registry.  I found this which details how the COM ports are assigned but i need to look at the registry to see if they old COM port is released.  This doesnt fix my problem, but if you are able to re-instate the comms and it shows up on a different COM port, it may be usefull to clear the registry and then re-instate the COMS for the Device.

http://search.ni.com/nisearch/app/main/p/y/0/q/com%20port%20usb%20device/x/0/

COM Port Registry

HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\SERIALCOMM

Craig

[LV_Pro]

Well, I'm going be at the customer's plant this morning, 125 mile drive, luckily there isn't too much snow at the moment. This problem has put me so far behind that delivery of a working, reliable system by the end of the year is in jeopardy. The clearing registry, etc., really isn't the issue, I can get the system to reinstall on the original ports assignments, just not via my program (yet). A bigger issue is Why!? With the decreasing number of computer chassis with available slots, particularly for my frequent measurement solutions for really small companies, USB was looking like the answer, but this incident has left a bad taste. Even if it turns out that the problem is something along the lines of a bad adapter on one of the ports, the way that the system handles it is troubling. This project is costing ME money, not to mention the hassles of trying to do all of this at this time of year, holidays, weather, and a customer that I probably won't be using as a reference!

Thanks,

And Merry Christmas to those for whom it is appropriate.

[JÞB]

I hear you Putnam!  There certainly is a market for a reliable USB conectivity solution.  Common Digi Intl! Go Go Comtrol!

[LV_Pro]

Has anyone a fair amount of experience with NI's USB-RS485 interfaces? In particular, does the port driver software have some mechanism for recognizing a particular "port" so that plugging and unplugging wouldn't cause windows to create a new port designation. I need to find a way to get around my problem where intermittently Windows seems to think that the usb-serial comm ports were unplugged, and replugged, moving them from Com 5 and Com 6to Com14 and Com15 (or some other high numbers). I was in at my customer last week, and hand it happen when nothing particular was happening on the computer, other than my program doing DAQ (via USB), the DAQ box plugged into a motherboard usb port, and doing occasional communication via one of the two attached USB - RS485 adapters (they are on the second usb hub I've purchased, a different brand from the original). At this point they (USB-RS485) and a USB connected Zebra printer are the only things on the hub. The Zebra is just sitting there, with the program not running yet, and no product tested, no test results to print out! But with the afore mentioned setup I discovered that the serial com had failed, and once again it was because there was no "L300" aliased com port at COM5.