LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

DLL build by Labview App Builder doesn't work if Built-IN functions used!?

Hi All,

I hope somebody shed some light on this;

(All VIs are in the attached case1-2.zip)

Case 1:
A VI reads a 1D array data and Uses RMS.vi to calc the rms of the data and returns the rms value and the error value. (make1_dll.vi).
This VI is used to build a DLL. (test1.dll using the test1.bld)
Call this DLL in a new VI (just to test that the DLL works) (test1.vi)
RUN the new VI >>> Result Nothing happens No Error or Crash and No result!!!

Case2 :
Build the above without using the “RMS.vi” and works OK. (see case2 VIs)

Any idea why the build-in function doesn’t work?


Best regards
0 Kudos
Message 1 of 6
(3,294 Views)
You might want to look at the path building you are doing to find the RMS VI. If you are using relative paths, then LabVIEW calls like "VI Path" will have an extra path if the VI is an exe or inside an LLB.

Drop some probes (indicators, outputs, etc.), rebuild and double check the paths. I've been burned by this before...

If this is the case, you can use the VI properties, or path parsing to solve it.

joel
0 Kudos
Message 2 of 6
(3,276 Views)


@Joel A wrote:
You might want to look at the path building you are doing to find the RMS VI. If you are using relative paths, then LabVIEW calls like "VI Path" will have an extra path if the VI is an exe or inside an LLB.

Drop some probes (indicators, outputs, etc.), rebuild and double check the paths. I've been burned by this before...

If this is the case, you can use the VI properties, or path parsing to solve it.

joel




I don't think that is the problem. The RMS.vi is referenced as statically linked VI in the make1_dll.vi.
As such it should be linked into the LabVIEW DLL as well. What I suspect is the problem is the fact that
the RMS.vi uses the lvanlys.dll and that for some reason there is something going wrong with the LabVIEW
test1.dll, which runs in the LabVIEW runtime context, calling lvanlys.dll while executed in the context
of LabVIEW itself. Probably something to do with the changes to how lvanlys.dll is treated between LV 7.0
and 7.1.

I see this same behaviour on my system too, so an installation problem is quite unlikely. Other than that calling a LabVIEW dll from within LabVIEW makes not that much sense (but did work fine in the past save from some hassles in 6.0 and 6.0.1), I have no explanation why this doesn't work.

Rolf Kalbermatter
Rolf Kalbermatter
My Blog
0 Kudos
Message 3 of 6
(3,266 Views)
hi there

if you pass some constant non-zero values to the indicators of make1_dll.vi and rebuild the dll it won't work until you remove the RMS.vi!! i played around with reentrant/non-reentrant VIs and Dll calls, but nothing worked. Looks quite wicked for me!

best regards
chris
Best regards
chris

CL(A)Dly bending G-Force with LabVIEW

famous last words: "oh my god, it is full of stars!"
0 Kudos
Message 4 of 6
(3,258 Views)
Thanks for all the replies;

I have played with it a bit more here are the conclusion(s) and solution(s)!!?;

It is not only the RMS.vi but any other of the analysis functions/VIs which are calling/using the “lvanlys.dll” are behaving in the same way (I haven’t tried any other functions/VIs) my application only needs the analysis functions/VIs.

Walk around;
After the build finished, copying the “lvanlys.dll” to the some directory where my own DLL is, solves the problem and the final vi (test1.vi - in my example) runs OK.

If you try to copy the “lvanlys.dll” automatically during the build from the C:\Program Files\National Instruments\LabVIEW 7.1\resource\lvanlys.dll as an added support file the build fails.

Also, after a run when I close the final vi (test1.vi - in my example) it tries to save the RMS.vi (or any other functions/VIs which has loaded the “lvanlys.dll” from it’s new location).

So it seems like the LabVIEW fails to link the dll location properly (although within the LV library functions/VIs the “lvanlys.dll”s path is absolute: C:\Program Files\National Instruments\LabVIEW 7.1\resource\lvanlys.*).

Is this a bug or dll’s build with LabVIEW aren’t meant to be used within LabVIEW development environment?

Best Regards
LV_0
0 Kudos
Message 5 of 6
(3,254 Views)
Hello!It looks like that all the sub-dll need to copy to the directory that is the same as the main program beacause i use a genarated sound program to do same thing. i need copy the dll "lvsound.dll" also so as to the program can work well.
0 Kudos
Message 6 of 6
(3,036 Views)