How do I pragmmatically determine what comm ports my serial instruments are on?

[David Lander]

I am building a test stand that incorporates 5 serial instruments; 2 digital loads and 3 power supplies. I can use my PC's device manager to figure out which comm port each device is on and set the VISA Resource Name so everything runs as expected. All is well at this point. The problem comes in when an instrument's USB connection is unplugged and replugged, at which point the system may renumber the port assignments; the result is that my program errors out, I have to figure out what port everything is on all over again, and change the VISA Resource Name for all of my instruments. While this is a minor annoyance for me as the developer, this would make the program unusable by the user.

While "don't ever unplug an instrument" is a sensible answer, the fact is that these things happen from time to time - like for calibration - so I want the program to work regardless of instruments being unplugged.

Is there a way to have the vi automatically identify what port each instrument is on?

[RavensFan]

Do your instruments have some command that you could send to them that would send back a response that would uniquely identify them?  Some instruments use an IDN? command.

If you have a command, then you could cycle through the available com ports and try out the command until you get a valid repsonse.

Usually, with USB devices, the com port is assigned when you first plug it into a specific USB port.  If you unplug and replug it into the same port, then you get the same com port number.  Plug it into a different USB port then you get a new com number.  If that is the real situation with your instruments, you may want to plug each device into each USB port one at a time and make note of the com port assigned.  The instrument 1 could be com ports 7 through 12 depending on which USB port you've plugged into.   Then instrument 2 could be com port 13 through 18 depending on the USB port.  This would let you identify the instrument based on the com port number assigned.  This should work as long as you don't do anything like clear the cache in Windows of assigned com port numbers.

[David Lander]

I'll have to look into the call/response.

As for the USB ports, reconnecting seems to reorder things sometimes regardless of the physical connection, possibly because I have a USB hub involved. I'll have to follow up on that and see if it's really the case.

[Swinders]

I've used a USB connected barcode scanner that appears as a COM port. If it is left connected to the same USB port the COM port remains constant but if it is disconnected and then put back into a different port the COM port changes. This sounds similar to your problem so I'll share how I solved things for my application.

The scanner I use accepts commands and will respond with a known string when I send a character 'I' via the serial connection. Using this I can see if the scanner is connected to the expected COM port (default port is stored in an ini file).

If this fails I create an array of possible serial ports by trying to open COM1 and checking for an error. If this does not generate an error I add it to an array. Next I try the same with COM2, COM3 up to COM16 (for example). This gives me a list of COM ports I can open.

I then iterate through the array trying for a response and stopping either when I get the expected response and continuing with the application or if the device is not found by the time I get to the end of the array I show the appropriate error condition to the operator.

If your instruments can return some kind of ID that will allow you to identify them as mentioned in another reply then this method could be used. Your 3 power supplies and 2 digital loads would need to be able to return a unique identifier otherwise you wouldn't be able to tell them apart and I think you'd possibly run in to problems.

[GregFreeman]

The only problem to querying the instruments, is sometimes it can be a royal pain if a lot aren't connected, waiting for the responses to all time out. So be prepared for potetionally having some long bootup times.

[David Lander]

Ok, I solved it. With my digital loads I'm querying the instrument about its serial number on its given address from COM0 through COM25. When I get a response I know that I have the right port and I assign it. With my power supply I can't query it about its serial number, it doesn't offer that function. Instead, I have to send it commands (using the appropriate address, of course) on COM0-COM25. If it's the wrong COM port it errors, so I have to catch the error and clear it. When I don't get an error I know I have the right one. It's clunky and takes longer than I'd like (24 seconds to configure 2 digital loads and 3 power supplies) but it works well.

[David Lander]

Here's the one for the power supplies. For some reason, everytime I ran my program (the one for which this is a sub vi), when I started it up again, it always missed the first COM port, so I had to add the first for loop you see here, and now it works. Once the vi makes an attempt, all attempts after that work fine. Any ideas why that might be?

[David Lander]

And for the digital loads...

[RavensFan]

One problem is that there is no com0.  Com ports start at #1.

Check the logic on your PS.vi  The way the error is being used to stop one loop but continue the next seems suspect.  Actually that innermost For Loop is useless because you have it wired up to only run one time.  Likewise with your first For Loop containing the Com4 initialization

You shouldn't need to run that part at all.  My guess is that you might be passing an error into that subVI from a previous search.  An error into a function generally keeps it from running.  So you are probably not running it the first time because of the error coming in, but then you do clear the error in that first For Loop and it runs normally after that.

You shouldn't need to blindly try com ports from 1 to 25.  Suppose it winds up to be 26 sometime in the future.  You'll never find it because you've hardcoded up to 25.

Use the Find VISA Resource function.  It also has an input to filter things to just serial ports, or just GPIB.  It gives you an array of the com ports that are present on your system.  Just go through that array to find your devices.  That way rather than blindly trying 25 com ports where most won't exist, you'll only be trying the com ports that actually do exist.

[David Lander]

Thanks. I'm a novice developer so I do some things a little wrong. Still learning. I'll check into all that stuff.