Creating development distro with dynamic vis

[bfarley]

I would like to be able to create a new development distribution and include any vi files that are called dynamically. There is an option called "include external subroutines" when you are doing a save with options, but I don't know what this does or if will help.

TIA,
Bill F

[altenbach]

Many times, LabVIEW cannot know what VI you're going to call dynamically (e.g. if the user can select it from a file dialog at runtime).

Just check the resulting llb to see what's missing. Then you can manually save your missing dynamic VIs into the same llb.
Unless there are memory concerns, I often place dynamic VIs inside a (always false) case structure of the toplevel VI. This ensures they are carried along with the distribution. (See e.g. the upper right case structire in my example code in this thread. Good luck.

[C. Allen Weekley]

Bill,

I believe the "include external subroutines" is referring to things like CINs. You need to copy or save each of your dynamic VIs into the same directory as your distribution. If you were using the Application Builder to make an executable, there is a button to "Add Dynamic VI," but to distribute VIs with source code you need to place the dynamic VIs into the proper directories yourself. A good practice when one is developing is to make a "Catalog" or "Tree" VI that has the most significant VIs of your application on its block diagram, especially dynamically called VIs, so you have an easy way to find them. Also if you do a "Save with Options" of the catalog VI you can place it in a new directory and it will include all your dynamic VIs.

[bfarley]

Thanks,
The problem is I have a lot of files that would need to be copied each time. I did try your suggestion in the past about carrying the vis in an always-false case structure - but that caused some of the vis not to run properly when called (LV would hang when I called the vi). Is there something specific I can do to make that work?

Bill F

[JeanPierre]

Instead of putting the VIs in a non-executing case, add a Static VI Reference (application control palette) for every dynamic and top level VIs of your application in a dummy VI. When saving this VI for distribution, the whole hierachy is saved.

[Jeremy Braden]

I have the skinny.

Long ago before dlls, the only way to use external code was a CIN. When you build C code for a CIN and insert the lsb file into a VI, the VI remains self contained. The problem at the time was that there was no way have common code sharable between CINs. Think of this as a rudimentary dll. The solution was to create an external subroutine and add a function in CINTOOLs that allow a CIN to call a file outside of a VI. This way several CINs could use the same common code.

It is my understanding that NI is moving CINs to the distant background features of LabVIEW in favor of dlls. This process has already started. According to "Using External Code in LabVIEW" LabVIEW 7.1 does not support the creation of exteral subroutines. See
page 3-1.

I suspect the checkbox still exists to support saving VIs having CINs with subroutines from a previous version of LabVIEW that managed to load. (I have seen VIs with CINs work after an upgrade once in a great while.--I do not know why)

[rolfk]

Jeremy Braden wrote:

> I suspect the checkbox still exists to support saving VIs having CINs
> with subroutines from a previous version of LabVIEW that managed to
> load. (I have seen VIs with CINs work after an upgrade once in a
> great while.--I do not know why)

There shouldn't be to many problems with upgrading VIs with CINs created
in older LabVIEW versions. I have done that many times with 4.0 VI/CINs
running with no problem in LabVIEW 6.1. There have been some changes in
the way CINs are interfaced in LabVIEW between versions but newer
LabVIEWs are usually able to cope with older CINs and take care of
necessary conversions such as the Boolean format change between LabVIEW
4 and 5. Usually you should be able to work with CINs as far back as
wha
t LabVIEW can convert VIs to directly.
Of course if you did use undocumented LabVIEW features in a CIN this
might be not true anymore and converting a LabVIEW 2.5 CIN to 5.0 with
the conversion package to be used in LabVIEW 7.1 will most probably
fail as the conversion package can't modify the CIN itself and LabVIEW
7.0 might not be able to deal with the 2.5 code resource.

Rolf Kalbermatter