VISA Device Info (Manf Name) FTDI

[_Xilinx_]

I would like to read the Manf Id from my USB devices (FTDI TTL-232R-3V3) but the Visa Device Info always returns an Error (Property Node (arg 2) in VISADeviceInfo.vi).

The only info I can fetch is the 'Rsrc Name' , resulting in ASRL88::INSTR , the rest is left blank coz if the error -1073807331 - Property Node (arg 2)

I was wondering if the problem can be that I am not an administrator on my PC...?  Just like I can't change anything in device management.

Anyhow I need this to work without Admin rights..

Can anyone tell me where I can find a list of all possible attributes I can use?  I found below two attributes in the LV HELP

This works fine, in VISA Find Resource Function

ASRL?*INSTR{VI_ATTR_ASRL_BAUD == 9600}

 

This doesn't work for me, in VISA Find Resource Function 

ASRL?*INSTR{VI_ATTR_MANF_ID == 0x403}

Thanks in advance for your help!

[TomTr]

Hi _Xilinx_,

The reason that it doesn't read the Manf ID is as the device is not made by National Instruments and therefore the stored properties are different. 

You should look at the data sheet for your device, found at the following link:

http://www.ftdichip.com/Support/Documents/DataSheets/Cables/DS_TTL-232R_CABLES.pdf

Under Appendix A - Cable EEPROM Configuration you have a list of the properties that you should be able to read.

Let me know if this helps,

Tom

[_Xilinx_]

Thanks TomTr,

Do you mean I can NOT use the Instr Property node to read properties for devices NOT from National Instruments?

For my FTDI-device , I have for example the 'Manufacturer Name' parameter  (6th param in Appendix A in the document you refer to), how can I read that parameter?

[TomTr]

Hi _Xilinx_,

I've been doing a little bit of research into this and as far as I can tell you are right, that is the way to read the properties. I had assumed that the appendix in the data sheet was the list of data you could read but i may have been wrong. Your device may not be completely compatible with the VISA drivers which could explain why you can't read the properties. You may need to get in contact with the manufacturer to find out what properties you should be able to read from it.

Kind regards,

Tom

[_Xilinx_]

Thanks for your help Tom!

I found the list of all available attributes in NI MAX 14.0 ,   (Below is my FTDI device info)

I was hoping there would be a unique identification (like serial number) but there is not. Even Manf_name stays National Instruments (as where it is a FTDI device)

Conclusion: there is no way I can identify my ftdi device from Visa Device-info.vi upon a surprise removal.

Although, I found a trick to prevent windows from re-enumerating my COM-port before they are released bij LV  -> instant VISA Close upon rx-fail.

I will need to install the D2XX drivers from FTDI to be able to read my serial numbers... see here: ftdi CodeExamples

But I don't really want to include this DLL in my code distribution...

[Dennis_Knutson]

Why do you care if a com port is using an FTDI chip? It's what is connected to the port that is usually important. By looking for a specific manufacturer, you limit the flexibility by not being able to swap the converter to another vendor if your original device needs to be replaced.

[rolfk]

The problem here is that VISA reports really the information that the VISA passport for the serial ports defines. This passport has been developed by NI so that is what is reported. The underlying Windows COMM API that it uses does not provide a standard method to read interface specific properties beyond things like baudrate, data bits, etc. For NI interfaces the according hardware device driver implements some custome IOCTRL calls that the VISA passport can use to query extra informations or set special features such as the wire mode for RS-485 interfaces. These IOCTRL calls are NI specific. FTDI may implement also some custom IOCTRL calls as might Prolific and others, yet they are not all officially documented nor standardized in any way.

NI-VISA being an NI product can implement custom handling for NI hardware but it's pretty dififcult to support other such custom interfaces for non NI hardware as they could easily break with a different version of the device driver. So it's much simpler to not attempt to do it than trying to do a continous catch up with these drivers and certainly miss certain specifc feature differences between manufacturers and driver versions.

A fairly robust way to implement some more specific device detection yourself is to query the registry for every COM port. Usually the name in the registry contains a bit more device specific information, but can in certain cases completely go ashtray if Windows doesn't recognize the particular low level device driver or for virtual COM interfaces, the USB bus enumeration information is faulty.

[JÞB]

Open MAX

Select on of the FTDI TTL-232R-3V3 in the devices and interfacec and "Open VISA Test panel"

From the VISA Test panel select "Attibutes"

Since I have one of those sitting right here........

I can see that that device type does not use VI_ATTR_MANF_ID

You SHOULD be using the Configuration API to do these things.

NOTE: also use the "Ignore Errors Right-click option on the Property node to attempt reading other values pass the first error.  The first error will still be reported but any existing properties will be returned.  (Observe the error out glyph becomes red)

[_Xilinx_]

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,

[rolfk]

One question would be if it is really useful to identify the ports based on the FTDI interface used rather than what device is connected on the serial side. Do these devices support some device identification query? That would also take care about accidential test setup connection errors.

Also use of command line utilities is definitely not something you should avoid on some fears. Under Unix this is the standard way of doing business. Under Windows it is less used since most applications tend to be GUI applications rather than command line tools, but there is no good reason to avoid them if they do what you need to do.