VISA Device Info (Manf Name) FTDI

[_Xilinx_]

Hi rolfk, thanks for posting.

I like your idea of starting with reading the Serial number.  And upon surprise removal I can try to find that device again amongst the new COM ports.

it will take some effort from the LV & Embedded motor control side but it's solid for endurance testing! 

Is it useful to identify...  Yes. Suppose the device under test is always changing, reading the serial number would result in another number each time.

---

My fear for command line tools is based on Running console programs for device recognition (like devcon.exe) usually require Admin rights.

My LV user programs do not have Admin rights. And including Admin passwords hardcoded really frightens me. 

I am very much ok with console programs for flashing microcontrollers in my case. But I try to prevent OS related command line tools.... Will they work on an XP,WIn7(32 or 64?),... is not certain.

[rolfk]

The admin password for devcon has nothing to do with the fact that it is a console application but that it does access privileged functionality in Windows. Every application, GUI or command line, or LabVIEW through a DLL interface trying to use such functionality would have to have admin or possibly even evelated privileges in order to use that functionality (such as resetting a device driver or even just calling device driver entry points that the driver developer considered to require privileged access rights).

Your devices under test might each have different serial numbers of course but the fact that they respond to your query for that serial number means that it is your device. If that device is connected to your computer through a specifc FTDI, Prolific or whatever COM port is usually not the interesting part. You rather want to know that you are really talking to your device under test and not a printer, or one of your measurement devices like a DMM, etc.

[JÞB]

---

@_Xilinx_ wrote:

Jeff,  thanks for thinking along!

How would you recognize your FTDI TTL-232R-3V3 device  on your system, when it gets assigned a new COM-port by windows?  

This happens upon surprise removal, when VISA close was not called yet.  

In my case, I have 5 ftdi's on 1 USB HUB and once in a while they all 5 get disconnected and windows assigns new COM-ports to them.  I would like to cover this removal in my code but I have to be sure that COM10 which became COM16 is the same device.  (I tried devcon.exe removal so that COM16 becomes COM10 again but I prefer not to use any command line utilities in my code...)

I was hoping to be able to read the ftdi serial number (or any unique value, this could be vendor Id I reprogrammed with FTDI_Prog utility) by means of NI-VISA.

---

I like your way of checking the connected ports!

Looks cleaner than mine,

---

There is nothing unique about a specific instance of an FTDI chipset-  AND, its not a device, the "Device," DCE, Data Communication Equipment, is connected through the FTDI Adapter to your host DCT, Data Communications Terminal.   The FTDI adapter should not be thought of as a device!  As Rolfk suggests, use the equipment on the remote end's ID for your needs.

ALSO, you bring up another common issue " once in a while they all 5 get disconnected"

Bad!  Not the users that go and mess with your test set-up! BAD engineering staff management! "Do Not Touch" signs or,  Tagout-Lockout controls...You know, anything like basic "Lab Practices" would prevent the casual disconnections of  an experiment's hardware.  Put the System in a locked room or locked rack if you cannot train "Authorized Personnel" to keep their hands AWAY form the "Cute little wires."   Access Control measures are important!

If your management team has not enforced at least a basic level of "Training"  for the employees in physical proximity to your hardware (Don't touch running experiments).  Update your resume-- you have no future at that employer!