Labview 2020 32-bit unable to load .dll

[axjones0009]

I am trying to use Labview to write code that will interface with a Futek torque cell (TRS 705) and a Futek amplifier (USB520).  Futek has support software on their website, and they have a .dll (https://media.futek.com/content/futek/files/downloads/futek-usb-dll.zip).  We have an older .dll library and some legacy sub VIs that were made a few years ago that somehow got corrupted, so I am trying to clean them up and make the usable again.

The futek .dll will not load into Labview.  I have tried dropping a .NET constructor into the block diagram as well as trying to add the .dll via Tools-Import-.NET controls palette, and I keep getting an error that says 'This assembly contains no public controls'.  I put the .dll file into the same directory as the labview.exe and it still didn't work.

I have been in contact with Futek, and the person who has been helping me doesn't know why I'm having my issue.  He says that he is running 2017 Labview, both 32 and 64 bit, and the .dll loads fine.  Futek did not have a legacy .dll they would send me.

To help myself understand what's going on, I also tried the labview .dll example I found in C:\Program Files (x86)\National Instruments\LabVIEW 2020\examples\dll.  Labview can't open the dll there either, but now with an error that throws a 'System.BadImageFormatException'.  If there was any .dll that should work, I figured the example .dll would so now I am wondering if somehow my labview program is corrupted, or I am missing something.

[rolfk · Accepted solution]

There are two very different types of DLLs under Windows. One is a classical DLL that must be loaded dynamically and then access its exported functions. This sort of DLL can be accessed in LabVIEW with the Call Library Node. Then there are .Net assemblies, for which Microsoft in their infinite wisdom choose to use the same file extension. They have pretty much nothing to do with each other, other than that they are both external libraries that get dynamically loaded at runtime.

So you first need to make sure that you are not barking up the wrong tree. Trying to use .Net nodes on a classical DLL is about as useful as howling at the moon. The opposite is equally true, the Call Library Node has no idea what to do about a .Net assembly.

Looking at the archive you posted a link too, the DLLs seem to be indeed .Net assemblies. And there are three variants of them. One for 32-bit, one for 64-bit and one for Any. The two fixed bit variants are apparently mixed mode .Net assemblies that contain precompiled binary code directly linking to the FTD2XX.DLL. Without installing the FTD2XX driver on your system somehow they can't be loaded. The Any variant is probably programmed fully in C# accessing the FTDI DLL through .Net Interop. But it still seems to contain this hard dependency on the FTDI DLL without using delay load. And even if it did use delay load you would get runtime errors (if it was cleanly programmed) or crashes (if it was sloppy programmed) without the FTDI DLL present on your system.

So head over to FTDI and download this package and install it on your system. Installation instructions can be found here.

[axjones0009]

That worked!  Thank you so much.  How did you know that there was an underlying call for the FTDI driver?  I opened the .dll in VS code and notepad but it just showed up as a mess so I couldn't decipher anything.

If I make a subVI library using the Futek .dll, do I need to include the FTDI driver?  I'm thinking about trying to mitigate this issue for future employees, and wondering if there's a way to make the sub VIs self sufficient, or providing better error handling than what the Labview's .Net constructor node produces.  Or is this FTDI driver only an issue when initially importing the library, and once sub VIs are made and other employees use them they will not have this issue?

[rolfk]

Dependencies is a very simple but helpful tool to see, what dependencies an executable or DLL has. It's the successor of Miicrosoft's Dependency Walker, a tool they used to distribute with their Windows SDK but didn't update to be able to handle 64-bit binaries and other newer Windows features such as Side by Side loading.

Visual Studio itself can't do that. And doing a disassemble while in principle workable is a lot harder to interpret and find out all those details. Also it is usually against the license agreement for most commercial software to do that.

There is no good way to make your VI library self sufficient. Such dependencies should be installed by the according software installer, since hardware access usually requires specific kernel drivers and/or registry entries that only the manufacturer really knows how to deal with. The real solution is to document such dependencies including where to look for to download and installer, and archive the current installer somewhere too.

[cordm]

You can look at DLLs using a tool like https://lucasg.github.io/Dependencies/. It can list dependencies and exported functions.

The FTDI D2XX driver is listed as a requirent on Futeks website in the installation guide, https://www.futek.com/sensit-software-support. So your users will need the FTDI driver on their machines. The FTDI website (https://ftdichip.com/drivers/d2xx-drivers/) conveniently states that you can distribute the driver as long as you keep the license info.