LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Locate dynamically called vi

I have a labview application (6.1) that contains one dynamically called vi. When I build the application, install it on another computer and run it, the first thing it does is asks me to locate that one dynamically called vi. So I do that, I locate the file and then everything works fine after that with the program. Everytime I launch the app I have to repeat this locate cycle. I've tried everything I can think of including not removing the backpanel in the app builder to get rid of this locate the file prompt. Does anyone have any suggestions?
0 Kudos
Message 1 of 6
(3,481 Views)

Did you actually include the VI in the build? The second tab page in the builder has an option for this and this will put the VI inside the EXE, where the RTE will look automatically.

Also, do you build the path relatively to the location of the top level VI? If you do, the Executable's name gets appended as a directory and you have to do an additional strip if you're runnning in the RTE (Application>>Kind property).


___________________
Try to take over the world!
0 Kudos
Message 2 of 6
(3,478 Views)
thankyou for the reply. The path is built absolutely not relatively. Also the vi in question is included in the the build as a dynamic file. Was there a different way to do this?
0 Kudos
Message 3 of 6
(3,474 Views)

Well, part of the search algorithm for a VI includes going through the same directory (or LLB) as the top level VI, so it should have found it if you include it as a dynamic VI. Does LV says it's expecting to find it where it actually is or does it give another path (I assume not since you say it's absolute)? If so, then this sounds really wrong.

As a workaround, you could try using the OpenG builder, which has some additional functionality, but since the building part is only a wrapper for the NI AB, I don't think that will help.

Is this happening only with this VI? Does this application have other dynamic VIs which work? Can you test it on a third computer?

And last thing, just a stupid question - did you try scrapping the whole thing and starting from scratch (uninstall the RTE, create a new bld file and installer, etc.)?


___________________
Try to take over the world!
0 Kudos
Message 4 of 6
(3,471 Views)
Having a dynamically called VI in a different location during development and during deployment is a common problem.  I usually solve it as follows.  Place a statically called VI in the same directory as your dynamically called VI.  The sole purpose of the statically called VI is to return its directory.  Given the directory, you can then construct an absolute path to your dynamic VI.  I have attached an example of this statically called VI.  Just make sure it is always in the same directory/LLB that the dynamically called VI is in.

There are other ways to do this, some more elegant, but I find this one the simplest and easiest.
0 Kudos
Message 5 of 6
(3,454 Views)

hi there

are you using an <applicationname>.ini file? if so please check if there are VI search paths specified in the key "viSearchPath". if the search paths are default  (the key is not contained in the file) then it should be sufficient to supply the name of the VI as a path to the Open VI reference function (see attachment).

 

 

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 6 of 6
(3,441 Views)