FTDI invalid handle on some computers

[Basilisvirus]

Using LabView 20.0.1 (64-bit) we get FT_INVALID_HANDLE if we try to use the Handle of the device, after the FTDI chip/device is successfully opened. Note that this issue happens to some of the computers we test it on. (on 2 computers the VI runs as expected, on 2 other computers this issue appears) 

We have downloaded the setup executable from FTDI's website: https://www.ftdichip.com/old2020/Drivers/D2XX.htm

And we also have downloaded their VCP drivers (file says it includes VCP and D2XX drivers): https://ftdichip.com/drivers/vcp-drivers/

we installed both drivers without having inserted the FTDI chip in the USB port of the PC.

The VI we run is shown below (and also attached). The device descriptor is Read, the device is opened based on its description. After the device is opened By description, I get error on the FT_Set_Baud_Rate for Invalid handle, and everything after that get invalid handle error (the FT_Set_Data_Characteristics and the FT_Close_Device).

After running the VI on a computer that shows the issue:

Extra tests we did:

-We did test this VI on both chineese/clone FTDI and FTDI chip bought from Mouser. No change in behavior.

-We did try to remove the "FT_Reset_Device from the VI, same behavior:

-We can use the FTDI's libraries .lib files using C/C++ (aka outside LabView), so I suppose this is not an issue with the drivers and windows.

-We can Use FR_Prog to read and program the FTDI chip(s) (The Chinese chip wont save the programmed values though, thanks China).

-A screenshot that shows that this example runs on some computers (with or without the FT_Reset_Device, doesnt make a difference):

I am not sure if I should ask FTDI for this issue first, but I will email them as well.

 Since not all computers show this issue, makes me believe it is an issue related to a combination of LabView compatibility+Computer/windows settings+FTDI drivers incompatibility. 

-How can I debug this behavior?
-I want to know if the handle created when device is opened is the correct one. It looks like the handle I get is "bad", but the handle is just a number, how do I know if the handle is the correct one?

[RTSLVU]

Hmm... Seems to work fine for me, but I am using LabVIEW 2023 Q1 32bit. Maybe the 32/64 bit is an issue?

Nothing to see here... (bad advice removed)

[altenbach]

---

@RTSLVU wrote:

The flat Sequence structure is superfluous. Think "data flow"...

---

Careful there!

Not in this case, because wires are branched to several places, for example the last three steps now execute in random order. They need to be in diagram order else things will break due to race conditions. 

The real question is why there is no error wire....

[RTSLVU]

---

@altenbach wrote:

---

@RTSLVU wrote:

The flat Sequence structure is superfluous. Think "data flow"...

---

Careful there!

Not in this case, because wires are branched to several places, for example the last three steps now execute in random order. They need to be in diagram order else things will break due to race conditions. 

The real question is why there is no error wire....

---

You are right, so I removed my bad advice.

But yeah there should be an Error cluster.  

Honestly this is not surprising, some of the worst LabVIEW I have ever seen was in "instrument drivers" provided by equipment manufacturers.  

[LLindenbauer]

This is the FTDI D2XX LabVIEW example right there, including the empty frame.

---

-How can I debug this behavior?

I guess having a reference C++ implementation to test against is a great starting point. I would suggest digging into the SubVIs one by one, starting with the first one in the sequence. The DLL calls return a success code but if I remember correctly, that might be discarded in the example. Try to branch the return code out and check if the function succeeds.

You could also start working on your own DLL call. FT_ListDevices, for example, should be reasonably straightforward to set up and give valuable insight.

[Kyle97330]

FTDI has a .NET wrapper for this DLL linked to several times on this page here:

https://ftdichip.com/software-examples/code-examples/csharp-examples/

You could try that and see if you get any better results, or more informative ones.

[rolfk]

The real problem is that FT_HANDLE is actually really a handle, aka a pointer sized variable. So in LabVIEW 64-bit it should be a 64-bit integer.

The FTDI library was created circa LabVIEW 7, a time where nobody was even thinking about 64-bit Windows.

The fix will be to go through the entire library and change the datatype for each FT_HANDLE parameter in the Call Library Node to Numeric, Pointer-sized Integer. Leave the passed by Value/Pointer setting as it was. Change all front panel controls that represent the handle to be 64-bit numerics. Voila!

[dkim2]

I was wondering if you could provide more insight into this issue.

I am having the same problem with the FT_INVALID_HANDLE error, using the ftd2xx64.dll library in LabVIEW 2024. 

The FT_STATUS is OK for opening the device, but when using the handle to close the device the status shows that the handle is invalid. I followed the steps to change the datatypes to a pointer sized integer and create a U64 numeric for the handle, and the issue persists.

Is there something else I might be missing or doing wrong?

Thanks

[rolfk]

Did you change the handle in ALL Call Library Nodes to be a Pointer Sized Unsigned Integer?

[dkim2]

Yes.

When I install the driver, the file in syswow64 is the ftd2xx.dll not ftd2xx64.dll, although I am using the call library function on the ftd2xx64.dll from LabVIEW. Could this be an issue?

Thanks