too many USB comm ports

[Andrew Fabans]

I think that Henrik Volkers was probably pointing you in the right direction.  This is likely not a LabVIEW problem at all.  I think it is caused by a feature of the USB to serial virtual COM port driver.  Each time sees a new serial converter chip, it will assign it a previous unused COM port number.  The most prevalent USB to serial converter chips (and the associated driver) are made by a company called FTDI.  If your device uses an FTDI chip, then you are in luck, because FTDI provides a solution to this problem.

To find out if your device uses an FTDI chip, go to the Device Manager when one of your devices is plugged in (right click on My Computer and select "Manage").

Slect your device's COM port and go to

Properties->Driver tab->Driver Details...

If the provider is FTDI Ltd., then you are indeed in luck.

Go to FTDI's website here

http://www.ftdichip.com/Support/Documents/AppNotes.htm

and get application note AN_107 Advanced Driver Options.  In the section on Ignore Hardware Serial Number, there is a description of how you can fix your problem by editing the registry.

[LV_Pro]

No, it isn't a LabVIEW problem, nor a problem specific to FTDI's chip set, although I don't know whether it is Windows or MAX that limits the number of COM ports to 256. I said the problem is that Windows will issue a new COM Port number to any new serial number USB COM device it sees installed, and above 256, MAX/LabVIEW/VISA will cease recognizing them. It is only a "LabVIEW" problem because my program that uses MAX/VISA is written in LabVIEW, and this is where I look for answers from others that may have tripped over the same problem.

I think I have fixed the immediate problem, by following the advice in a couple of links

"Deleting registry entries..." and "Reseting COM Port entries under Windows". In the first thread the initial poster refers to deleting entries in the "ENUM" section of the registry that reference the USB devices with the same VID and PID of the "offending" devices. Even if other devices have the same VID and PID, they should reinstall when you plug them back in. In my case there was another device, other than the unit under test, that uses the FTDI serial to USB chip set, but it reinstalled correctly when plugged in after all of these actions. The second reference refers to editing the "COM Name Arbiter" key, which is where Windows apparently stores the info about all the COM numbers previously used. I'm not sure if doing this first would negate the need to do the other, it is just the order I happened to have done them.

[Henrik_Volkers · Accepted solution]

Thanks for the pointer:

Here it is, right from that Appnote:

7.1 Ignore Hardware Serial Number
If devices have the same vendor ID and product ID but different serial numbers, the system will normally treat them as different devices. This causes the drivers to be installed for each device and create registry entries for each device.
It is possible to override this behaviour to make the system ignore a device's serial number and treat all devices with matching VID and PID connected to the same USB port as if they were the same device. This is achieved by adding a REG_BINARY value called IgnoreHWSerNum to the registry and setting it to 01.
This value is held in the registry key located at:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\UsbFlags\IgnoreHWSerNum{Device VID, PID and interface}
For a default FTDI device ID (VID 0x0403, PID 0x6001), add the following registry REG_BINARY value set to 01:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\UsbFlags\IgnoreHWSerNum04036001
For port A of an FT2232 device with default VID and PID, the IgnoreHWSerNum string would be:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\UsbFlags\IgnoreHWSerNum0403601000
and for port B of an FT2232 device the IgnoreHWSerNum string would be:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\UsbFlags\IgnoreHWSerNum0403601001
As the FT2232 device also uses the Windows composite device driver, an additional IgnoreHWSerNum entry is required to prevent Windows from creating additional composite driver registry entries:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\UsbFlags\IgnoreHWSerNum04036010
Now the system can treat devices with the same vendor ID and product ID but different serial numbers as the same device and drivers are installed for the first device only. As such, only one entry is created in the registry. If the device is connected to another USB port, the driver will have to be reinstalled for that port.
Note that IgnoreHWSerNum cannot be setup in FTDIBUS.INF or FTDIPORT.INF, it must be setup by editing the registry manually or by an installation utility BEFORE installing the driver.

However, keep in mind  this will work with FTDI Chipset devices. Also it is whise to check if there are other pittfalls due to that fix.

[LV_Pro]

Thanks All!,

