LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

configuring the call library node

Hi all,
We have a dll which until now was always situated in the same directory.
To produce executables we have get the .dll into the target directory.


My problem is that during the developement I can have several copies of the .dll residing in different directories. If right click on the function and select configure and type in the new path to the .dll, and save the VI. On reopening the VI often still has the path to the .dll in its original location.
can anyone offer advice?
thanks dht
0 Kudos
Message 1 of 8
(4,137 Views)
This is tough to troubleshoot without having all the VIs in front of me, but I suggest the following:

Work your way up from the bottom of your VI hierarchy, opening one at a time each VI that calls the DLL in question. Change the path, save, close, and repeat with the next VI higher up the hierarchy.

My theory is that the new path isn't "taking" because some other VI in memory still has a hold on the old path.

You'll be doing yourself a favor if you can minimize the number of copies of the DLL you have, and also try to keep constant the relative path between your VIs and that DLL. Speaking of which...

There's often confusion about the path that's displayed in the Call Library configuration dialog. Internally, LabVIEW stores in the VI either 1) the name of the DLL or 2) a relative path from the VI to the DLL (including the name of the DLL). What's displayed in the dialog is either 1) the name of the DLL or 2) an absolute path that is formed by appending the DLL's relative path to the VI's absolute path.

In case 1, LabVIEW uses the system search paths to load the DLL. In case 2, it tries to load the DLL from the computed absolute path.

All of these behaviors are on the list for improvement in a future version of LabVIEW.

Steven H.
Message 2 of 8
(4,108 Views)
Good morning dht,

I must agree with Steven. Keep dll's to a minimum... or better. to one.

I just spent the whole day yesterday debugging a dll. I created an executable version of it just for debug purposes. .... to discover that in one of my TestStand steps, I was using an older dll which did not have recent features!! I had not noticed the slight change in dll names. 😠

I am storing the older dll vintages (and snapshot of the code) into a folder indexed by date. TestStand / LW-CVI (and LV) have NO access to this directory.

I also recommend using absolute directory when selecting the dll (or sub-vi's for that mater). Especially at the early stage when "trying out" several versions of a same/similar named item.

🙂

JLV
Message 3 of 8
(4,099 Views)
Hi all - thanks for the excellent responses. What Im trying to achieve
is to call a single dll, via several Sub vi's, which for the purposes of creating an executable must be in the same directory.
What I beleive is being said that all the subvi calling this vi should be opened individually and repointed to this directory using an absolute path.My concern is that when the application is installed, it will be the absolute path that is used ie not the program files/ myapplication.exe directory. Is my understanding correct?
thanks dht
0 Kudos
Message 4 of 8
(4,084 Views)
You can have multiple vi's / sub-vi's all calling the same dll in the same directory. (one dll, one directory).
The directory can be where you want it to be.

The idea of pointing to an absolute directory is simply to avoid selecting the wrong dll (as I had done).
As you know, the dll may contain multiple functiona that you are calling at run-time.

JLV

( 😉 LV has a very good memory of where you placed code as it keeps a list of folders to search 😉 )
Message 5 of 8
(4,077 Views)
we have dll's in one directory but labview goes to another why it does so even if we delete the directory labview serch it still confuses , as i see labview design engineers hvent completed design of simple software , where is the qa of ni ??????????????
0 Kudos
Message 6 of 8
(4,034 Views)
Hi gili,

Problem:
When I entered the name of a DLL in the Call Library Function configuration window (right-click on the Call Library Function, select Configure), I did not specify the path to the DLL in the Library Name or Path field; I just entered the name of the DLL. Where will LabVIEW look for the DLL? Also, if I included the correct path but later moved the DLL, where will LabVIEW search?
Solution:
LabVIEW will first look in the location that you specified in Library Name or Path field. After that it will use the VI Search Path. The VI Search Path can be set in Tools » Options in the category of Paths.
Note: This search order is different from the search order that is used by an executable built using the Application Builder :
http://digital.ni.com/public.nsf/websearch/862567530005f09c862565c50068363d?OpenDocument
which is :
1)the same directory as the executable,
2)\windows\system (\winnt\system32 for NT systems)
3)any path that is specified with the "set path" command in the autoexec.bat file or listed in the path environment variable on NT

On opening up a vi which specifies a dll, it will still search and load it if it can find it.
After that, unless you unload the vi and all the others holding the dll open, then the LV process has it.
So if you open up a main.vi and it has 3 sub vi's all using the same dll, but it has moved, then you need to change each and every call library node referring to it, and save. Shut them down, and re-open. Best to work without the path filled in and make sure it's available in the search path.

Hope that helps

Sacha Emery
National Instruments (UK)
// it takes almost no time to rate an answer Smiley Wink
Message 7 of 8
(4,019 Views)


I have the same problem described here.  When I change the absolute path of the DLL, while reopening it, it still points to the same old DLL.
What if I want to point to different version of the same DLL in different VI.

Message Edited by mehmetg on 05-03-2006 04:32 PM

0 Kudos
Message 8 of 8
(3,789 Views)