[SOLVED] USB connected device- How to access 'Bus Reported Device Description'

[Username]

@Avra , Thanks for jumping in here. I'm glad to get your take on this.

If you know that your users will always use some specific USB<>RS485 or similar adapter to connect to PLC, then you might query WMI to ask for manufacturer info of all serial ports and search for a match. Or you might ask the user to choose only the first time and then compare and match that info on all later attempts.

It will always be USB or RS485, no TCP. This is what I'm doing in the above code, searching all serial ports using PnPDeviceID to ID the device. The reason only one device shows in the screen shot is because the ShowMessage Dialog pops up immediately when found, and my device happened to be the first one found. after clicking OK, two more devices are listed in the Memo but they don't match the criteria, so it works as intended.

But there might be a better way if you only have one PLC, and that is to get a list of all COM ports, try to open them one by one, and for those that can be opened try to send manually a specific message that only PLC should be able to understand and reply (like MODBUS query - but do it before Pascal SCADA communication driver initialization), and see if an expected answer shows up.
That way you could identify COM port of a PLC without user's assistance, whatever serial adapter is used.

I like this way, and I thought about it myself, but wish I knew a couple things for sure... Maybe you can help answer?
 
(1) Is the PnPDeviceID subject to change at any time by the manufacturer eg with driver updates? If so, the current code is not ideal, as it could break. If it's written in stone for this manufacturer and every device of this make/model, then I'm good with code as is (as long as I also ID the serial number to ensure it's my product and not another unit of the same type.)

(2) If I choose the Modbus query way of ID'ing the device, that would just be a 03 Read register for a 1-byte device ID # and another a pair of 03 reads of the two 4-digit serial number locations. I could ship the units with the serial # in an inf or have user enter the number upon installation.

I assume that unexpectedly querying any device with a read request it may or may not understand can do no harm. Is that assumption correct? (I expect you'll answer in the affirmative or else you would not have suggested it! ) But in the case of a second unexpected device of the same type, it will answer, and so I must ascertain it's mine, or a different one, and serial number is the only way to know. It's unlikely, but probably should consider whether querying some other device while it's busy with a task (not mine) poses any potential problem.

(3) Must I ensure that I set the device's Modbus address to one that's not being used already, or does that matter only with TCP? I expect it's only a TCP issue, not serial?

[Username]

If you know that your users will always use some specific USB<>RS485 or similar adapter to connect to PLC, then you might query WMI to ask for manufacturer info of all serial ports and search for a match. Or you might ask the user to choose only the first time and then compare and match that info on all later attempts.

That's unworkable though if there are multiple devices in different roles.

I think OP's asking about Windows, but if I can throw in a Linux perspective for completeness: any device which is plugged in and recognised by a kernel driver creates various things in the /sys tree, but the precise layout is driver-specific i.e. the relative positioning of device name etc. for (say) an FTDI serial adapter might not be the same as those for e.g. a CH340.

If the device isn't recognised by the kernel then the best one can do is use the libusb API.

In the case of genuine FTDI serial adapters, each is supplied uniquely serialised in EEPROM and if necessary this can be overwritten with e.g. the serial number of the kit it's interfacing with. Don't expect this to work with rip-off copies, of which there are several variants.

MarkMLl

@MarkMLI , Thanks for your input.
The device does have a real FTDI chip, with serial number stored. I didn't know it could be re-written, but I would not want to change it anyway. You have also addressed the possibility of multiple devices in different roles, and that definitely has merit.  As I am able to read the serial number, I think asking the user to enter the serial number during installation of my software will solve any potential problems there. The serial number is printed on the device case as well as in EEPROM.

For now, I'm only looking at Windows, but I have used Ubuntu for years running my little cnc machines in my shop, and I might be looking at that aspect as well in the future. But for now, just getting a commercially viable product rolled out is somewhat daunting, without venturing into Linux at the same time. Although I do wish Linux was as ubiquitous as Windows.

[MarkMLl]

The device does have a real FTDI chip, with serial number stored. I didn't know it could be re-written,

Just about anything can be rewritten, although I've only dipped my toe in at the moment. That's how FTDI bricked clones with a Windows device driver: if a clone were detected its VID was rewritten so as not to claim to be a genuine FTDI device.

Which leads to your

(1) Is the PnPDeviceID subject to change at any time by the manufacturer eg with driver updates?

Experience suggests that the reverse is more of a problem: manufacturers using the same VID:DID for widely-differing devices, with the actual device description (e.g. what firmware the driver should load to it) being determined by some obscure endpoint register. Ignoring for one moment the widely-experienced problem this caused to (Linux) webcam support, I've actually seen a weather station and a missile launcher claim to have the same VID:DID and it's regrettably common for devices to simply use the defaults from PIC or AVR examples.

And branching out slightly further, you might have seen discussion about using FPC for programming the RP2040 on e.g. a Pico card. I've successfully loaded a .elf file using a Picoprobe driven by OpenOCD and gdb, but digging deeper I was dismayed to discover that the Raspberry Pi Foundation has only reserved a single DID for the Picoprobe which makes it tricky to e.g. debug multiple networked targets such as the Transputer emulation which did the rounds of the hacker media a few weeks ago.

I won't witter any further but the bottom line is that vendors (i.e. owners of a VID) do seem fairly reluctant to change DIDs, or to allocate more than strictly required.

MarkMLl

[Username]

... but the bottom line is that vendors (i.e. owners of a VID) do seem fairly reluctant to change DIDs, or to allocate more than strictly required.

MarkMLl

Now that you mention it, this PID is PID_1020, but the actual device is a 1050.

I read about FTDI doing that bricking thing. I don't think I'll have to worry about that as I believe it's a legit FTDI chip. But given that I now know the PID is not device specific, I'll need to rely on the Serial #.

Here's another question if you don't mind, The VID is VID_2044. Do you expect that will always be true for this manufacturer? If so, that's a good filter for a first-round USB Port search, followed by a serial number query directly to the device.

Thanks,
Dave

[bobby100]

@Avra , Thanks for jumping in here. I'm glad to get your take on this.

If you know that your users will always use some specific USB<>RS485 or similar adapter to connect to PLC, then you might query WMI to ask for manufacturer info of all serial ports and search for a match. Or you might ask the user to choose only the first time and then compare and match that info on all later attempts.

It will always be USB or RS485, no TCP. This is what I'm doing in the above code, searching all serial ports using PnPDeviceID to ID the device. The reason only one device shows in the screen shot is because the ShowMessage Dialog pops up immediately when found, and my device happened to be the first one found. after clicking OK, two more devices are listed in the Memo but they don't match the criteria, so it works as intended.

But there might be a better way if you only have one PLC, and that is to get a list of all COM ports, try to open them one by one, and for those that can be opened try to send manually a specific message that only PLC should be able to understand and reply (like MODBUS query - but do it before Pascal SCADA communication driver initialization), and see if an expected answer shows up.
That way you could identify COM port of a PLC without user's assistance, whatever serial adapter is used.

I like this way, and I thought about it myself, but wish I knew a couple things for sure... Maybe you can help answer?
 
(1) Is the PnPDeviceID subject to change at any time by the manufacturer eg with driver updates? If so, the current code is not ideal, as it could break. If it's written in stone for this manufacturer and every device of this make/model, then I'm good with code as is (as long as I also ID the serial number to ensure it's my product and not another unit of the same type.)

(2) If I choose the Modbus query way of ID'ing the device, that would just be a 03 Read register for a 1-byte device ID # and another a pair of 03 reads of the two 4-digit serial number locations. I could ship the units with the serial # in an inf or have user enter the number upon installation.

I assume that unexpectedly querying any device with a read request it may or may not understand can do no harm. Is that assumption correct? (I expect you'll answer in the affirmative or else you would not have suggested it! ) But in the case of a second unexpected device of the same type, it will answer, and so I must ascertain it's mine, or a different one, and serial number is the only way to know. It's unlikely, but probably should consider whether querying some other device while it's busy with a task (not mine) poses any potential problem.

(3) Must I ensure that I set the device's Modbus address to one that's not being used already, or does that matter only with TCP? I expect it's only a TCP issue, not serial?

1. https://www.ftdichip.com/Support/Knowledgebase/index.html?caniuseftdisvidformypr.htm
2. it won't do any bad if you 03 an unknown device. I am doing it on regular basis
3. only identifier is the unique Unit ID (e.g. Device Address for RTU). Master is always on Address/UnitID 0. Needed for both TCP and RTU.

[MarkMLl]

Now that you mention it, this PID is PID_1020, but the actual device is a 1050.

Here's another question if you don't mind, The VID is VID_2044. Do you expect that will always be true for this manufacturer? If so, that's a good filter for a first-round USB Port search, followed by a serial number query directly to the device.

I should of course have written PID rather than DID :-(

The 16-bit VID is something that FTDI has had allocated to them by (I think) the USB Consortium, so is effectively their "property" in the same way as the top few bits of a MAC address identifies a manufacturer. My recollection is that the same VIDs are also used for things like Bluetooth-connected peripherals.

I think it's reasonable to assume that the VID applied to a device won't change: once allocated, a manufacturer is unlikely to yield a VID. What I think you will find however is, by analogy with what's happened to MAC addresses, a continued tendency of companies to merge which will leave an increasing proportion of VIDs in the hands of a very small number of players.

Just be thankful that Logitech bowed out of CNC-related stuff decades ago...

MarkMLl

[bobby100]

@MarkMLI
The link I gave in my previous post (FTDI knowledge base) explains the FTDI's politics about VID and PIDs for FTDI devices.
A sub-company can get 8 PIDs free of charge from FTDI, to use with FTDI's VID.
A sub-company can use own VID by using an external EEPROM (next article in the knowledge base).

[Username]

@MarkMLI Thanks!

[Username]

1. https://www.ftdichip.com/Support/Knowledgebase/index.html?caniuseftdisvidformypr.htm
2. it won't do any bad if you 03 an unknown device. I am doing it on regular basis
3. only identifier is the unique Unit ID (e.g. Device Address for RTU). Master is always on Address/UnitID 0. Needed for both TCP and RTU.

Thanks @bobby100,
OK, in the LAZ Object Inspector, there is listed, for a pascalSCADA TPLCTagNumber  object, the PLCStation Property, which is the Modbus address for the Device, which I can set to anything from 1 to 247. It comes set at 4 out of the box, and that's what it is now.

So what happens if a user plugs this device into a USB port, and I 03 the serial number, at Modbus address 4, and there is already another device on a different USB port, with Modbus address 4?

[MarkMLl]

The link I gave in my previous post (FTDI knowledge base) explains the FTDI's politics about VID and PIDs for FTDI devices.
A sub-company can get 8 PIDs free of charge from FTDI, to use with FTDI's VID.
A sub-company can use own VID by using an external EEPROM (next article in the knowledge base).

Yes, which is common policy for the manufacturers of microcontroller-like devices (Microchip, Cypress etc.). However in the case under discussion we are talking about the basic FTDI USB->serial convertor, not e.g. something from the Vinculum product range where configurability is emphasised.

MarkMLl

[MarkMLl]

So what happens if a user plugs this device into a USB port, and I 03 the serial number, at Modbus address 4, and there is already another device on a different USB port, with Modbus address 4?

I am /so/ glad that @Bobby100 has volunteered to answer that... :-)

MarkMLl

[Username]

I am /so/ glad that @Bobby100 has volunteered to answer that... :-)
MarkMLl

HA! I don't usually write LOL but I am! Very funny. 

[bobby100]

You can have same address on different COM ports (different USB Port = different COM port).
In PascalSCADA you are communicating with a device with UnitID over one selected COM port.
I didn't try to use PascalSCADA with more than one COM port at the same time. Dunno if it is possible at all.
I did try to use PascalSCADA with more than one TCP connection, and it didn't go well. The CPU usage was 99%. Probably my bad code, but I couldn't find the source of the problem.

My last couple of works that have had something to do with ModBus - all of them are ModBus Slaves, and PascalSCADA can only work as a ModBus Master.

[Username]

You can have same address on different COM ports (different USB Port = different COM port).

OK of course.  I can see that now. The other device would not even be aware of the request since it's on a different USB port. Thanks.

[Username]

Another question for anyone please,

Maybe this question should be in a separate thread, so if it gets too involved, I'll start a new one, but, right now I have a good deal of code written that communicates with the device. Read 03 and write 06 commands. I can do everything I need to do so that's not an issue. BUT:

I'm only writing and reading, with no error checking. I understand that the MSB of the Modbus response will be set if an error occurred, but I don't know how to get that response in pascalSCADA (or at all, really.) I looked at the pascalSerialPort.pas Unit and I can see there's a record structure involved and a lot of setup and overhead routines. Is there a _minimal_ example anywhere that just shows at a minimum how to get and interpret a single Modbus command response from the device?

After considerable searching online I have yet to find anything.

TIA