Dynamic SubVI Questions

[theoneandonlyjim]

I'm kind of new to the use of dynamic subVIs, but I've come to recognize just how powerful they can be. I'm revising some existing code and really want to implement them.

Before I make them a part of the project, I've been working smaller examples scratch-pad style to get my head around a couple of concepts. I've been able to develop a main and sub-vi example that I've successfully built into an application.

While doing so, I've come up with a couple of questions. I'll throw them out to the 'net and see what I get back.

-For diagram clarity/readability, I intend to use subVIs within the dynamic VIs. Are these loaded/unloaded as part of the dynamic code?

-Along those lines, what happens when I build my application? Do I list the subVIs within the dynamic VIs under "Always Included"? Do I even have to include the dynamic VIs? What about source file settings? I could see that as getting complicated if my application grew past a certain point.

-Is there a good VI or other program that allows one to monitor built application memory usage (running/loaded EXEs, VIs, etc.), similar to what "Dynamically Monitor VIs" can do in the development regime? Tracking program function might answer these and other questions I might have.

I recognize that these are basic questions, but this topic has just not sunk in for me yet. Apologies also if this is the wrong forum.

[Aristos Queue]

Please define the term "dynamic VIs" ... are you talking "VIs that you load dynamically using Open VI Reference or the 'Call Setup' pop up menu option on a subVI node" or are you talking about "dynamic dispatch VIs that are members of LabVIEW classes"?

The answer to your questions will vary greatly depending upon which of these two technologies you're asking about.

[theoneandonlyjim]

Please define the term "dynamic VIs" ... are you talking "VIs that you load dynamically using Open VI Reference or the 'Call Setup' pop up menu option on a subVI node" or are you talking about "dynamic dispatch VIs that are members of LabVIEW classes"?

The answer to your questions will vary greatly depending upon which of these two technologies you're asking about.

Sorry - I meant dynamically loaded VIs using Open VI Reference. OOP is something I've yet to tackle.

[Daklu]

First, as far as I know the main use cases for using traditional "dynamic sub vis" are:

1. The application allows plug-ins that will be created after the main application is compiled. (Dynamic loading.)

2. You want to improve the application start up time. (Dynamic loading.)

3. You want to start an unknown number of identical processes. (Dynamic launching.)

If one of those three isn't your goal you might want to rethink using dynamic vis. IMO it will add unhelpful complexity to your project. (There may be other non-oop reasons for using dynamics I haven't mentioned.)

-For diagram clarity/readability, I intend to use subVIs within the dynamic VIs. Are these loaded/unloaded as part of the dynamic code?

"Regular" sub vis on a block diagram are loaded when the parent vi is loaded.

-Along those lines, what happens when I build my application? Do I list the subVIs within the dynamic VIs under "Always Included"? Do I even have to include the dynamic VIs? What about source file settings?

I'm going from memory here and haven't tested it all thoroughly, but here's my understanding:

It depends on whether you are using dynamic loading or dynamic launching. Here's an example of the difference:

The top example has a static reference to the vi that is going to be executed. Since LV "knows" which sub vi is going to be used, you don't need to specifically include it in the build and the sub vi is loaded when the application starts.

The middle example does not have a static reference to the vi that will be executed. The reference shown is for a vi that *only* defines the connector pane. (No BD code.) All plugins will need to use the same connector pane pattern. The vi located at that path (if one is there) is loaded when the Open VI Reference function executes. If you have vi's in your project you are loading using this method, you'll need to "always include" then in your build. (It kind of defeats the point of having a plugin though.)

The last example is a hybrid of the two.

I could see that as getting complicated if my application grew past a certain point.

Yep, especially if you're using dynamic loading to load vis already built into your executable. If the sub vi is going to be included in my build anyway I use a Static VI Reference and avoid all the management headaches.

[theoneandonlyjim]

Thanks for the illustration. It generated some additional questions for me. I'll admit I don't have a CS background, so please excuse any ignorance I show.

When you say "don't know the specific VI at compile time", do you mean that I have (for example) three subVIs, and based on the input used to choose my plugin, I load the correct one? Or, do you mean that I'm leaving a placeholder for a VI with this specific connector pane that I haven't written yet? If it requires inclusion in my build, how is this an advantage over standard subVIs?

If I'm not including VIs in my "always included" list for the executable build, they need to be part of the installer build so that they're placed at a location identified by the path within the caller VI, right?

I think dynamic loading/launching is what I am after. The application calls for controlling one of three pre-defined tests sharing a common set of equipment. I want to mask user input because, though there are commonalities between the three tests, not all use all the equipment. I want to load only the components needed.