What do you call the not-top-level VIs?

[Aristos Queue]

I'm looking at a spec for a future feature in LabVIEW today. The spec talks about top-level VIs and not-top-level VIs. The top-level VIs are the ones that are the top of your application or that are kicked off and run independently (through Asynch Call By Ref or the Run VI method). The not-top-level VIs are all the other VIs.

 

Does anyone have a term better than "not-top-level VIs"? I'd like to call them "subVIs", but people both inside and outside NI abuse that term all the time to refer to all VIs since any given VI could become a subVI at any time. Using "subVIs" for a specific subset of VIs apparently creates confusion -- trying to do that appears to be what lead this spec document that I'm reading to use "not-top-level VIs".

 

Does anyone have a good term expressly for "not-top-level VIs"? Or should I just tell people "use the term 'subVI' and we'll educate the confused."?

[ak_nz]

I'm looking at a spec for a future feature in LabVIEW today. The spec talks about top-level VIs and not-top-level VIs. The top-level VIs are the ones that are the top of your application or that are kicked off and run independently (through Asynch Call By Ref or the Run VI method). The not-top-level VIs are all the other VIs.

 

Does anyone have a term better than "not-top-level VIs"? I'd like to call them "subVIs", but people both inside and outside NI abuse that term all the time to refer to all VIs since any given VI could become a subVI at any time. Using "subVIs" for a specific subset of VIs apparently creates confusion -- trying to do that appears to be what lead this spec document that I'm reading to use "not-top-level VIs".

 

Does anyone have a good term expressly for "not-top-level VIs"? Or should I just tell people "use the term 'subVI' and we'll educate the confused."?

 

Personally I have no problem with the term subVI. In our business we understand that the term refers to a caller-callee relationship - often we say "PleaseDoThis.vi calls DoThis.vi as a subVI" to indicate that more clearly.

[ShaunR]

SubVI is the term since the "Top Level VI" is descriptive of a pyramidal hierarchy and the expectation is for all other VIs to be SubVIs of this. Historically Top Level VI has been the equivalent of "Main" in other languages and is a monolithic application viewpoint.
 
If we view this as a tree, it seems clearer where you question arises from. Classical labview hierarchy terminology basically defines the hierarchy tree as being:
 
Root = Top Level VI (Singular)
Node = Sub VIs.
 
and you are saying "but yes, we also have these other sub VIs that are more cohesive than other sub VIs so lets have"
 
Root = Top Level VI (Singular)
Leaf = Non-Top-Level
Node = Sub VIs.
 
In this case, I suppose you could call them "Leaf VIs" or "Subordinate" VIs or lemons but it isn't really clear what they are or how they differ from Root and Node.
 
However I don't consider a "Top Level Vi" to really be the top level of the application. Rather, the Top Level of a module, process and/or grouping and I tend to talk in terms of a hierarchy tree where
 
Root = Root VI,
Leaf = Top Level VIs (not singular)
Node = Sub VIs.
 
Here, the Root is just an entry point so can be a Top Level VI, a dynamic launcher or the IDE and there is no need for a notional distinction between sub VIs and non-top-level VIs since it is already understood that a top level VI is the pinnacle of a hierarchy of sub VIs, but Root VI is the pinnacle of the application.
 

 
My though process Edited September 4, 2014 by ShaunR

[crossrulz]

The term "subVI" just screams that it is called by something.  Would you rather call it "subroutine VI" (subVI for short )?  I've never heard of there being a confusion with this term.  I say educate those who are confused because by making up another term, you are going to just confuse the large majority who understand "subVI".

[Sparkette]

I don't see what's wrong with the term "subVI". Yeah, any VI can be used in another VI as a subVI, but once that happens, it's no longer a top-level VI, so the term will apply.

[chris754]

I understand what you are saying. We have a program that loads a bunch of modules that can be independent in-and-of themselves. Each module has a top-level vi that becomes a "sub vi" when called through the larger program. Why not sub-top level vi? I think that is relatively clear in purpose. It says that this VI can be run independently, but also is part of a larger hierarchy in which it is not the main. It is a dominant branch in a root system.

 

Or another idea would be to relate it to management.  You have your top-level (CEO if you will), then manager VI or supervisor VIs, then your subvis.

Edited September 5, 2014 by chris754

[mje]

I think the confusion is that in this context you're not trying to describe a property of the VI itself, but rather its role in the execution system or position in the call stack/tree. When the VI returns does the execution system hand off to the next item up or does it clean up everything because it was the top?

 

Top level VI vs (call) stack VI? Can't say I like that name any better.

 

I'm skeptical a new name is needed provided the document properly explains the context of what "subVI" is referring to.

[chris754]

I see what you are saying mje, but what of call and forget vis? You can have a situations where the Main VI has stopped and closed, but the secondary top level vi continues to run undeterred. Do we now call this the top level vi? or is it still a sub vi?

[Phillip Brooks]

I feel a sourcender discussion brewing... 

 

http://lavag.org/topic/8689-need-lv-users-to-help-change-english-language-and-possibly-other/

Edited September 5, 2014 by Phillip Brooks

[smenjoulet]

My opinion: VIs should be called VIs when not in the context of an application or hierarchy.  I think that referring to VIs in general as subVIs is incorrect and would argue for re-education of the confused.  Maybe it's nitpicky, but it bothers me when someone asks me if I have a subVI to do such and such.  If I catch myself (because I admit it's easy to let it slide), I'll respond "No, but I've got a VI that does that and you can use it as a subVI."

 

