Ftd2xx.dll Drivers For Mac
Elodie Akiyama
I have a C# application that's using the FTD2XX.DLL from FTDI. This application is used for multiple generations of a single product and abstracts the physical hardware. There's an FTDI and a HID implementation.
Background aside now. When I instantiate the FTDI class I get a modal, not generated by my code about not finding the FTDI driver and asks the user if the drivers are installed. I tried wrapping this in a TRY/CATCH block but no exception is thrown.
I have the exact same requirements - in my case I'm enumerating the list of standard serial ports and appending this with the list of any attached FTDI devices. If the driver isn't installed, then I'd like to not have those modal dialog boxes appear. One quick and dirty way I've figured out to do this is to check for the file FTD2XX.DLL being in c:\windows\system32 (or wherever windows is installed). The existence of this file basically means the driver is installed.
You shouldn't do this, you should use the latest DLL installed into the Windows system directory by the FTDI driver. If you have an old version of the DLL in your app directory, and the user has newer drivers (possibly installed by some other FTDI-based device), you could have all kinds of trouble.
To avoid the error perfectly, however, you'll need to do the same check that the FTD2XX.DLL does internally (since the DLL obviously can exist on the system without any driver). For example, checking whether the driver is listed in the registry under HKLM\System\CurrentControlSet\services would be a more robust check than the one you have. Still not sure if it's equivalent to FTDI's own check.
So I have been trying to use the FTD2XX drivers and I downloaded what I thought to be the correct file here. After installing it using the instructions found here, I tried to run even the most basic VI that came with the package. For some reason it is telling me that I'm missing an FTD2XX.dll file, which I checked and don't have. I googled to check to see if it came separately but everything I found seemed too general and specific to LabVIEW (it just kind of looked sketchy). Anyway, am I missing some important file on my computer? Or just misinstalled the driver.
So i've done some more research and the problem may be with LabVIEW. I didn't know before, but since linux uses .so's as it's object libraries, it makes sense that a linux OS wouldn't recognize .dll's as the correct ending for libraries. So I guess my question now becomes:
LabVIEW uses wildcards to search for Windows, Linux, or Mac libraries [1]. In your case, try FTD2XX.* as the name of the libary in the Call Library Function node's configuration pane. You'll at least uncover the next obstacle, if there is one.
Dennis - there are lots of reasons for using the D2XX driver with the FTDI devices - it allows you to use things like the libMPSSE driver for doing digital I/O, I2C (e.g. reading/writing EEPROMS) and SPI. I think you also need to use that driver if you want to do things like querying available FTDI devices and the device information (e.g. serial number). If you're just using it as a serial port, you should definitely just stick with the VCP drivers and VISA though.
Yes that is exactly why I am using the D2XX drivers instead of the VCP; they easily allow me to query the device and interface better with the voltage supplies that I am using. If you have any other ideas for acceptable equivalent drivers that might interface better, I would be happy to hear your suggestions.
I am very intrigued by the the conditional disable structure and will probably explore that option later but for now, your first point allowed me to actually get the VI's to work. I simply changed the file name to end with .so and then everything worked like a charm. The only downside, of course, was that I need to do that for dozens and dozens of VI's. But at least it worked. Thank you for your help.
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.
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.
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.
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!
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.
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.
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.
Sometimes the cable drivers can be a bit frustrating to get going (especially with such a big program like Vivado). I know you said you installed the cable drivers, but I would recommend trying to install them again (without having to reinstall Vivado) via this Xilinx answer record. If that doesn't seem to resolve the issue, I would also recommend checking out this thread on our Forum where all of the major troubleshooting steps for fixing cable driver issues/no hardware target detected issues are listed.
7fc3f7cf58