Adding terminal to deeply nested subVI

[jjurbanus]

I first must say I think it's awesome there is a fluorishing community here of like (graphically) minded people, and really appreciate how you guys answer questions. I'm Labview self taught...and am making a massive program (for an interesting toy invention), and started using subVIs, which are great. However say you have a deeply nested subVI (like 7nth down the VI hiarchy), and you add an additional terminal to it. Is the only way to have that connector/terminal show up in the top/main VI is to manually add a terminal to all 5 other subVIs between the main and the 7nth?

Thanks for any insight

[orko]

QUOTE (jjurbanus @ Dec 2 2008, 08:01 PM)

Is the only way to have that connector/terminal show up in the top/main VI is to manually add a terminal to all 5 other subVIs between the main and the 7nth?

The quick answer is: yes. Data has to be wired somehow to the new terminal, so in your example you would be adding new control terminals to the calling VIs of the lower level subVI and wiring it all together.

Now, what you may want to consider is how you are organizing the subVIs in your hierarchy.

If you look at the project as a whole, there is probably a way to design it a little bit better an get rid of some levels. Creating a subVI for the sake of creating a subVI will get you into this "deeply nested" scenario in a hurry. And if you are putting too much functionality into your subVIs, you will find the nest (hierarchy) will get pretty "tangled" and interwoven. Functionality starts becoming inter-dependant this way which leads to bad juju.

The two questions I like to ask myself are, "Does this subVI serve a defined purpose?" and "Will I be using this subVI anywhere else?". If either of the answers is "no", then it may be time to lay the design on the table again and rethink how things are organized.

Just my 2c. Hope this helps.

[dannyt]

Hi,

I agree with Orko's comments but just though I'd throw in a few suggestions for the heck of it. Things you could possibly do......

1) OK I am getting ready for the flack here ..... use a global variable ...... though there are very good reason to limit use of global variables, that does not mean that cannot be used in some situations.

2) You could use a Function Global Variable type of set-up, your VI low down in the hierarchy can set your functional variable and you main VI could read it and update its display from it.

3) You could create a reference to the indicator on your Main.vi you wish to be updated and pass that reference down to the subVI and let you subVI update the indicator using the properties values of that reference. This sort of matches your suggestion of wiring the output terminal up but may have other uses.

4) You could obtain a reference to your Main.VI in your subVI (either dynamically or by passing it down similar to above) and from that reference find a list of indicator and controls on the main VI and then update the particular indicator you want.

gosh there a so many ways to skin this cat.

hope it provides something to think about.

Dannyt

[LAVA 1.0 Content]

QUOTE (dannyt @ Dec 3 2008, 03:57 AM)

...

2) You could use a Function Global Variable type of set-up, your VI low down in the hierarchy can set your functional variable and you main VI could read it and update its display from it.

...

The FGV (Action Engine) is an approach that I have used in apps with GUI so complicated they need seven layers to support them.

If you manage all of the GUI properties in properly, it gives you a single access point to the GUI look and feel. It also allows "screen stacks' to be amintained such that "Back" and "Forward" functionality if required.

Ben

[Francois Normandin]

5) Combine an existing control with the one you wish into a cluster. (if it makes sense)

This way, you don't change the layout of your conpanes.

The best way to achieve that is through Strict TypeDefs, if you happen to have one already.

As previously said, so many ways to skin a cat... but if you don't need to: They're so cute after all!

[jjurbanus]

Thanks for the suggestions guys, I'll consider/look into them all (#5 looks very interesting). I happened to look at your resume orko, really interesting (especially the part with projects having 400+ VIs!).

Jesse

[orko]

QUOTE (jjurbanus @ Dec 3 2008, 03:50 PM)

I happened to look at your resume orko, really interesting (especially the part with projects having 400+ VIs!).

Thanks, although it is not uncommon in large applications to have a lot more than that. That number should really be upped to 800+, which I'm sure can be topped by many posters here

[xilverbolt]

I'm a n00b.

Let's say you create a SubVI and then want to add another output to it... how does one do this? I've made the SubVI Expandable and clicked Insert Input/Output but that only lists an input or output that I already have wired up. Thanks.

[ned]

QUOTE (xilverbolt @ Dec 8 2008, 05:27 PM)

I'm a n00b.

Let's say you create a SubVI and then want to add another output to it... how does one do this? I've made the SubVI Expandable and clicked Insert Input/Output but that only lists an input or output that I already have wired up. Thanks.

We know you're a n00b if you use the phrase "Expandable" in reference to a subvi...

