dynamic call a sub vi from vi.lib in exe program

[chinawang_78]

hello all,

i try to dynamic call a sub vi which include a function vi from VI.lib (emaple MEAN.vi)  in a exe main program, it is can run on edit mode, but once I build main program to exe file, the sub vi can not run.

can somebody try it?

[natasftw]

Did you add that vi to the "always included" section of the source files in the exe setup?

[chinawang_78]

for this sample; the solution is add MEAN.vi to main program then build to exe, it is can run.

the problem is: if I create a new Sub vi with a function vi from vi.lib,  I have to add those function vi to main vi  and build it again, 

is there some solution else?

[Dennis_Knutson]

You were just given the answer. Do you understand what it means to select 'always include'?

[Bob_Schor]

The problem is in MainCall, where you try to obtain the reference to your Add sub-VI.  You are wiring in an explicit Path, which is the path to the VI in Development mode.  However, when you then build it as an executable, the path changes in a subtle way that I never try to remember.

Instead, I use Static VI References to get my VI References.  I'm attaching a Snippet in LabVIEW 2015 (which is, I think, the "wrong" version of LabVIEW for you, but you should be able to duplicate this yourself fairly easily) showing what I did.

First, I edited your "subadd" VI to give it an Icon, so when I drop the Static VI Reference, I don't have to "guess" what it represents (there are a lot of "Self-documenting Tools" built into LabVIEW that can really improve the quality of your code).  Here are the steps you need to take:

1. Drop a Static VI Reference (from the Application Control palette) on your Block Diagram.
2. Right-click it, change it to a Strictly-typed VI Reference (since you will use it for the VI Type diagram, as well).
3. Right-click, "Browse for path", find "subadd.vi" and select it.  If you've made an Icon, it will appear (as in the Snippet).
4. Drop a Property node, wire the Reference to its input, and choose the VI Path property.
5. Wire the Path property to the VI Path input of Open VI Reference.
6. Wire the Static Reference into the Type Specifier input of Open VI Reference.

The nice thing about this formulation is that it works both for Development and for Execution modes.  It also is simpler and self-documenting (if you make Icons for your VIs).

Note that doing this ensures that "subadd" will always be included in your build, even if you only mention MainCall in the Build Specification.  Because "subadd" is in the Build, the sub-VIs that it uses, in particular the LabVIEW Mean function, will also automatically be included, and don't need to be specified.

Bob Schor

[Norbert_B]

---

@Bob_Schor wrote:
[...]

The nice thing about this formulation is that it works both for Development and for Execution modes.  It also is simpler and self-documenting (if you make Icons for your VIs).

 [...]

Bob Schor

---

It works always as it is a static reference to the subVI. As such, the app builder identifies it as dependency and add it to the exe.

It is a very good solution for most use-cases and my feeling tells me that the OP of this thread should do exactly this.

However, it is no solution if you are looking for plugin architectures.

Norbert

[chinawang_78]

thanks reply!

yes, for this simple vi, can use static reference, but if there are many subvi (steps) call by main as below, how to do?

is it have to add those function vi (from vi.lib) to main and build again? why those subvi can not call by exe program if it include a function vi from vi.lib?

[Norbert_B]

In that case, as already mentioned several times by now, use the Always Include option in the app builder!

Norbert

[ShilpaS_]

This solution works only if we have single sub VI, if we have multiple sub VIs and need to call dynamically, then what we need to do??

please reply..

---

@Bob_Schor wrote:

The problem is in MainCall, where you try to obtain the reference to your Add sub-VI.  You are wiring in an explicit Path, which is the path to the VI in Development mode.  However, when you then build it as an executable, the path changes in a subtle way that I never try to remember.

Instead, I use Static VI References to get my VI References.  I'm attaching a Snippet in LabVIEW 2015 (which is, I think, the "wrong" version of LabVIEW for you, but you should be able to duplicate this yourself fairly easily) showing what I did.

First, I edited your "subadd" VI to give it an Icon, so when I drop the Static VI Reference, I don't have to "guess" what it represents (there are a lot of "Self-documenting Tools" built into LabVIEW that can really improve the quality of your code).  Here are the steps you need to take:

1. Drop a Static VI Reference (from the Application Control palette) on your Block Diagram.
2. Right-click it, change it to a Strictly-typed VI Reference (since you will use it for the VI Type diagram, as well).
3. Right-click, "Browse for path", find "subadd.vi" and select it.  If you've made an Icon, it will appear (as in the Snippet).
4. Drop a Property node, wire the Reference to its input, and choose the VI Path property.
5. Wire the Path property to the VI Path input of Open VI Reference.
6. Wire the Static Reference into the Type Specifier input of Open VI Reference.

The nice thing about this formulation is that it works both for Development and for Execution modes.  It also is simpler and self-documenting (if you make Icons for your VIs).

Note that doing this ensures that "subadd" will always be included in your build, even if you only mention MainCall in the Build Specification.  Because "subadd" is in the Build, the sub-VIs that it uses, in particular the LabVIEW Mean function, will also automatically be included, and don't need to be specified.

Bob Schor

---

[Bob_Schor]

One drawback to using a Static VI Reference, of course, is that this forces the VI into memory (which can also be viewed as a strength since you always know "where to find it").  If you have multiple VIs, they'll all be in memory, even the ones that you aren't running.  "Dynamic loading" still requires the VI to be in memory, but if you have, say, six of them, you only need enough memory for the largest of these (assuming they are brought in, and dismissed, one at a time) instead of for all six at once.

Whether or not this is an issue for you depends on the memory requirements of your task and the available memory on your PC.  In these days of 64-bit OSs and 16GB systems, this may not be as much of an issue. 

It is easy enough to build a sub-VI that "hides the details" of starting a particular Asynchronous Call so you don't have a mess on your calling routine.

Bob Schor