From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Finding FTDI Chip COM Port Numbers

Solved!
Go to solution
Solution
Accepted by abeaver
Why didn't you say that this was specific to a certain piece of hardware that you designed? You presented a generic solution and I responded with some problems that I saw. That is certainly useful and not at all clutter. Your remark is quite offensive, as a matter of fact. Should we just stop now?
0 Kudos
Message 11 of 18
(3,486 Views)

Thanks for your feedback on the solution.

0 Kudos
Message 12 of 18
(3,481 Views)

Thanks abeaver

I was looking for something like this and find you code useful

0 Kudos
Message 13 of 18
(3,440 Views)

unsigned long get_COMPort()
{
  FT_STATUS ftStatus;
  LPLONG    PortNumber;
 
  ftStatus = FT_OpenEx("DeviceDescription B",FT_OPEN_BY_DESCRIPTION,&ftHandle_B);
  ftStatus = FT_GetComPortNumber( ftHandle_B, & PortNumber);
 
  return PortNumber;
}

0 Kudos
Message 14 of 18
(3,135 Views)

Note that on a 64-bits machine, the handle represented as U32 will not work.

Most of the utilities here or there, will not work.

The handle must be changed to a U64 everywhere.

See example below:

 

ComportFromFTDIChannel.png

0 Kudos
Message 15 of 18
(1,607 Views)

I've tried using your code to do exactly this, but I can't get it to work within the context of the software I'm developing.

 

Running it on its own with a labjack and 5 FTDI adapters plugged in, I get a list of the 5 FTDI adapters. However, when I run the VI from a parent VI I get a bunch of FT-STATUS errors like "DEVICE NOT FOUND" and "DEVICE NOT OPENED". Specifically, I can only establish a connection with a COM port currently receiving data from a connected DUT.

 

This is the very first attempt at doing anything with the port in the SW, so I know I'm not doing anything wonky prior to checking for FTDI chips. Regardless, these driver calls shouldn't be dependent on the status of the port anyway. I just want to list out all of the FTDI chips connected to my system without attempting to do a handshake over the port... why couldn't they have included a call to just list all of the FTDI port numbers?

 

It's beginning to look like the only solution is to NOT use FTDI adapters, because the drivers do not work well with Labview. Unfortunately, my hands are tied as my company has grandfathered in 1.8V TTL as the only acceptable communication interface. If anyone knows of a manufacturer which provides standard RS232 to 1.8V TTL converters please tell me, because I will drop these FTDI adapters like a hot potato.

0 Kudos
Message 16 of 18
(1,208 Views)

@abenevides wrote:

I've tried using your code to do exactly this, but I can't get it to work ...

 


 

It is interesting that you resurrect an eight year old solved thread just to complain that the posted solution doesn't work, instead of starting a new with your *real* request.

 


@abenevides wrote:

I just want to list out all of the FTDI chips connected to my system ..


I would recommend trying something like this:

Find FTDI COM ports.png

---------------------------------------------
Certified LabVIEW Developer (CLD)
There are two ways to tell somebody thanks: Kudos and Marked Solutions
Message 17 of 18
(1,183 Views)

Thank you!

 

I made a slight modification to your recommendation, because the COM# is associated with the VCP# in registry editor, I can filter the data column by the presence of "VCP" in the name column with ease. This seems like it would be a far more reliable method of obtaining a VISA reference for each virtual com port connected to the system. Apologies for resurrecting a dead thread.

 

abenevides_0-1651770270264.png

 

0 Kudos
Message 18 of 18
(1,142 Views)