03-04-2020 01:47 PM
Keyboard is not COM port device for long time.
My understanding of your idea is that
- at start, the application connects to all possible COM ports
- user make something with particular device and the device sends COM message into computer
- the application catches the message (there is not requirement to recognize) and knows COM port
- the application provides possibility that user matches the known COM port to particular device from list of all devices
Am I correct? Is so it is also not very helpful ...
- most COM port devices are simple and works as slave only (command comes than device generates answer)
- COM port could be used for multiply devices ...
03-04-2020 03:59 PM
When did I ever talk about a keyboard?
How do you think "most COM port devices are simple".
Serial communication is used in a wide variety of devices from very simple to very sophisticated. As I said, due to lack of information from the original poster, we don't know what devices are being communicated with to know if they are simple or if they have capabilities.
If the device has the capabilities, then the steps you list do show you understand by idea.
The idea just *might* work. PC connects to all devices it sees. Even if it is a "simple slave device" command/response only, if the user can do "something"/"anything" to make the device give a different response. That may mean hitting a button. ("HIT a button" means press a button or something on the device if you need further explanation.)The PC will see the response and know which one was acted on.
If the mysterious device doesn't have capabilities, then of course my idea won't work.
But if you are going to say my idea is "also not very helpful", then you are just being argumentative for God knows what reason.
03-04-2020 04:20 PM - edited 03-04-2020 04:21 PM
@billko wrote:
According to Microsoft, the serial number is defined in the USB_DEVICE_DESCRIPTOR. I think the real reason is that hardly anyone makes use of the field. Many (most?) manufacturers of USB devices even duplicate serial numbers; I have to think they're saving money somehow by doing this. (Besides being an extreme inconvenience, there's no traceability - but that's another issue for another day...)
You are of course right. It is part of the Device Descriptor that each USB device must provide. But as it is strored as a seperate String Descriptor it is optional according to the USB Specification!
I guess Microsoft forgot to say that the string needed to be unique to each unit. 😉
It is not a Microsoft Specification but from the USB Consortium. As mentioned above, the iSerialNumber member of the Device Descriptor specifies a wIndex for a String Descriptor that contains the Serial Number, if and only if that index is not 0. As all String Descriptors in the USB Specification are optional (implementing String Descriptors costs extra control logic to support and registers to store which can be a considerable cost factor of a few pennies 💲 for devices) so according to the USB Specification it is valid to not implement them 😁.
I would guess that the reason for Virtual Com Port devices not to support them is however mostly related to the extra step during finalization of the product to store this unique ID in the chip somehow.
03-04-2020 04:21 PM
1. Estimation level:
- if 90% devices have "HIT" button it is good
- if 50% looks somehow reasonable
Agree?
2. My personal experience:
- I am sure that less than 10% devices in my hands were able to send "update". Moreover, almost all such devices require to enable such behavior.
- application which able to catch device message async (and "HIT" button requires such application!) is more complicated. When I need to connect to new device I look NI device driver. I never (!!!) saw driver which supports async. That is really surprised me!!!
Is YOUR experience different?
03-04-2020 04:30 PM - edited 03-04-2020 04:36 PM
@Vasilich2004 wrote:
1. Estimation level:
- if 90% devices have "HIT" button it is good
- if 50% looks somehow reasonable
Agree?
2. My personal experience:
- I am sure that less than 10% devices in my hands were able to send "update". Moreover, almost all such devices require to enable such behavior.
- application which able to catch device message async (and "HIT" button requires such application!) is more complicated. When I need to connect to new device I look NI device driver. I never (!!!) saw driver which supports async. That is really surprised me!!!
Is YOUR experience different?
Why are we even arguing about this? Who cares? It was just an example of what might be done; more about how to think about it than what, specifically, to do. Just to give the OP some ideas on how one might proceed given the less-than-optimal conditions.
For instance, maybe the application can be scanning an activity log file on all COM ports that responded to a certain command, and ask to HIT a button. The HIT button action is logged, then the application knows which instrument was accessed.
To be clear here, I am not saying that this is how the unknown black box works; it's just an example of the kind of procedure you might follow to correctly ID the black box.
03-04-2020 04:36 PM
... before idea implementation it should be look reasonable 😉
By the way, how to you insert previous message? in old NI website it was logically easy. Then approach changed and I can't remember!
03-04-2020 04:37 PM
@Vasilich2004 wrote:
... before idea implementation it should be look reasonable 😉
By the way, how to you insert previous message? in old NI website it was logically easy. Then approach changed and I can't remember!
This quote thing got me when they changed, too. It's the quote button on the toolbar. It took me quite a while to figure it out. 😉
03-04-2020 04:38 PM
Why do you keep talking about "HIT" button.
All I ever said was "hit a button on the device".
So do you also get lost when a computer screen tells you to "Hit Any Key to Continue?".
A lot of devices have buttons, and can change their behaviors. I never talked about "Asynchronous messages". Why are your reading that into my message?
Many instruments do have buttons on them that you can "hit" (press, depress, push, touch, pick a synonym). A button on many instruments that changes a device between "local" mode and "remote" mode would be something a PC could regularly query on all devices connected to it, tell you to press that button on "Instrument A", and when it gets a response that is different than it was before, it now knows which instrument connected to it must be designated as "A". Rinse, repeat for B, C and D.
My first choice would be to go out and find some decent USB/serial converters that you can rely on not to jump around.
If that is not an option, then I'd try to find a way for the devices to uniquely identify what they are.
Since the OP hasn't had any progress on those two fronts, then my next thing is to "think outside of the box". (That is a figurative box, not a literal box.)
Find something about the devices that let's me interact with them programmatically and physically so the PC can learn which device is related to which measurement entity.
03-04-2020 04:59 PM
@Vasilich2004 wrote:
... before idea implementation it should be look reasonable 😉
By the way, how to you insert previous message? in old NI website it was logically easy. Then approach changed and I can't remember!
found 🤕 time to retire is coming 😎
03-05-2020 09:43 AM - edited 03-05-2020 09:45 AM
All this talk about the "Hit button" and keyboards? Wow talk about clouding the issue guys...
Here's what I see...
Lets forget about trying to figure out what BT adapter is plugged into what USB port and concentrate on identifying what device is on what serial port. Because that is what the OP really needs to know.
My question to the OP is what are the devices that you are connecting via serial?
Is there any type of query you can use to identify them?