Library Calling Function Issues

[urlmichael]

Hello,

I have a software development kit that I'm working with that provides .lib files (atmcd64d.lib and atmcd64d_internal.lib) and .DLL files of the same name that are located in my /Program Files (x86)/National Instruments/LabVIEW 2013/user.lib directory. I have a master .VI that contains many VI's from that library. However, when I try to load the VI, it tries to find the .DLL file. I manually find the .DLL file for it. When it loads, however, I get errors from all of my sub VI's telling me that they are not executable because of an error.

Follow that error all the way to the root, and I find that the Call Library Function Node says that the "Library not found or failed to load." However, I can't edit this Library Function Node because it's in a VI that's in a library. So, I can't simply point each VI to its proper library.

I think that the problem is that the .DLL is not pointing to the correct libraries. How can I figure out where the .DLL is telling the VI's to look for their Labview Libraries? Do I have this backwards?

I would be thrilled to provide any information necessary. Thank you for your help,

[mikeporter]

What do you mean that you "...can't edit this Library Function Node because it's in a VI that's in a library...". What is preventing you? What library is it? Is it or the VI locked? Why isn't the DLL located at a standard location? Where is the VI expecting the DLL to be?

Mike..

[tst]

Can't say I ran into something like this exactly, but from your description it sounds like the library wasn't installed correctly. Did you go through an installation process or were the files simply copied?

I would have expected that if all the files are in user.lib, then it could find the DLL even if the files were only copied, but maybe they were copied incorrectly or maybe the DLL it's looking for is a different one.

As for the "not found or failed to load" error, I'm going to guess that this is about missing dependencies that the DLL itself needs and which presumably are supposed to be installed with it. I don't have enough experience to know if you would really get this error in such a case, but it sounds reasonable.

[tst · Accepted solution]

Also, your files have 64 in their names (indicating they're 64 bit DLLs?), but the path is in Program Files (x86), indicating that your LV is 32 bit. I'm fairly sure you can't load 64 bit DLLs in a 32 bit process, but I don't have the relevant experience to tell what would happen if you actually try.

[rolfk]

---

@tst wrote:

Also, your files have 64 in their names (indicating they're 64 bit DLLs?), but the path is in Program Files (x86), indicating that your LV is 32 bit. I'm fairly sure you can't load 64 bit DLLs in a 32 bit process, but I don't have the relevant experience to tell what would happen if you actually try.

---

A 64 bit DLL is simply an unintelligent bunch of bytes for Windows if tried to load from a 32 Bit process and vice versa. Windows simply claims the file is not a valid DLL.

[rolfk]

Another thing to watch out for is the d in the name of the libraries (and hence DLLs I would assume). That is a common convention to indicate a debug build. And that could mean that your DLL links with the debug version of the Visual C runtime libraries. However Microsoft does not allow a develeoper to distribute the debug runtime libraries so the only way to get them installed in your system is to get Visual C (of the same version) installed.

You should ask the developer to rebuild that library as release library and fix the VIs to link to that version.

[urlmichael]

I can open up the VI and view the back panel, but when I try to manipulate wires, terminals, or right-click on the Library Function Node, it doesn't give me any options. It's a VI located in the atcmd64d.lib library, which I would assume is the problem. Can one not edit VI's in a library, or is there an option that I have to change to make it editable?

The .dll is located in the SDK install directory, as are many other .DLLs and libraries. Is there a way for me to figure out where the standard directory is? The VI is looking in C:\Program Files (x86)\National Instruments\LabVIEW 2013\vi.lib for the .DLL, but it isn't locaed in the LabVIEW directory, it's located at the SDK installation directory, which is C:\Program Files\Andor SOLIS\Drivers

As you can see, LabVIEW is 32-bit, and the drivers are 64-bit. I'm going to try to install LabVIEW 64-bit and see if that helps.

Thank you!

[urlmichael]

Oooh... didn't see that. Good catch!

I might try to re-install the SDK as a 32-bit process instead, since I'm planning to write the application on one computer (64-bit with 32-bit LabVIEW) and then run it on another (32-bit with 32-bit LabVIEW)