COM Port arbitration.

[Sajeesh]

Hi

The DUT (device under test) is connected with computer through USB interface. The device manger shows the COM port assigned to the DUT. Its working fine.

Issue is when we connect new DUT, new COM port is assigned in device manager. The previous COM is inactive now.

We have to test several number of boards with USB interface and the COM port assigned is getting incremented.

How to stop this arbitration of COM port.?

[RavensFan]

This has come up before, so if you do a deep enough search of the forums, you'll find the solution.

It is a feature of Windows where any given new device is given a particular comport number and Windows will remember that based on the device's identification number.  I know I've also seen it do this when I move the same USB/RS-232 serial port adapter to a different USB port.

There is a process you can do within Windows to have it remove previous comport number allocations.  You'll have to search the forums or google that for yourself.  I don't know if there is a way to automate that cleanup process or if it is something you'll have to do manually from time to time.

[RTSLVU]

As Ravens Fan was saying this is a WINDOWS "feature" not a LabVIEW issue...

All you can do is manually clear the "ports in use" 

In Windows Device Manager

1. Under "View" check the "Show Hidden Devices" box
2. In the Ports (COM & LPT) section you will now see every Com port that has been ever been assigned by Windows
3. Right click on each one and select "Uninstall device"
4. That will free up that Com Port number to be used again

The person that can figure out how to make LabVIEW do this would be my hero

MORE: Have you considered using LabVIEW to search the available Com ports for the UUT?  

This could be as simple as just sending one of your UUT specific commands over every Com port one at a time and ignoring the timeout errors on the ports that are there but not in use. 

[cbutcher]

Your mileage may vary, but take a look at the ComDB registry string. It maps which of the 256 COM ports are "available", and can be used to free ports (apparently, I haven't tried this).

You might then consider creating a batch file or something that you could execute (from LabVIEW) to reset your allocation of COM ports to a known state (such that the next device you plug in is allocated the same "next available" port each time).

This will require Admin access, of course.

See https://stackoverflow.com/questions/2002890/change-com-port-via-registry-command-line-or-software for some links and discussion of programmatically adjusting COM ports.

[RTSLVU]

---

@cbutcher wrote:

Your mileage may vary, but take a look at the ComDB registry string. It maps which of the 256 COM ports are "available", and can be used to free ports (apparently, I haven't tried this).

You might then consider creating a batch file or something that you could execute (from LabVIEW) to reset your allocation of COM ports to a known state (such that the next device you plug in is allocated the same "next available" port each time).

This will require Admin access, of course.

See https://stackoverflow.com/questions/2002890/change-com-port-via-registry-command-line-or-software for some links and discussion of programmatically adjusting COM ports.

---

I was thinking something similar myself...

LabVIEW has a whole slew of Windows Registry Access Vi's under Connectivity in the Functions menu.   

[RolfO]

For some devices it may exist a registry key which will disable a new COM-port assignment for each device.


In a production environment where one has to constantly connect and disconnect USB serial ports or other USB devices (e.g. USB-memory sticks or disk drives) when testing a UUT the computer will fill up after a while, and if i remember correctly also getting slower. This can be seen in Device Manager by checking "Show hidden devices"  as shown by RTSLVU in his posting.

For my previous employer i made a wrapper around devcon.exe to both find assigned COMports and clean out old devices automatically. Unfortunately i do not have access to that code any more.

Information on how to download devcon.exe can be found here:
https://social.technet.microsoft.com/wiki/contents/articles/181.how-to-manage-device-drivers-with-co...
I just extracted the SDK and located devcon in these locations on my windows computer, these files can be placed wherever you want and run standalone (as long as you adhere to the licence.)
C:\Program files (x86)\Windows Kits\10\Tools\x64\devcon.exe
C:\Program files (x86)\Windows Kits\10\Tools\x86\devcon.exe

Documentation for find-command:
https://docs.microsoft.com/en-us/windows-hardware/drivers/devtest/devcon-find
Device instance paths to be used when searching is located under "Properties  ->  Details->Device instance path" when right clicking on device in device manager. (Remember to just search for class and vendor, and use * as wildchar for rest of string, since you probably don't not know serial number of connected device.).

E.g. (devcon.exe located in directory or included in PATH):
X:\Prosjekter\bin> devcon.exe findall "@ROOT\PORTS*"
ROOT\PORTS\0000 : NPort Communication Port 1 (COM1)
1 matching device(s) found.

X:\Prosjekter\bin> devcon.exe findall @ROOT*
ROOT\VOLMGR\0000 : Volume Manager
ROOT\BASICDISPLAY\0000 : Microsoft Basic Display Driver
.......
ROOT\PORTS\0000 : NPort Communication Port 1 (COM1)
23 matching device(s) found.

[Sajeesh · Accepted solution]

hi

There are some fixes from the IC manufacturer.

3.5 Use Ignore Hardware Serial Number Setting in the Registry

works fine in the system