Henrik, I'm giving you the credit for the solution, as my post above "fixes" the immediate issure but not the underlying problem. I had seen a comment in one of the Windows USB threads that made mention of that, I don't think it actually has anything to do with the FTDI chip set though, think it a basic Windows (XP at least) function. Of course, with the FTDI chip set being the most common it by default becomes "an FTDI problem". We were talking about looking for this, but as you say it may have ramifications. I know that with one of our devices (a USB controlled DIO card mentioned in an earlier post of mine), the board initialization expects a returned serial number, don't know if it is the actual "USB one" or not, so we will implement this with some caution. Also as our boards are also being tested off site at a contract manufacturing house, I'm not sure of our comfort level in getting them to edit the Registry, although for the fix mentioned in my earlier post I guess they have to do that already. I also don't know on this specific tester if the other unit, that isn't run by LabVIEW is used with another utility to "flash" data onto our units, which also has the same VID/PID pair as our UUT's, might need to use the serial number. So if this "fix" works for all the same VID/PID pairs, I'm not sure we can use it since there are other devices that have that pairing, although I guess if more than one is plugged in at a time it would issue multiple com port addresses.

[MIG]

Just thought I'd mention an alternative method of uninstalling unused com port devices, which uses the Device Manager rather then using devcon or editing the registry...

1. Press [Windows]+[Break] to bring up the System Properties dialog box.
2. Select the Advanced tab and click the Environment Variables button.
3. Click the New button below the System Variables panel.
4. In the New System Variable dialog box, type devmgr_show_nonpresent_devices in the Variable Name text box and 1 in the Variable Value text box.
5. Click OK to return to the System Properties dialog box and then click OK again.
6. Select the Hardware tab and click the Device Manager button.
7. In Device Manager, go to View | Show Hidden Devices.
8. Expand the various branches in the device tree and look for the washed out icons, which indicate unused device drivers.
9. To remove an unused device driver, right-click the icon and select Uninstall.

Sorry, I've lost the link to where I got this information from.

Cheers,

Mark.

[JasonSmith]

---

@LV_Pro wrote:

"Deleting registry entries..." and "Reseting COM Port entries under Windows". In the first thread the initial poster refers to deleting entries in the "ENUM" section of the registry that reference the USB devices with the same VID and PID of the "offending" devices. Even if other devices have the same VID and PID, they should reinstall when you plug them back in. In my case there was another device, other than the unit under test, that uses the FTDI serial to USB chip set, but it reinstalled correctly when plugged in after all of these actions. The second reference refers to editing the "COM Name Arbiter" key, which is where Windows apparently stores the info about all the COM numbers previously used. I'm not sure if doing this first would negate the need to do the other, it is just the order I happened to have done them.

---

Windows doesn't actually store the COM Port reservation with a device, cleaning up the COM Name Arbiter key would probably unreserve the ports. I have never modified this portion of the register directly, so I can't speak to the exact functionality of this registry key. The problem with this is that if one of the old devices were not cleaned from the ENUM section of the registry, it could try using the previously assigned port number and cause a COM number collision.

Microsoft does provide functions for manipulating the COM port reservations, which may (or may not, who knows?) be safer than modifying the registry directly. You can read about them on their COM Port Database Support Routines page. I am not sure off the top of my head how complex their structures are, so I don't know how easily they could be interfaced from LabVIEW. Unfortunately that doesn't solve the problem of removing all the existing hardware, which to automate requires the use of a much more complicated set of functions.

If you do properly remove the the hardware by uninstalling through device manager or making the appropriate function calls in an application, the port reservations will go away with the hardware.

-Jason S. 

[LV_Pro]

The port reservation appears to go away when you use the Device Manager route, but apparently it doesn't modify the "last port number used" in the registry. I originally attempted doing the setting the variable to allow the "hidden devices" to be seen (a note, if you don't have any serial devices connected when you open device manager, none will show up regardless of the state of the "SHOW_NONPRESENT_DEVICES" switch.) and I eliminated the ports from 262 to 231 (it is a very laborious task, one port at a time, with the device manager screen refreshing between, requiring me to scroll back down through the very long list to get to the next one). Unfortunately, having "removed" these, when I reinstalled the last unit (which Windows had seen as COM262) it didn't recognize it (good), reinstalled it (good) and gave it COM263 (not good). So just eliminating them in DevMgr isn't apparently sufficient, although possibly if I had spent the two hours and deleted all of them ...  I also am nervous about editing the Registy, made sure to follow the MS suggestions of how to "export" the current one first.

[labme]

Try using the freeware "Device Remover - The Powerful Device Manager" for removing the phantom devices!
It allows you to select multiple devices to remove. As far as I remember this app helps with the COM number problem! They will get lower numbers again.