DLL Load Error in Labview 2011

2
votes

I have encountered a problem with loading a DLL in LabVIEW.
I am using LabVIEW to connect to a flow meter, and for this purpose the company that makes the flow meter was nice enough to give me a library of subVIs. Each of those subVIs calls a function from one of two DLL libraries also provided by the company.

So half of these subVIs are dependent on one DLL, and the other half are dependent on the other DLL. Those that use the first DLL work prefectly well, and there is no issue with them. But those that use the second DLL have some sort of bug : every time I open one of these subVIs, I get a popup window that says:

Error loading "absolute path\name.dll". A DLL Library initialization routine has failed.

The subVI is then not executable, and the run button is displayed as cracked. But there is a twist. If I right-click on the "configure library function node" and select Configure, then reselect the exact same dll absolute path in the appropriate field, then click OK, the subVI runs perfectly well and does exactly what it is supposed to do. I don't actually change anything in the node configuration window, I merely reselect the same path. Even stranger is the fact that this weird "trick" only works about 75% of the time. The other 25% of the time, I need to actually close the VI and any other VIs that reference it, then reopen it.

And then there is another twist that makes even less sense to me: the company also sent me a couple "example VIs" that show how the different subVIs should be used in relation to each other. These examples run perfectly well! But then I wrote my own VI that is a simpler version of the "example VI", and I keep getting the DLL load error.

What am I doing wrong, and how do I make sure that the VI is executable without having to reconfigure the Library function node every time ? What do you think is causing the problem ?

N.B: Part of the problem is that I don't really understand how reading a DLL works in labview, so any information on that would also be greatly appreciated.

1
dlllabview
LabVIEW DLL handling is quite simple, it loads DLL and list functions. DLL loading (at VI open) often fail because of unsatisfied dependencies, or DLL init failure. Do you have access to the DLL's source code? Does it open correctly in Dependency Walker? - CharlesB
I don't have access to the DLL source code, unfortunately, but I have downloaded dependency walker. The DLL seems to open perfectly well, although I don't really know what dependency wlaker would say if it didn't. Interestingly, I moved my own VI in the same directory as the example VI and I noticed this : if I open the example VI AND THEN my own VI, then the DLL Load error is not thrown and the subVIs are all executable in both the example VI and my own. But if I open my own VI AND THEN the example VI, both throw the error. Does this mean anything ? - Art
Do you save the VI after you 'reset' the path? LabVIEW stores paths either relative or absolute, it might be that that get mixed up. When you open the VI (broken), and don't fix it, you can check the path in the LabVIEW project dependencies list. Also make sure in the 'path' section of the project (ctrl-e in the project window) the DLL is listed in the right location. It could be that some dependency tries to load the DLL from another location before your VI tries to load them. - Ton Plomp
Sounds like the name is getting mangled and the writer of the DLL didn't use extern "C" when using __declspec(dllexport). Does the name have a lot of @ and other misc stuff? - Austin
No the name doesn't seem to have weird misc stuff in it. I found a temporary solution by simply making a copy of the VI given to me by the company and editing it by removing the subVIs I needed and adding some wrapper code to make it do exactly what I want. I'd still like to know where that error came from though... - Art

1 Answers

0
votes

When you call a function (within a dll) in labview the .dll has to be in a location here it is readily accessible in the linked to the location (or I believe in the same location as the VI/executable).

For example if I write a subVI that say calls stdout to write to the command prompt it will call a windows dll. This dll should be in the same place in every since windows computer since a lot of windows program need it for their day to day use so it will always be locaed.

c:\windows\system32\stdout.dll //note this is and example

Now when you used your new flowmeter VI's it was expecting the dynamic link libraries to be located where ever they were on the orginal author (or at least last editors) machine. If they are not there, LabView freaks out.

You can relink, and remake the VI's the hard way. Sorry but its likely the easiest way to remake them.