Despite indicating the path, still have to manually point to DLL each time LV Runs using Call Library Function Node

[Steckman]

I am using the Call Library Function Node in LV 8.6. I have checked the specify path on diagram check box and pointed directly to the DLL file I am using. Every time I start Labview I have to go to the diagram and physically go find the DLL in one of my calls in order for it to work correctly. Once I perform this everything seems to work as expected. Has anyone else seen this issue? Any suggestions would be appreciated.

Thanks

[altenbach]

---

Steckman wrote:

I am using the Call Library Function Node in LV 8.6. I have checked the specify path on diagram check box and pointed directly to the DLL file I am using.

---

What is your definition of "pointed directly"? Do you mean with e.g. a path diagram constant?

[Steckman]

I have tried using a path constant but still have the same problem. By "pointing" I mean I actually go into the Call Library Function Node icon\properties and browse to the actual DLL file. After I do this the first time it works like a charm the rest of the session.

[altenbach]

Does it work if you uncheck "specify path on diagram" check box.

I guess I don't fully understand why you have it checked. There must be more to your situation that you are telling us. 😉

[elanimal]

I have seen this many times on multiple computers at work when calling the DLL for the Ocean Optics Spectrometer ( also have seen various posts here on this issue). Best results for me was to check the specify path ( LV 8.1 but not available in LV 7.1 ) and to use the DLL from C:\Windows\System  directory in Windows XP. I usually have a Path Control for this but a path constant should work as well I would think.

Strangely enough, in LV7.1 and not being able to specify the path AND not having the DLL in the System folder , the problem goes away when I compile the appication and run as an executable.

Mario

[smercurio_fc]

I have also seen this problem on occasion, but could never pin down the exact cause. Consequently, I now always keep the DLL in the same directory as the VIs that call it. In the "path" textbox I just put the name of the DLL, no path. I can move the directory around and the code will still work. You can also keep the DLL in the Windows\system32 directory, as suggested. Windows will look for a DLL first in the same directory as the calling app, and then in the system32 directory.

Message Edited by smercurio_fc on 01-18-2009 09:48 AM

[rolfk · Accepted solution]

---

Steckman wrote:

I am using the Call Library Function Node in LV 8.6. I have checked the specify path on diagram check box and pointed directly to the DLL file I am using. Every time I start Labview I have to go to the diagram and physically go find the DLL in one of my calls in order for it to work correctly. Once I perform this everything seems to work as expected. Has anyone else seen this issue? Any suggestions would be appreciated.

Thanks

---

Most likely that DLL does depend on other DLLs that reside in the same directory as the one you are pointing at in the Call Library Node configuration dialog. What happens is this:

Without first going to that directory:

LabVIEW requests Windows to load the DLL, Windows sees that it needs to load other DLLs and can't find them in its standard search locations:

1) already loaded in memory

2) in the application directory (where the exe resides that started the current process, in the LabVIEW IDE this would be where LabVIEW.exe is)

3) in the System directory

4) in the Windows directory

5) any directory the PATH environment variable contains

6) in the "current directory"

Because Windows can't find a dependant DLL it aborts the loading of the main DLL and returns with an error to LabVIEW.

Now you go in the configuration dialog and point to the DLL. The file browse dialog in LabVIEW uses the standard OS file dialog and this dialog has the obnoxious behaviour to always update the "current directory" to the directory from which a file got selected in. Now LabVIEW sees that the path has "changed" and requests the load of the DLL again. Again Windows sees that it needs to load other DLLs too for this DLL but this time going through above search order it will actually hit on the DLL in that same directory et voila everything goes fine.

This is definitly NOT a problem of LabVIEW. LabVIEW does not know and really shouldn't have to know that a DLL needs other DLLs loaded and even more important should never attempt to think it can do DLL dependancy loading better than Windows, which it probably could but which is simply not its task.

It is your responsibility as programmer and user of that DLL to know about its dependencie, and if you haven't written the DLL, to hit the original programmer on his head if he hasn't documented those dependencies, and make sure that those dependencies are actually properly resolvable for Windows by putting them in one of the above mentioned locations

2) is usually the best location for built applications since it will not pollute the Windows or System directory of the application user and 5) is the best for the development machine since you can add a directory to your PATH environment variable where you put the DLLs you need for developing a specific application.

Rolf Kalbermatter

[Claire_Reid]

When you place a checkmark in the Specify path on diagram checkbox, any library referenced in the Library name or path control will not be used. Try unchecking this box and specify the path in the Call Library Function Node.

[Steckman]

I appreciate all the quick suggestions and explanations. The first technique I tried today was to put the two suspect DLL's into the windows\system32 directory and everything worked just fine. I understand this is probably not the preferred method. This at least seems to go along with the general explanation of the search paths and loading of the libraries. I also plan to try removing the check box for showing the path, and see what type of influence that has. Looking back on it all now, this has been my first experience using the call library interface node, and during the early stages of creating this program I had several crashes and may have ended up checking this box without a full understanding of its use which has further complicated my issues to date. The various explanations and suggestions have given me a lot more insight into how LV and Windows deal with DLL's. Thanks to all

[NimbleThink]

My recollection is that you had to modify the Windows PATH variable to include the path with the Omnidriver DLL in it, and that you had to have that DLL in the directory in which it was installed by the OO installation script.

There may have been another environment variable which had to also be set, however I am not sure (it's been 2 years since I dealt with OO's DLL).

Regards,

Leif Kirschenbaum, Ph.D.