LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Best Practices - Distributing Dynamic VI's with LV2011

Solved!
Go to solution

I'm distributing code which consists of a main program which calls existing (and future) vi's dynamically, but one at a time. The dynamically called vi's do not have input or output terminals. They run, one at a time, in a sub-panel in the main program. The main program needs to maintain a reference to the dynamically loaded vi so it can be sure the dyn. loaded vi has fully stopped before unloading calling a replacement vi. These vi's do not used Shared Variables or Globals, but may have a few vi's in common with the main program (it would be OK to duplicate these vi's in the release).

 

With that background, what are the best practices these days for releasing dynamically loaded vi's (and their dependents)?

 

If I use a Project Library (.lvlib), it would seem that I need to first build a .exe containing the top-level vi's (the one's to be dynamically loaded), so that a separate .lvlib can be generated which includes their dependencies. The contents of this .lvlib and a .lvlib containing the top-level vi's can then be merged to create a single .lvlib, and then a packed library can be generated for distribution with the main .exe.

 

This seems way too involved (but necessary?)

 

My goal is to simply have a .exe for the main program, and some other structure containing the dynamically called vi's and their dependents. This seemed so straighforward when a .exe was really a .llb a few years ago Smiley Wink

 

Thanks in advance for your feedback.

 

0 Kudos
Message 1 of 3
(2,131 Views)

A great source of information I've found since posting is here:

 

http://zone.ni.com/devzone/cda/pub/p/id/1261

 

regarding packed libraries. Bottom line - they automatically include dependencies to the top-level dynamically linked vi's placed in a .lvlib from which the .lvlibp is built..

 

I cannot seem to find an example of dynamically calling a vi within a packed library. If I use the old .exe as llb method, I get an Error 7.Call vi using Path example

...

0 Kudos
Message 2 of 3
(2,124 Views)
Solution
Accepted by topic author Wiredup

Continuing the conversation with myself Smiley Wink Here's the solution:

 

Dynamically calling a vi within a packed library

 

Works like a champ. All of the dependencies are contained within the packed library and the dynamic call is working great.

0 Kudos
Message 3 of 3
(2,122 Views)