Talk to a 32-bit DLL file using a VI in 64-bit LabVIEW

[tdeshp]

I am trying to communicate with an ADC evaluation board (from Analog Devices) using LabVIEW in order to store and process the data collected by the ADC. The board came with an installation CD which installs the drivers and the interface software; this interface is used to control and display the data collected by the ADC. This interface, from the look of it, was clearly written in LabVIEW, although it currently is an .exe application in Windows. But fortunately, the installation CD also contains a bunch of LabVIEW source VIs which were used in the creation of this interface. After digging around a but one thing is obvious: the executable (from the LabVIEW file) or the native LabVIEW files themselves talk to a DLL file which in turn communicates with the baord at a low level. So no matter what I use: LabVIEW, MATLAB, C, etc., I am going to have to talk to the DLL.

Okay, getting back to problem with LabVIEW, when I open the source files (for the board interface) in LabVIEW I get some errors. When I traced down the errors back to their source I saw that, in the sub-VIs directly linking to the DLL, the path to the DLL file was incorrect. When I selected the correct file I got the message: "The library selected is not valid for the current platform. For example, you are running 64-bit LabVIEW and the library might be a 32-bit library"

That message is correctly guessing that this indeed is a 32-bit library. My question is how can I solve this issue without having to install a completely new 32-bit version of LabVIEW?

[mishklyar]

If the vendor provides only 32 bit DLL,the shortest and the most obvious way is to have the 32 bit based LabVIEW version.

If this is not an option, it is still possible to use 32 bit DLL, but you would need to write one 32 bit executable/ActiveX server

using C++ for example that uses this 32 DLL, and one 64 bit DLL for interface with Labview, and do some kind of inter-process

communication between two 🙂

Michael.

[tdeshp]

Thanks for your response Michael. But the reason I chose LabVIEW over other programs is that I don't want to deal with the low level programming! The manufacturers (Analog Devices) have done this for me! That's what made LabVIEW an appealing option.

I find is very surprising that a well-known program such as LabVIEW does not have something in-built to deal with stuff like this. Having backward compatibility pretty common in almost any decent software product. I would love to just install a 32-bit version to solve my problems, but I cannot afford getting a second LabVIEW.

[kegghead]

Quite simply you can't call a 32-bit DLL from a 64-bit application. This isn't a LabVIEW specific thing, it's a basic fact about matching architectures in any language. There are some exceptions when calling Windows DLLs because Microsoft has put a lot of effort into it's Windows on Windows emulation layer, but if you're dealing with non Windows libraries, you will have to match architectures.

If AD only supplies 32-bit DLLs, you'll either need to write translation code or use 32-bit LabVIEW. There's no way around it, and the same would hold for any language.

[DFGray]

If you own a 64-bit version of LabVIEW, you also own the 32-bit version.  Download the 32-bit version corresponding to your 64-bit version, use the same serial number to activate it, and you should be good to go.

[tdeshp]

Oh cool! I didn't know that. Thanks a lot DFGray.

tdeshp