[Ic3Knight]

Hi All,

We've developed a system control application using a plugin architecture to make the main app "device independent". So far everything is working well, I write device driver VIs for the specific hardware, and then compile them into an llb file which is then called dynamically (by reference to the top level vi in the llb) as needed by the main application.

My problem is this: One of the devices I'm using is controlled in labview using calls to a manufacturer supplied dll file. The manufacturer has also written a bunch of "wrapper" type VIs for using said dll file. Within these wrappers, the "call library function nodes" are set up internally with a path to the dll file to use. When I write my driver VI and then build it into an llb (using openG builder to remove the front panel and block diagrams), the wrapper VIs appear to still be looking for the dll in the original directory (which is within the instr.lib directory). However, when I then dynamically call my driver VI from within the main application (which is being run as an exe) unless the dll is within the root directory of the application, I get an error (stating that the top level vi isn't executable).

What I want to do ideally is specify the (relative?) path to the dll when I build the llb file so that I can place it where I want within my application directory (eg ../App_root/Device plugins/Support/XXXX.dll) Does anyone know how I can do this? (Does anyone understand what I'm rambling about?!)

Any advice greatly appreciated!

Cheers

Paul

[ned]

There's a configuration option for Call Library Node that says "Specify path on diagram." Have you tried setting that option? Then when your application (or plugin) starts, you can store the path to the library in some sort of global storage and pass it to each call library node.

[Ic3Knight]

Hi Ned,

Yeah, I did see that, but to do that I'd have to go through the manufacturers entire set of wrapper VIs and change each one, adding a path to the right dll file... I was wondering if there was any way to tell the labview runtime engine where to look for dll files... (it seems strange to me that when run in a dev system environment, labview looks at the path specified in the "Call library node", but when in an executable runtime environment, it looks in the root directory of the application). Might it be something to do with search paths?

Anyone got any other suggestions?

Cheers

Paul

[rolfk]

Ic3Knight, on 02 February 2010 - 02:32 PM, said:

My problem is this: One of the devices I'm using is controlled in labview using calls to a manufacturer supplied dll file. The manufacturer has also written a bunch of "wrapper" type VIs for using said dll file. Within these wrappers, the "call library function nodes" are set up internally with a path to the dll file to use. When I write my driver VI and then build it into an llb (using openG builder to remove the front panel and block diagrams), the wrapper VIs appear to still be looking for the dll in the original directory (which is within the instr.lib directory). However, when I then dynamically call my driver VI from within the main application (which is being run as an exe) unless the dll is within the root directory of the application, I get an error (stating that the top level vi isn't executable).

Please post such questions in the future in the applicable section (External Code).

The LabVIEW application Builder recognizes DLLs as dependant files and includes them into the build when creating an executable. The OpenG Builder might not do that. An additional feature of the LabVIEW application Builder is to also adjust the location of the VI Paths AND DLL Paths in the compiled version for the build application which the OpenG Builder might also not do for the DLL Paths.

There is certainly a possibility to improve the OpenG Builder to also care about DLLs properly but that is not for the faint hearted.

Once LabVIEW does not find a DLL where it expects it to be it tries once more in the directory where the project file is located (obviously not applicable for executables) and then simply passes the request with only the DLL name to Windows and then the standard search criteria of Windows apply:

1) already loaded into the application memory
2) the executables directory
3) the system directory
4) the windows directory
5) any directory mentioned in the PATH environment variable

So your options would be several depending at which stage you want Windows to find your DLL.

1) Create a specific loader VI that locates the DLL and loads it into memory and also stays in memory and is run before your driver is loaded
2) - 4) copy the DLL in the according location
5) modify the PATH environment variable to point at the location where your DLL can be found