Commands to FTDI virtual COM port via NI VISA interfere with communication with FTDI chip using D2XX drivers

[johnsold · Accepted solution]

It is possible that it does not close ports unitl the program exits unless you specifically tell it to close them (or maybe not at all automatically).  Is that Get Device Description function a VI that you can open and see what it is doing?  If so, check to see that it closes any port it tries to open.

Lynn

[Halden]

Hi Todd

It turns out that when the other program has the VCP on the other device open and the D2XX function won't report the device descriptions, it also doesn't report back the serial numbers.  So I don't know which serial number to use to open the device.

Halden

[Halden]

Hi Lynn,

FT_Get_Device_Description_By_Index calls FTD2XX.dll with the function FT_ListDevices.  I don't think it actually opens a channel to the device.

It sounds like maybe I need to change the second program so that every time it wants to communicate to its VCP device, it should open the COM port, send the command, get the response, and close the COM port.  Right now, the program leaves the port open while it runs (and does lots of other stuff) and then closes the COM port when it stops running.

Halden

[johnsold]

It would not surprise me that the dll attempts to open a channel.  How else would it discover the connected devices?

Generally open port, write/read, close port is not very efficient. In your case it may make sense if the communication is rather infrequent.  If you go that route, try to make the error handling robust so that any time it fails to connect, it will pause briefly and then try again.

Lynn

[Halden]

Thanks, Lynn, your advice helped solve the problem!

It turns out that the function to find the FTDI devices won't work if it encounters an FTDI device (the VCP) that is already open.  It won't even return descriptions of the other FTDI devices that aren't open!  The solution is:

Ask how many FTDI devices there are.

Ask for the descriptions by index, starting with the highest index (# devices -1) and and counting down.

Keep on asking for descriptions until the second DLP description returns or the 0th index (which means there is no DLP)

Then, use the index to send the commands to the DLP.

This utilizes my observation that the VCPs always appear as the lowest indices in the list.

The DLP returns 2 descriptions, the A and the B.  Sometimes it includes the A or B suffix, sometimes it doesn't.  But A always has a lower index than B, and A is the one that must receive the commands.  That's why I talk to the 2nd one.

Hope this is useful to someone...

Cheers

Halden