Can I load a vi into memory programmatically

[Kahless]

Here's the situation (I'm programming in LV7.1)...

I've got a program that runs, which uses the DSC.  I'm wanting to programmatically shut down and quit the Tag Engine when the program ends.  My problem is that when I use "Engine Shutdown.vi", all vi's that use the tag engine have to shutdown before the Tag Engine will completely shut down.  If I call this an wait (monitoring engine status for shutdown), then I get a deadlock error.  If I call this and end the program, then I get a pop up asking if I want to "Stop and close Tag Engine" (and for some reason an error afterwards as well, doesn't describe error, just that a log is being created.)  My goal is to have to pop up or dialog boxes appear that the user has to interact with when shutting down.

So the solution that I believe would be appropriate for this would be to close the main program and have a separate vi (that is independant of the main program structure) call the "Engine Shutdown.vi", then quit itself, closing LV.  So I've been messing around with this...

"Open VI Reference" with the vi path connected as an input (just a simple vi I made to kill the Tag Engine, wait until it falls, then kills Labview).  This is connected to an "Invoke Node" with the 'Run VI' method selected, property 'Wait until done' set to False, and 'Auto Dispose Ref' set to True.

This works all fine on my developement machine, but I imagine I'm going to have issues when compiling this and installing it onto it's target machine.  How would I compile this?  If I add this vi to the build as a Dynamic VI will it automatically be loaded into memory when the program runs (on the target computer)?  If not, is there any way I can programmatically load this vi into memory in such a way where it is not a subvi to my program (else it will have same issues shutting down Tag Engine)?

As always I appreciate everybody's help,

Sean

[mikeporter]

First, the only problem you might have with this setup is deriving a path to the target VI that is valid for both runtime and development environments. The easiest is if the caller VI is located in the same subdirectory as the target VI in the development system.

Beyond that, Dynamic VI is what you are looking for. These VIs are built into the application with their front panels, but are not loaded into memory unless explicitly called during execution.

Mike...

[Kahless]

Mike, thx for your response.  Let me run this by you...

So if I put Main.vi and Kill Engine.vi in the same folder on my developement machine, have the attached snippet of code execute when Main.vi is ready to shut down (very last thing to run, after all loops conclude) build the app (with Kill Engine.vi as a Dynamic VI), and install the app on the target machine, does it sound by you that this will work?  (Kill Engine.vi is the simple vi I made to shutdown and quit the Tag Engine, wait for this to conclude, then exit Labview).

Thanks,

Sean

[mikeporter]

The snippet is close, but the current VI's path node returns the entire path including the VI name so the result of that code wold be something like:

c:\my development directory\main.vi\kill.vi

You need to strip the path one time to remove the file name, after which you can add the new one on. By the way the reason this works is that in a built application all the VIs reside in one library so while the path as a whole is different in a built executable (it includes the name of the executable), the relative path stays the same.

Mike...

[Kahless]

That's what I was thinking too, but the "Launch Tag Engine I.vi" example (C:\Program Files\National Instruments\LabVIEW 7.1\examples\lvdsc\_common\Tag Engine.llb) uses this method to get the path, and upon running the example with a couple probes on the lines, it did in fact work in fabricating the path.  I'm thinking being that it is a relative path that is being attached to Build Path ("..\Kill Engine.vi"), the ".." goes up one level, ie getting rid of the "Main.vi", then adds the "\Kill Engine.vi" to the path.

This does make a lot more sense to me now, specifically how the library is structured and the reasoning for this methodology.

Mike you have been most helpful.  I greatly appreciate your assistance.

--
Sean