HyperTerminal sees a COM port but VISA does not

[Edjsch]

It should not be possible that HyperTerminal sees a COM port but VISA does not. Does anyone know why or have any ideas?

Here's some more info: I wrote a LabView (LV) program and deployed it (via the Application Builder) to some of our production department's PCs (some Windows XP and some Windows 7). We use it to set up products we design and manufacture through our device's USB serial port. The USB port is actually a virtual COM port (VCP) - a USB to Serial converter or "bridge". We have a custom driver for our device and since each device's USB bridge chip is programmed with a different serial number, every time we connect a new device to the PC the installer runs and assigns a new COM port number. This is so our customers can use multiple devices on a PC. Fine. On one of our production PC's we were close to  COM900 ports (HyperTerminal sees only up to COM256) when suddenly Win7 would not allow any more. We were able to uninstall orphaned (non-present) COM ports from DeviceManager ("DM") by starting it from a command console (DOS window) with a special command-line switch, "set devmgr_show_nonpresent_devices=1" then "start devmgmt.msc" (I have this in a batch file). In DM View menu you can "Show hidden devices" and uninstall them as if they were connected. I've also tried uninstalling them the normal way when the device was actually connected. Either way, sometimes, not always, depending on the COM port number, after reusing that port number by installing a new device which picks up that old, freed-up number, LV VISA doesn't see it. In other words, when "Refresh" is clicked in the COM port VISA list box, any new devices installed should be and normally are seen. (Refresh is not needed if the application is started after the device's driver is installed. It is only need if the LV application is open with the new device is added.) However, HyperTerminal does see it and lists it in the Properties screen, the "Connect using..." list box. And the port works with HyperTerminal. (Of course we've tried rebooting after uninstalling and/or reinstalling the device, with the same results.)

When I've spoken to the NI Applications Engineers in the past about serial port issues (not about this problem) they have confirmed that if HyperTerminal can see the port then NI VISA should also see it. This is crazy. I am posting this in hope that someone can shed some light on this problem.

Thank you. -Ed

[JÞB]

OK You cleared the resources reserved by the serenum service now you need to clear the reserved VISA Aliases.

MAX: Tools>Options>VISA Options

Select: General settings>Aliases

You'll figure it out from there!

this also clears the devices out of devmon

[Edjsch]

Thank you, Jeff. I'll try it and let you know.

(I'll have to install NI MAX on the PC in question. Do you know if I can install MAX alone without installing the entire LabView package? If you don't know I'll see when I insert the LV installation DVD's.)

Ed

[JÞB]

you'll need MAX and MAX VISA configuration support.

(Oh why did you not include these in the installer? ) Very useful tool for debugging hardware configuration issues  and even storing hardware configuration (those *.nce's sure simplify deployment)

[Edjsch]

I really appreciate your help, Jeff. Unfortunately it did not do what I hoped or you expected. After clearing all the aliases, neither MAX (nor LV) would see a newly installed VCP. To make the port visible I have to manually create a new port (right click Serial & Parallel --> Create New Port). Then I have to manually type in an ASRL number and Serial Binding. The port is not listed there (it is not seen!) so I have to enter it manually (the number that Device Manager shows) in the Serial Binding list box. (BTW, ASRL numbers up to 256 are only allowed. So when I have, say COM702 I must assign an ASRL number under 257.) After entering it manually and clicking Refresh (F5), now MAX and LV see the port and I can use it.

This is not the solution we need. Do you have any other suggestions?

If not our only viable option will be to reinstall Windows and all the programs we need, then create a restore point. When we run out of port numbers in the future we will do a system restore. It's a pain, but I don't see any way around it.

Let me know what you think. Thanks! -Ed

[JÞB]

OK After re-reading the thread. I see you use the term "Bridge" with the VCP.  I'm going to assume you have a Silicon Labs chipset.

Having spent two days this week digging into an issue with the silabs.sys and silenum.sys (turns out my BIOS was reserving COM3 and COM4 I had to change the enumerator HKEY Start to COM5 to resolve) I'm going to offer two possible solutions.

From Add/Remove programs Uninstall these two programs

Reboot

Then reinstall the driver and VCP enumerator

Reboot

Test the system.

If that does not fix the issue: Stephanie House (SiLabs) [MCU.Support@silabs.com] has been very helpful and has some Si Labs in-house utilities that may address the issue.

[Edjsch]

Good catch. Yes, we're using the Silicon Labs CP2102 and have created a "custom driver" installation package. Our new PCBs have a factory-programmed chip, so the PC reuses that COM port (COM3 on that PC). The problem is when we we re-program the CP2102 (setIDs exe) with our PID, and device strings (including the S/N), the PC runs our installer and assigns the next COM port number. I was hoping that maybe it would go up to 64K or something! Anyway, it surpassed COM256 but we ran into this problem when almost up to COM900.)

There is a registry entry for each SN device, which shows the assigned port. If we delete the key with regedit, the COM port database (don't know the file name) still has the port number. That's where Device Manager comes in. It seems to allow us to manually delete the ports, but it would take quite a while to delete 900. (I was trying to make a batch file for DevCon, but couldn't get it to see the HW ID of the devices in need of deletion.) So we tried manually deleting a few. After doing that Device Manager shows that Windows (and HyperTerminal) can reuse the port number when a new device (new SN) is installed, but, as you know from this post, VISA cannot see unless I manually add it in MAX.

I can't see how it has anything to do with the Silicon Labs driver. I might have to delete ALL of MY devices, then uninstall the driver files, reboot, then reinstall, as you suggested with the SiLabs driver. However, I don't see how VISA will now see these changes. VISA must have it's own database. That's what I thought deleting the ports in MAX would clear out, like a fresh install, but apparently not.

I've been through Silicon Labs' tech support on other issues and they've been able to help on some. I could run this by them.

BTW, have you noticed that Silicon Labs' chip and driver, while faster than NI's own "bridge" or serial-USB converter (I returned it because at $100 it's performance was worse than a $20 converter you can buy in Staples), is substantially slower than a real serial port? For example, our device can transmit 250 readings per second (a 12 byte string). A real serial port used with my LabView program can keep up, i.e.., graph & tabulate at that rate, but with a VCP we only get about 70 RPS. Same code. Can't figure this one out. They say the've tested the driver to 900 KB claimed. We're using 115KB here. Anyway, the VCP driver makes it look like a COM port which LV thinks it is. Why is it slower than a real port when the USB should be able to work almost 10 times faster than I'm using it (up to 1024 bytes per mSec per the full-speed USB spec, which SiLabs claims they verified)?

Anyway, I appreciate your help. Thanks! -Ed

[elrathia]

I've had issues with these drivers when I have installed a myriad of them in a production setting. Are you using dozens of them on the same computer, one after the other? You might have to use a utility to remove the absent ones from your Registry.

Just a thought.

[JÞB]

It seams that you could (with the right HKEY entry) assocate an action to destroy the com port on device removal filtered by your PID?  I don't know exatly how but if I were you I'd investigate.

Also you could use the windows registry API functions to do this automatically in your test

[Edjsch]

I found this post (from 2008!): http://www.cygnal.org/ubb/Forum9/HTML/001680.html. Read it and its links.

In addition to the Registry keys there's a bit-mapped database file called ComDB. See: http://msdn.microsoft.com/en-us/library/ff546481.aspx (also in the link above). Others have had the same problem with the SiLabs chips and drivers, but my problem is multiplied by the LabView problem. Read on...

Device Manager cleans up both the registry and the com port database. (As I said I have not yet been able to run devcon from a batch file to automate the deletion of hundreds of ports. A program could be written, also, but it should be do-able in a batch file.)

Anyway, even after doing so, I still have the problem that LabView VISA cannot see new ports that are installed re-using a deleted port number, and MAX confirms this. I can use MAX to manually re-assign the new port, but this is not an acceptable production solution.

Thank you all for your suggestions. This is a gnarly problem, indeed. Any more thoughts are appreciated.

Ed