I've been reading through this thread and I think I have a grasp on what you are trying to do. Here are my thoughts...
I'm pretty sure Windows assigns the addresses, LabVIEW only references those assignments. It is possible the driver may assign a port for the device and then never frees that assignment after it is unplugged. If this is the case, clearing the Aliases or trying to resolve this issue in LabVIEW would not work because it is only clearing the references, not the assignments.
As far as not being able to clear them in Device Manager, I found an interesting thread after doing a google search
I'm not sure the accuracy of the claim. But in the last post, someone claims Windows XP has a glitch and describes exactly your issue.
You said some machines are XP some are Windows7? I'm not sure if this is applicable, but he then links to this tutorial on how to free up used COM ports. (I think this is for XP, but may also work in 7)
I hope this helps!
Thanks for your help, however this does not address my problem. I know well that in Device Manager the COM port assignment of a connected device can be changed. (This assignment is done when the device driver is installed, so it's natural that Windows lets the user change it.) The problem we are having is with previously installed but currently not connected (USB VCP) devices. This information is saved in the Registry so that when the device is reconnected Windows does not launch the driver installation wizard since the driver is already installed.
To digress for a moment, the post that claims Windows XP Device Manager has a glitch is not a glitch. And we are using Windows 7 and that also functions the same. See the link to the Microsoft article that explains the command "set devmgr_show_nonpresent_devices=1". (I made a batch file with that line then "start devmgmt.msc".). Device Manager then lets you uninstall an orphaned COM port. See my original post. (Device Remover also seems to work.)
Anyway, the real problem was that with a manual deletion of a port so that Windows would let a new driver be installed, HyperTerminal would work but LabView would not. This is where we are stuck. We can manually, one at a time, reassign the ASRL to COM port in MAX, but we really need to automate the process or reinitalize all of the VISA assignments.
I've been doing some digging and found this NI tool. If you navigate to the National Instruments folder in Program Files of your computer, in the NI-Serial folder there is an executable called NIPortConfig.exe. I know you have tried other ways, but try using this tool to recover unused ports rather than other methods and see if it works. I have attached a copy of the program if for some reason it is not in your program files.
I will continue to look more into this issue in the mean time.
Hope this proves useful,
Thanks for your input. I searched ni.com and found the description of NIPortConfig here: http://digital.ni.com/public.nsf/allkb/AEF778866CA41A458625763F0062A805.
It says it applies only to Windows 7 (which we are using along with some XP machines). I ran the program, which was where you said it would be. On my XP PC it doesn't list any serial interfaces, since I don't have any NI hardware installed. But I (bravely) clicked the "Recover Unused COM Numbers" button and within a second or two said it was complete. I looked in MAX --> Software --> NI-VISA --> VISA Options tab and everything seemed to be the same as before. Most items were in order, except for ASRL9 is still asigned to COM10, ASRL12 to COM9, and ASRL13 to COM12. (I was able to rename them manually to be in order.)
I will keep this in mind when our Production PC runs out of COM ports, along with DeviceRemover and uninstalling and re-installing VISA. (I suppose that would fall under "Nationa Instruments Software" item in Add/Remove programs?) My ace-in-the-hole is restoring the PC with the system image I made from a clean install, which actually may end up being easier at this point, but I'll play around with the other ideas from this post. Let me know if you or anyone finds out anything else. (Carisa?). Thanks.
Carisa is actually out of the office this week, but I've been talking with her about this issue and we are both pretty muich out of ideas. But I sparked the interest of one of our VISA gurus and he said that if you delete the visaconf.ini file, MAX will regenerate that automatically it this may "reinitialize" the VISA assignments.
Let me know how this works.
Thanks, Pete. I'll post when/if we run into the problem again on our Production PCs. But this may be a while because we are now uninstalling each port (it is fast in Window 7) when we are finished testing each instrument and are ready to ship. Uninstalled ports then get reused when a new instrument is connected (by the driver wizard, which is fast and silent in Windows 7 - there's just a pop up message in the System tray), so we might not get up to port 800 something again.
This work-around we are doing (uninstalling) is our best solution at the moment. It costs only a few seconds per unit and should relieve us from needing to find a better solution than restoring the hard drive from the system image. I hope this post helps others with the same or similar problems in the future.
Thank you all for your inputs.
I'm sorry I didn't update this post months ago. Last March (2012) I came across the following on the Silicon Labs website. (Jeff Bohrer correctly assumed from my original post that we are using the Silicon Labs "USB to Serial bridge" in our device along with their VCP (Virtual COM Port) driver.) It turned out that Silicon Labs provided the ability to install their driver on a "production" (aka, "manufacturing") PC (the PC that the production department uses to flash the CP2102 chip with our company specific information - PID, serial number, strings, etc.) so that the PC does NOT enumerate and install DIFFERENT/ADDITIONAL COM ports for each device (which is normally done because they all have different serial numbers). The way to do this is simply a matter of adding the following 2 lines to the setup.ini file for their "pre-installer" (the program that is run BEFORE connecting the USB device so that the drivers are installed on the PC and Windows "found new device" wizard can find the driver):
[Manufacturing Ignore Serial Numbers]
Ignore Serial Numbers
That did the trick. Now our Production PC's do not keep creating additional COM ports every time we program (flash) the USB chip. I still have not resolved the original problem of VISA's COM port aliases issues vs. what Device Manager sees when we hit the limit (more than 800 COM ports - COM891 - were installed where the limit was supposed to be 256), but since the Production PC's are not adding new COM ports with every device we program, we don't have the problem any more.
Thanks all for your help. I hope this info may help others in the future.
Not sure if this is completely related (since I only skimmed through the posts), but when I have used COM ports that are no longer in use, I found a procedure online to remove "ghost" COM port assignments so they could be used again.
This works on Windows 7 for sure, though not sure about XP, Vista, or Win 8, and you probably need administrator priviledges.
1. Right-click "Command Prompt" in 'Start-->Programs(Win XP)/AllPrograms(Win7)-->Accessories-->Command Prompt' and choose "Run as Administrator".
2. Enter set devmgr_show_nonpresent_devices=1 (space after 'set') and then press 'Enter'.
3. Enter start devmgmt.msc (space after 'start') and then press 'Enter'.
4. In Device Manager, select 'View-->Show Hidden Devices'.
5. Now if you expand the Ports (COM & LPT) section, all the COM ports that have ever been created will be displayed; the non-present ones being in grey. You can uninstall anything that you don't want (right-click, select uninstall).
6. Once finished, select 'OK' in the properties dialog box, and wait for the Device manager to update the 'Ports (COM & LPT)' device list.
I only post this because I did not see a marked solution to this post. It is not specific to any device in particular that I know of.