LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

What is the proper way to specify the shared library location in a call library function node for a .lvlib function?

Solved!
Go to solution

I'm having a bit of an issue with how to properly specify the shared library location in a call library function node that is is in a VI which is part of a LV library. Here is a bit of background that might help.

 

I do a lot of measurements using photo spectrometers from multiple manufacturers.  Someone in my company developed a DLL library in C that provides an single API for all the different spectrometers. To make that DLL easier to use in LabVIEW, I wrote a .lvlib that wraps all the functions.  When I want to use the API, I simply include the .lvlib file in my project which allows me to drag and drop the wrapper VI's onto my bloc diagram. When I created the .lvlib VI's, I specified the path in the call library node to be ./<DLL Name>.* so it will always look in the local directory of the application for the DLL when I run.

 

The problem is, when I load the application, LabVIEW asks for the location of the DLL even though it is right there in the local directory! I've tried putting copies of the DLL in the directory with the .lvlib, but it still refuses to find the DLL when loading.  What am I doing wrong?

0 Kudos
Message 1 of 5
(4,316 Views)

One other thing.  I tried specifying the location by name rather than by path, and the result was that it was loading the DLL from the system32 directory instead of the project directory. Because I am updating the DLL library also, I need to ensure it loads the version in the local project directory, which is why am using the ./<DLL name>.* path in the call library node.

0 Kudos
Message 2 of 5
(4,309 Views)
Solution
Accepted by topic author MrJimSmith

You should in that case simple enter the full path to the DLL by browsing to it. If the DLL is on the same volume/drive than the VI containing the Call Library Node LabVIEW will internally store the relative path from the VI to the DLL (but still show the absolute path). If you move the DLL and VIs together (so the relative location of the DLL to the VI stays the same) LabVIEW will still find the DLL.

 

I don't think that the lvlib would add anything to that.

Rolf Kalbermatter
My Blog
Message 3 of 5
(4,291 Views)

That solved the loading issue, but what happens when I build the executable?  Will it expect to see the library DLL in the same relative path; i.e. if my lvlib and the DLL is in  directory parallel to the project directory, do I need to recreate that structure to allow the stand-alone exeutable to find the library or can it exist in the same directory as the .exe?

0 Kudos
Message 4 of 5
(4,277 Views)

Never mind, I did a test build and everything works great. Looks like LabVIEW adjusts the path during the build process.  Thanks for the help, Rolf!

0 Kudos
Message 5 of 5
(4,271 Views)