(I might be wrong - does anyone actually use that style of subVI, or are we all too set in our ways from before that was even an option?)

Right click on the icon in the upper right corner of your front panel, choose "Show Connector". Click on any empty (white) terminal, then click on the front panel item to which you'd like to link it. If there are no free terminals, you can add one by right-clicking and choosing Add Terminal.

[xilverbolt]

QUOTE (ned @ Dec 8 2008, 10:56 PM)

We know you're a n00b if you use the phrase "Expandable" in reference to a subvi...

(I might be wrong - does anyone actually use that style of subVI, or are we all too set in our ways from before that was even an option?)

Right click on the icon in the upper right corner of your front panel, choose "Show Connector". Click on any empty (white) terminal, then click on the front panel item to which you'd like to link it. If there are no free terminals, you can add one by right-clicking and choosing Add Terminal.

That is NOT intuitive! But it worked! Thanks.

[asbo]

You could also use the Patterns sub-menu to have a little more freedom in how your terminals are distributed.

[BrokenArrow]

I like orko's two questions ....

QUOTE (orko @ Dec 3 2008, 02:22 AM)

The two questions I like to ask myself are, "Does this subVI serve a defined purpose?" and "Will I be using this subVI anywhere else?". If either of the answers is "no", then it may be time to lay the design on the table again and rethink how things are organized.

but the first can almost always be answered "yes". Such as: "The sub-vi saves space on the wiring diagram", or, "the sub-vi makes the code more modular". I don't think these are necessarily bad reasons to make a sub-vi. A good example of the proper use of a one-off sub-vi would be in the "organization" of multiple Property Nodes for GUI manipulation (wiring in references). Other examples which I use a lot would be in large string concatenations, multiple Select or min/max functions, obtain multiple notifiers, etc. Admittedly, these are "space savers" and not true modular coding techniques (and not true encapsulation), but a one-screen wiring diagram is important to me.

[orko]

QUOTE (BrokenArrow @ Dec 10 2008, 11:20 AM)

"Does this subVI serve a defined purpose?"

...the first can almost always be answered "yes". Such as: "The sub-vi saves space on the wiring diagram", or, "the sub-vi makes the code more modular"

Saving space on the block diagram is a defined purpose in my eyes. Whether or not it is worth it for a one-shot subVI is up to the designer. A lot of times I find that I really just needed to split a state machine up into more states...rather than have a bunch of sequential code in one loosely defined task.

Making the code more modular seems to me to be a function of the design itself, not a result of turning a block of code into a subVI. It pays to think the design hierarchy through before the code is even written, which tends to flesh out the need for "modules".

Then again, I've probably just drank too much of the OOP grape drink and am thinking that way inherently now...

[BrokenArrow]

QUOTE (orko @ Dec 10 2008, 03:26 PM)

Saving space on the block diagram is a defined purpose in my eyes.

Indeed. My point, which I didn't make very well, was that this does not allow us to answer "yes" to your question 2: "will I use this sub-vi again". I guess the thin line is, if I answer yes to that question, it goes into my library and gets a more generic name. If I answer no, the sub-vi just become part of the current project scenery.

QUOTE (orko @ Dec 10 2008, 03:26 PM)

A lot of times I find that I really just needed to split a state machine up into more states...

And THAT is the way you keep yourself from nesting too deeply (that point is being made for our hopefully-not-a-one-hit-wonder original poster). If I'm three VI's deep, it's time to rethink the design. Actually two.

QUOTE (orko @ Dec 10 2008, 03:26 PM)

Then again, I've probably just drank too much of the OOP grape drink...

Jonestown Estates gives http://www.softpanorama.org/SE/anti_oo.shtml' rel='nofollow' target="_blank">30% discounts for OOP users.

[Aristos Queue]

QUOTE (orko @ Dec 10 2008, 02:26 PM)

Then again, I've probably just drank too much of the OOP grape drink and am thinking that way inherently now...

No such thing as "too much" if you're serious about building large scale software. Keep drinking... there's more coming...

[orko]

QUOTE (Aristos Queue @ Dec 11 2008, 12:36 AM)

No such thing as "too much" if you're serious about building large scale software. Keep drinking... there's more coming...

Cheers!

http://lavag.org/old_files/monthly_12_2008/post-3266-1229011880.gif' target="_blank">

[Francois Normandin]

QUOTE (Aristos Queue @ Dec 11 2008, 03:36 AM)

Keep drinking... there's more coming...

<HailMary>

Care to tell us when????

<\HailMary>

Doesn't hurt to try...