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: 

DLL call problem FTDI DLL: works in LV16 but not in LV17

Solved!
Go to solution

Hi,

 

I have posted the issue already under an existing topic, but perhaps it is better to post it as a new topic:

 

We are having issues with the FTDI dll uner LV17. The code created years ago it was working fine until upgraded to LabVIEW 17. 

 

I have run the same code in the same machine with LV16 and LV17 and using 16 works, using 17 doesn't. See below :

LV16_vs_LV17.png

In LV16 I can successfully retrieve the COM port number but in LV17 it gives an error (Invalid Handle).

 

Is somehow different the way to call DLL on LV17?

Both versions are 64 bit and both running with Admin privileges. I have tried to run it in all the possible configurations (First LV17 only, LV16 only, LV17 with LV16 opened, etc) and it is always the same result.

 

The CLFN does not return any errors.

 

I have been in touch with the FTDI technical support and they claim it must be a LV17 issue.

 

Any idea on what to try next?

 

 

0 Kudos
Message 1 of 5
(3,920 Views)

@Dominigomes wrote:

 

I have posted the issue already under an existing topic


https://forums.ni.com/t5/LabVIEW/DLL-call-problem/m-p/3763986#M1060249

 

Note that thread this is probably only related, not a duplicate...

0 Kudos
Message 2 of 5
(3,913 Views)
Solution
Accepted by topic author Dominigomes

What could help is if you attach the actual VIs instead of a (rather unsharp) image!

 

But from a cursory glance at the code I'm pretty sure the issue is that the FT_HANDLE datatype is really a pointer sized variable.

 

The FTDI driver has been originally written in LabVIEW 7.0/7.1 and uses 32 bit integers for this datatype. You are running this in LabVIEW 64 bit, where this datatype really is a 64 bit variable.

Apparently in LabVIEW 2016 and before the register for such a parameter got somehow magically sign extended even if you only pass 32 bit values as parameter. Something in LabVIEW 2017 changed so the sign extension doesn't happen anymore and the upper 32 bit are now undefined.

 

The proper fix for this is to go through the entire FTDI VI function library and:

- Reconfigure in each Call Library Node every FT_HANDLE datatype to be a pointer sized integer

- modify the VI controls that are meant to contain an FT_HANDLE to be 64 bit integers

 

So yes it is something in LabVIEW 2017 that causes this, but the real problem is that FTDI hasn't updated this library to support 64 bit LabVIEW. Even if LabVIEW kept sign extending 32 values to 64 bit registers on 64 bit LabVIEW it would still fail as soon as the handle, which most likely happens to be a pointer inside the DLL, happens to be allocated in memory beyond a 2 or 4 GB address.

Note that only LabVIEW 2009 and later is available as 64 bit version and has the necessary configuration option in the Call Library Node for pointer sized integers, which magically will adapt the parameter to the right size depending on the bitness of the LabVIEW version.

Rolf Kalbermatter
My Blog
Message 3 of 5
(3,882 Views)

That works!

 

Thanks a lot for your help.

 

I will communicate the information to FTDI as well.

 

Thanks again!

0 Kudos
Message 4 of 5
(3,869 Views)
Thank you very much , it worked 😄😄
0 Kudos
Message 5 of 5
(3,097 Views)