How to scan COM ports and get their information such as location using Labview?

[dadest100]

Hi all,

I have an application where I have 4 serial adapters being read using Labview. My application is autonomous and runs twice a day. The problem I am having is that when the computer RESETS for any reason all or some of the COM ports change their number (whatever was connected to COM9 is now COM8 and so on...). So the Labview is reading the wrong COMs or not reading them at all. 

I know the physical location of my serial adapters, for example: Port_#0003.Hub_#0006. That won't change even if the computer resets. (Or will it?)

Is there any way I can scan all the COM ports that are available at the start of my application and then select which ones I want to use based on their physical location?

Any help will be much appreciated.

Cheers,

David 

[RTSLVU]

If they are IEEE 488.2 compliant and return model number and serial number as part of the response to a *IDN? command.

You can always use "Find VISA Resources" to determine what com ports are available.

Then issue a *IDN? command on each port to determine what instrument is on what com port.

[GerdW]

Hi RTSLVU,

to avoid confusion: you are talking about the "*IDN?" command, do you?

[RTSLVU]

---

@GerdW wrote:

Hi RTSLVU,

to avoid confusion: you are talking about the "*IDN?" command, do you?

---

Oops, yeah thanks you caught it soon enough that I could fix it

[crossrulz]

---

@dadest100 wrote:

I have an application where I have 4 serial adapters being read using Labview. 

---

A simple solution might be to go with something like this guy: StarTech ICUSB2324I.  It is a 4-port USB Serial hub.  So a single USB port will control all of your serial ports and this *should* reduce issues with ports getting reallocated.

[paul_cardinale]

In the past I've tried many many things to try to correlate physical location to COM port number.  I was never successful.  Ideally, the devices connected to COM ports should have readable serial numbers.

[RTSLVU]

---

@paul_cardinale wrote:

In the past I've tried many many things to try to correlate physical location to COM port number.  I was never successful.  Ideally, the devices connected to COM ports should have readable serial numbers.

---

Right, without some kind of unique identifier you are kind of screwed. I ran into this same thing with a bunch of Sorensen electronic loads. They did not put their individual serial numbers in the *IDN? response. So if I had more than one of these in a test system I had to rely on the user manually confirming the instrument locations with a separate program that would write a configuration file the main test program would use.

Also I have found that Windows 7 and newer tends to "remember" what USB-serial adapter was given what port number and always gives it the same one regardless of what USB port it's plugged into.

[dadest100]

Thanks for your answer.

I am using the BLE dongles BLED112 from Bluegiga. I believe they don't support the *IDN? command because I haven't been successful getting an answer from them. This is he error i get. (Image attached) 

[RavensFan]

While *IDN? is the default query in MAX, not many things you connect to in the real world will respond to it.  It is a carry over from the "instrument" class of devices like oscilloscopes and multi-meters, and analyzers.

You need to figure out if there is a particular command that the devices on the other end of your serial/BLE dongles will respond to and give back information that is unique to them, such as a serial number, or perhaps some memory location you can put an identifying code into.

[RTSLVU]

---

@dadest100 wrote:

Thanks for your answer.

I am using the BLE dongles BLED112 from Bluegiga.

---

Yeah that's not an IEEE 488.2 compliant instrument, so 488.2 common commands are not going to work.

But a BT dongle should have some sort of unique identifier. In my limited experience working with HC-05 and HC-06 BT modules I recall there was a command that would give you the MAC address of the BT device. 

Maybe yours has a similar command you can use in place of *IDN?