VI's vs SubVI's

[packstove]

Other Than a neater looking flow code. Is there an advantage to creating and using subvi's rather than wiring your entire code into one VI. I mean, is there some speed advantage? or is it just easier to trace?

[Ton Plomp]

Is there an advantage to creating and using subvi's rather than wiring your entire code into one VI.

Hi Packstove,

their is no speed advantage, calling a subvi will cause some overhead (6 usec if I recall) However it will give you the option to do something programmers like:

more with less work!

You can use the same code over and over again. And problems are easier to track (if done right).

Ton

[Mike Ashe]

- code reuse

- easier to read non-trivial size projects

- looking like at least a journey(wo)man programmer instead of an amateur

thats enough for now, there are other reasons, but those are sufficent

[mross]

Other Than a neater looking flow code. Is there an advantage to creating and using subvi's rather than wiring your entire code into one VI. I mean, is there some speed advantage? or is it just easier to trace?

You mentioned neater looking, that is certainly very good.

Easy code re-use was mentioned. Each subvi is a standalone program. If you think ahead, many times you can make a specific sub vi genreally applicable.

Code testing is easier becasue you can test the subvis without all the surrounding code. Simnilarly debugging a large application is easier when you know exactly what small protion of the vi is hanging. You can have the front panel of a subvi active and watch it as the higher level program runs. When you learn to build in error clusters that pass through subvis you have a vary clean and useful way to sequence "code snippets" and to pick up erruntime errors for later review. And so on. The advantages at this level are unlimited.

If you are smart in naming subvis, and creating icons, descriptions and tip strips you get some very handy documentation.

Context help pops up for all sub vis showing the in and outputs their type and representation. This can be enhanced with descriptive text.

Sub vis can save data for reuse during runtime and can be shared among running vis, like a global with processing capability, there are other permutaions of this use. See functional globals or "LV2 style gobals."

Maybe best of all is very easy, very independent (of the spawning vi), parallel processing. Imagine you want to write a lot of data to a slow output line. You may not want your program to wait for that. So you have a sub vi that writes serially to a port. The top level vi calls the serial writer by passing it a dataset. The top level vi and the serial writer go on about their business with out interfering with each other. All you had to do to make that happen was wire the data to the subvi. When the subvi completes it can pass data back to the top level or not. The sub vi can generate error dialoges, warning dialoges, display graphs or other user interfaces.

For example I have a test executive that is mostly machine controls and test selectors. When I run the tests I often want to see the results graphed, but I don't want to take up space on the front panel with a graph that does not need constant monitoring. So I have a sub vi containing the graph on the FP and maybe some processing on the BD (block diagram). Right clicking on the sub vi onthe top level BD reveals the "sub vi node setup" and one option is to show the FP when running. I can make the FP pop up for a finite duration or I can make it wait for a button press to stop. If the sub vi was not visible when called then it goes away when it is completes or when I tell it to stop. So it is not only the BD that is simplified but also the UI.

Once you get uesd to this it will be like clouds parting after a monsoon.

Mike

[packstove]

Thanks for the info

[Mads]

The reasons to use sub-VIs have already been covered, however there is a downside to using sub-VIs that should be mentioned.

If the code is going to be called thousands of times the overhead in calling a subVI will slow down the execution dramatically so sometimes it is just not a good idea.

It would still be much better if you could organize the code in a subVI in the programming development and then flatten the code during compiling, that way you could get neat looking code, reuse etc, but without the speed penalty. I suggested a "flatten when compiled" feature to NI a couple of years ago (could be a subVI option, right click on it and set it to flatten...), however I have not seen any hint of it being implemented.

Mads

[Mellroth]

I don't know if anyone mentioned it, but you can save memory by using subVI's, assuming that the subVI is used more than once in your system.

With a decreased memory footprint, you will also notice that the load time of large applications decreases.

/J

[Yair]

I suggested a "flatten when compiled" feature to NI a couple of years ago (could be a subVI option, right click on it and set it to flatten...), however I have not seen any hint of it being implemented.

How about this? Not a right click option yet, but it has been a scripting method since at least 7.0. Unfortunately, Bsvingen only found out after going through all this.

[Mads]

That's great, thanks!

Why do they hide all the useful stuff....Scripting is great but not released. Inlining is there but why cannot they make it available as a VI option:-(

Mads

How about this? Not a right click option yet, but it has been a scripting method since at least 7.0. Unfortunately, Bsvingen only found out after going through all this.

[bsvingen]

Here is a tool I made with the inline script method.