To me subVI still makes the most sense in that context.  The only alternative that comes to mind is "called VI", but I suppose that could cause confusion with call and forget scenario discussed by mje and chris754.

 

If you start trying to apply different names to different scenarios, i think you'll end up confusing more people in the end.

[smithd]

I think most people would disagree with me, but I think of it like this... it feels to me as though a VI is only something where the UI is intended to be used (even if just as a dialog or debug screen). Anything else, which is intended to always be called by something else with a UI is a subVI, function, or subroutine.

 

 

Maybe it's nitpicky, but it bothers me when someone asks me if I have a subVI to do such and such.

I think I personally would just call it "a function to do blah". I mean, technically I don't care if its written in LabVIEW, just that it does what I want it to do

 

This becomes tricky with RT, where the top level VI should the the only function in your entire codebase which *doesn't* have anything on the front panel, but...its still the thing you go to in order to run the system, so thats still the "UI".

[JKSH]

My opinion: VIs should be called VIs when not in the context of an application or hierarchy.  I think that referring to VIs in general as subVIs is incorrect and would argue for re-education of the confused.

+1. Calling something "sub" when it's not sub-anything feels silly to me. On the other hand, reeducation sounds like an uphill battle.

 

For an alternative: How does "Child VI" sound?

 

 

I think most people would disagree with me, but I think of it like this... it feels to me as though a VI is only something where the UI is intended to be used (even if just as a dialog or debug screen). Anything else, which is intended to always be called by something else with a UI is a subVI, function, or subroutine.

This makes sense too, actually -- VIs are "Virtual Instruments" after all, and were originally designed to be software versions of hardware instruments.

 

 

The root cause of AQ's problem is that people don't think about the meaning of the name "subVI". But on a related note, the name "VI" itself is extremely overloaded. VIs started off as Virtual Instruments, but have since expanded to become all kinds of things. SubVIs, Polymorphic VIs, Global VIs, Control VIs, XControl Method VIs have very little to do with instruments. So now we have a construct whose name is "Virtual Instrument" but whose meaning is "One of several forms of LabVIEW code"

[GregSands]

Keep It Simple.  If it has a block diagram (or at least compiled code), it's a VI.

 

If a VI is run at the top level, it's a top-level-VI.

 

If a VI is called by another VI, it's a sub-VI.

 

If a VI has a front panel that is presented to the user, it's a UI-VI.   Or an interactive-VI.  Or a user-VI.

 

But they're all VIs, the other names just give hints as to how the VI is used.

[ShaunR]

Keep It Simple.  If it has a block diagram (or at least compiled code), it's a VI.

 

If a VI is run at the top level, it's a top-level-VI.

 

If a VI is called by another VI, it's a sub-VI.

 

If a VI has a front panel that is presented to the user, it's a UI-VI.   Or an interactive-VI.  Or a user-VI.

 

But they're all VIs, the other names just give hints as to how the VI is used.

 

Not quite since you can only build one "Top Level Vi" according to the Application Builder (so it's not a "hint") and "sub VI" has a definite dependency hierarchy (only appears in the hierarchy window if tied by the diagram) - pedantry prevails!

 

1. All VIs have front panels and diagrams at design time.

2. What does "Top Level" mean? (top level of application? top level of a hierarchy of other VIs? Top level of a notional design partition?)

3. If one VI calls another VI dynamically then exits, is that called VI a sub vi of the caller that has now exited?

 

Currently, the only unambiguous parlance is that if a VI has another VI on it's diagram, then the VI on the diagram is a sub vi of the VIs diagram.

I'm suggesting that if you define "Top Level VI" as being the pinnacle of a stack of VIs tied by its diagram, then everything fits nicely and you don't need all the other nomenclature. You just need to rename what the application builder calls the application entry point (which is currently Top Level VI) and that removes all ambiguity and AQ can name his "Not-Top-Level-Vi" as a "Top Level Vi".

 

That IS simple and can be explained with the VI hierarchy window to the confused.

Edited September 8, 2014 by ShaunR

[Rolf Kalbermatter]

My logical understanding of these terms is quite specific. Top Level VIs are VIs that run as the top of a VI hierarchy. They can be the main VI that starts a LabVIEW application but just as much VIs that get loaded through VI server and run as independent "deamons" in parallel with the rest of the LabVIEW application. They don't have direct links to the rest of the application other than through classical inter-application communication (IAC) means like pipes, TCP/IP, or files and quite occasionally Intelligent Global Variables, which don't classify as inter-application communication since they only work within the same process, but the principle is very much like IAC.

 

In fact the main VI in most of my applications (the one assigned in the Application Builder as startup VI is only a loader with splash screen that then loads the actual main VI as another top level VI and runs it, after which the loader terminates itself cleanly.

 

SubVIs are anything else when called by a VI, either implicitly by being part of the diagram or explicitly through the use of Call By Reference. They can show their front panel if they implement some form of dialog or other form of user interface but usually don't do so. The new Asynchronous Call by Reference "can" sort of create something in between but in most cases is more used like a Call by Reference with simply a delayed synchronization for the termination of the subVI.

[drjdpowell]

“sub-level†VIs?

 

You’re going to have confusion regards, as “top level†can refer to more than one dependance hierarchy.  Something started by an ACBR node is “top level†in one sense but not in another.