too many usb comm ports

[LV_Pro]

Good Morning,

    I've run into what may be issue soon, where we have the units being tested that have built in USB ports that appear as serial comm ports. The problem is that every time we connect a UUT that hasn't been run on that computer before Windows assigns it a new com port number. My concern is that quite soon, as the production line gets into full swing, we will hit the "magic number" of 255, the highest com port number and I don't have any idea what Windows will do at that point. Before I start writing code to parse the new com port number returned by VISA, and adjust" the registry entries accordingly, I want to know if it is necessary. I figure that there are a couple of possible scenarios, that Windows complains and won't issue a com port #, that Windows starts over at the beginning, or that Windows just hits 255 and then keeps reissuing it. I would prefer that it be the later two, don't want to have my program messing around in the registry, and really don't have time at the moment, nor access to the machine(s) to experiment to see.

Thanks,

[Henrik_Volkers]

Depending on the used driver/chip there might be a solution. I think it was FTDI where I have read an App note about this problem and how to solve it.

I would try to contact the manufactor of that USB chip if they have a solution. Since most users use the provided chipdriver dlls in their product there is a chance that you don't even have to request a rebuild of the driver and only have to replace the dll 🙂

The Chip/driver producer should listen and provide a solution. If QA dep tell the designers thats a no go they will design in a new chip next time.

Another way would be to force the OS to reasign the port to the lowest free port with a script. 

[LV_Pro]

I'm not sure that I understand your answer. The problem is that on our test stands we will see hundreds of the product boards go by over the life of the boards. As I have seen with "standalone" usb-serial adapters, when a new one is plugged in, that the computer hasn't "seen" before, it will assign it the next available comm port #. It probably knows that it hasn't seen it before by some serial numbering type scheme that is returned in the USB's header info when plugged in. As the hardware design for the unit containing this USB interface is essentially frozen, and as that side of the design group won't see it as a problem in the target systems (where the boards won't be "talked to" via the USB path) it is unlikely that I can get any hardware/firmware changes. I'm not sure that would be the way to go anyway. Definitely not going to get a change to the BOM at this point (on top of which I'm an outside contract test consultant). So I will have to address the problem on my side of the fence. I haven't looked yet, but am pretty certain that the Com#'s are stored in the registry, so I can just make sure that I "reset" those numbers before they get to 255, but am never comfortable with my programs modifying the registry.

[pallen]

This might not be going in the right direction...but I'll throw it out there:

Microsoft provides a command line utility called DevCon that works a little like the Device Manager. http://support.microsoft.com/kb/311272

I believe you could use this programatically to remove/reset your port numbers to prevent them from climbing too high. 

[LV_Pro]

Well I discovered that Windows got to 256 and just keep incrementing the COM port numbers. Unfortunately VISA doesn't like anything above 255 or 256 (I wasn't there for the happy moment). Not having too much luck resolving the problem, which is in a cross post on the GPIB/VISA forum. Haven't tried "Devcon" yet, looks like one of those tools that it really helps if you were on the original Windows design team!

More to follow, although if anyone has any fresh ideas...

[slipstick]

I had this issue about a year ago with a Silicon Labs Virtual Com Port device we make. I used DevCon to keep the number of Com Ports constant and it worked great. It reallly removed all references to the virtual port and the machine has been making hundreds of units with no errors or USB bloat.

I highly recommend it.

Oh, and you just call it with System Exec and plumb in the command you want it to run.

[LV_Pro]

Thanks. I downloaded it will take a look in the morning when I'm back at the office.

[sebster]

In the 'More Information' section of the Microsoft Support page for DevCon is the following text:

"DevCon is not redistributable. It is provided for use as a debugging and development tool. You can freely modify DevCon for private use."

Don't know how this will affect you, but it's something to consider when you do redistribute your executable.

Sebster.

[LV_Pro]

Yes, I saw that. Didn't really want to put it in our exe's, they have already been qualified and sent out. Our expected production run of these units shouldn't require having to do this more that a couple of times, as painful as it may be. If I knew all the places that the references hid, in the Registry, etc., I could probably put together a distributable utility targeted to just this issue.

[LV_Pro]

Tried DevCon on Friday without a lot of success. While I was able to remove the most recent port "entries", I haven't figured out how to get it to remove those that "aren't installed", but are registered in the Registry. I also found numerous locations in the registry that refer to them. I guess if I have to spend the hours it appears that is going to take I will have to, but my first attempts weren't successful. I tried just removing back before the 256 limit, but when I plugged in a new serial number USB device it went ahead and issued it COM263, the next number in the series if I hadn't deleted the entries in Device Manager, or through DevCon, so apparently it is keeping track of the count somewhere I haven't found. I love Windows (not!).