Labview with FTDI D2XX drivers?

[Parker0110]

I have a new issue to use labview with FTDI D2xx driver. 

I have labview 2017,2018,and 2019, the FTDI device is DLP USB245M-G2.

I downloaded the latest FTDI D2xx driver from https://www.ftdichip.com/Drivers/D2XX.htm

I downloaded the example code from

https://www.ftdichip.com/Support/SoftwareExamples/CodeExamples/LabVIEW.htm

I pointed the correct ftd2xx64.dll to each of the labview modules.

The example code is run perfectly on multiple windows 7 computers. I can write and read bytes to/from DLP USB245M-G2 without any problem.

The problem is the same procedure won't work on any windows 10 computer. By using the same example code and same hardware, there is no byte can be send out. I dig deeper in to the example code, the sub-module FT_Get_Device_Description_By_Index.vi, and FT_Open_Device_By_Description.vi looks work fine with the FT_Status = 0. But the next sub-module FT_Reset_Device.vi returned FT_Status = 1 which means invalid handle based on D2xx Programmer's Guide from FTDI. And from here, all modules start to return FT_Status=1. And no bytes can be sent out. 

I am very sure, all the version of labview, drivers, example code and hardware are exactly same. The only difference is the example code running on windows7 computer and windows 10 computer. I even try it on multiple windows 7 and windows 10 computers. They all work same.

Does anyone have same issue? Any advice or commence are very welcome.

[JÞB]

---

@Parker0110 wrote:

I have a new issue to use labview with FTDI D2xx driver. 

I have labview 2017,2018,and 2019, the FTDI device is DLP USB245M-G2.

I downloaded the latest FTDI D2xx driver from https://www.ftdichip.com/Drivers/D2XX.htm

I downloaded the example code from

https://www.ftdichip.com/Support/SoftwareExamples/CodeExamples/LabVIEW.htm

I pointed the correct ftd2xx64.dll to each of the labview modules.

The example code is run perfectly on multiple windows 7 computers. I can write and read bytes to/from DLP USB245M-G2 without any problem.

The problem is the same procedure won't work on any windows 10 computer. By using the same example code and same hardware, there is no byte can be send out. I dig deeper in to the example code, the sub-module FT_Get_Device_Description_By_Index.vi, and FT_Open_Device_By_Description.vi looks work fine with the FT_Status = 0. But the next sub-module FT_Reset_Device.vi returned FT_Status = 1 which means invalid handle based on D2xx Programmer's Guide from FTDI. And from here, all modules start to return FT_Status=1. And no bytes can be sent out. 

I am very sure, all the version of labview, drivers, example code and hardware are exactly same. The only difference is the example code running on windows7 computer and windows 10 computer. I even try it on multiple windows 7 and windows 10 computers. They all work same.

Does anyone have same issue? Any advice or commence are very welcome.

---

Every one does.  Thanks for the link.  Read the note "*"  the driver has no support for Windows 10

[glstill]

The note says it does support windows 10:

*Includes the following version of of the Windows operating system: Windows 7, Windows Server 2008 R2 and Windows 8, 8.1, Windows server 2012 R2, Windows Server 2016 and Windows 10. 

[rolfk]

The name of the DLL would indicate that you are probably using 64-bit LabVIEW. That sample LabVIEW library was written long ago most certainly without any 64-bit considerations at all in mind. LabVIEW 7.1 is from around 2003. The first LabVIEW version that supported 64 bit development was 2009, but most programmers who develop interface libraries for DLLs are still not aware of the necessary considerations to support seamless 32-bit and 64-bit operation and if pointed out to that fact they usually respond that they will worry about the problem when they move some day to 64-bit.

You will have to review the entire LabVIEW library to use correct datatypes in the Call Library Node. Most likely making sure that all the handles are configured as pointer sized integer and changing the control to transfer the handles through the connector pain to be an UINT64 would be the first step for that. There are likely other neccessary chances so don't call it a siege if this change will already seem to make the library work! If there is one thing worse than a DLL driver without a LabVIEW interface library, it is a LabVIEW interface library to such a DLL with bugs. It will come an haunt you one day, most likely when you have installed your control system somewhere on the other side of the globe in a remote location and it suddenly starts to crash every other day, with you only having a slow dialup modem link to debug it over!

Note: I just checked the manual and FT_HANDLE seems to be always a DWORD independent of the platform so changing that to a pointer sized integer won't be the solution. Still taking a LabVIEW 7.1 VI library that interfaces a DLL without thorough review of all functions and trying to use it in LabVIEW 64-bit is ALWAYS asking for problems.

Correction: While the original FTDI programmers manual that you can reference from those pages would indicate that an FT_HANDLE is a DWORD, all the newer headers that I could find in the wild actually define this to be a PVOID, so indeed a pointer which would absolutely positively match your observations that all the other functions will return error 1 since they do not receive the full handle when you run it in 64-bit LabVIEW. 

Therefore it would seem to me a very good idea to use the latest FTD2XX.h header file that you can possibly get from FTDI to methodically review EVERY single LabVIEW Call Library Node to be correctly set up. If they changed this declaration they may have changed others too.

Also if you are at it to change the DLL library name you can use a little known (but fully documented) LabVIEW feature to write the DLL name as ftd2xx**.* instead of ftd2xx64.dll.

LabVIEW will automatically replace the double star with nothing on 32-bit versions and with "64" on 64-bit versions. The last star after the dot as extension separator will be replaced by the platform specific shared library extension which is dll on Windows. 

[glstill]

With that all being said, perhaps it would be easier to install the 32-bit version of LabVIEW and try it out.

[rolfk]

---

@glstill wrote:

With that all being said, perhaps it would be easier to install the 32-bit version of LabVIEW and try it out.

---

Fully agree on that, but for the benefit of other users who seem to have had problems with that or are coming across this in the future when trying to execute the FTDI library in 64-bit LabVIEW it is now officially documented what the problem is!

The full solution would be for FTDI to update the LabVIEW library to 2009 and carefully review its contents. I don't have any intentions of creating such a fixed version and especially supporting it.

[Parker0110]

Thank you so much Rolf and glstill for your reply. I will try your suggestions and will post the result. At the meantime, I contacted to the FTDI tech support about the issue. However, feels like they don't know what's going on and keep asking me the irrelevant questions. If I can get anything positive reply from them, I will also post it in here.

Thanks again!

[rolfk]

Most likely they don't even know what LabVIEW is and have nobody who could care. They had at some point someone who was using LabVIEW 7.1 and did this for some reason, maybe an important client with a large opportunity or just for the fact that this person liked LabVIEW. This person most likely has long left the company or moved on into a different position where he couldn't do LabVIEW developnment anymore even if he wanted to. All the others don't know and won't care.

LabVIEW 7.1 is from 2004. That is 15 years. People change carriers several times nowadays in this timeframe.

[Parker0110]

Finally, I install the 32-bit of labview and use FTDI 32bit dll file. It does work. Now the labview program can work on Win 10 computers. I talked to the FTDI tech support, they said they don't have the programmer to maintain the labview code anymore. So I guess that's it. If you want to use the FTDI driver in labview, make sure to install the 32bit version.

[expfox24]

I am having exactly the same problems as you were having, can you tell me where you got the 32 bit dll from?  If I try to get it from FTDI the 32 bit version still contains a dll named ftd2xx64.dll.

Did you use the example code from FTDI or create your own?

Could you post the code that you managed to get working?