Quick subVI configuration and overview from caller BD

[SteenSchmidt]

Hi.

SubVIs are sometimes easily missed in a block diagram when you glance over it, and their current configuration is impossible to determine unless you open up each subVI and examine its VI Properties. I suggest a quick way to highlight and configure subVIs within a BD. Consider this section of code:

Then one could hold down the ALT-key (or some other easily accessible interface) to get this view, which gives you an interactive highlight glyph overlay on top of each visible subVI. Letting go of the ALT-key returns your BD to normal of course:

The interactive highlight glyph gives you direct access to this for each subVI:

- It highlights where in the BD there is a subVI.

- It shows if the subVI has unsaved changes.

- It shows the runtime priority of each subVI (more on that later).

- It shows the reentrancy mode of the subVI (as well as inlined/subroutine state).

- It highlights any unwired required inputs of that subVI.

- It shows if the subVI has debugging enabled (which can have a negative impact on performance).

- It illustrates if the subVI is otherwise configured for optimum performance (more on that later).

More on the subVI highlight glyph:

I imagine tooltips might pop up containing additional info if you hover the mouse pointer over the elements in the glyph. I think clicking the "unsaved changes" asterisk should save the subVI with all the bells-and-whistles as if you opened it and did CTRL+S on it. I think clicking the "Debugging enabled?" element should toggle the Allow debugging property of the subVI directly. I think clicking on the colored frame should open the reentrancy setup dialog of the subVI. The colored icon frame is part of many LabVIEW style guides for icons btw, but not everybody is familiar with them, and thus don't use icon frame colors like this. Also such colors might clash with other style guides - class icon templates for instances, or company logo colors. That is why I propose the reentrancy setting being part of this subVI highlight glyph.

More on subVI priority:

I have earlier proposed a much simpler way of defining subVI priority with a number, which is along the lines of how it's defined in a timed structure, instead of the current way of setting Priority and Preferred Execution System in VI Properties (which many people find hard to figure out and keep mixing it with timed structures). That idea can be found here. This priority number is what I propose is located on the subVI highlight glyph. Clicking on this element in the glyph should open the subVI's Priority setup dialog directly.

More on the "optimum performance" element:

I haven't really thought deeply about this element, but I see it as an indicator of if "all the rest" about the subVI is optimized for best performance and least runtime pitfalls. Stuff like making sure Enable automatic error handling and Auto handle menus at launch are disabled. Anything outside of the optimum will light this indicator. Clicking on it should open the subVI's VI Properties dialog or similar.

What do you think?

Cheers,

Steen

[SteenSchmidt]

On second thought it should probably be something else than the ALT-key, as that is often used for menu shortcuts.

/Steen

[dthor]

An interesting Idea.

1. Highlights: I don't have an issue finding my subVIs, as I have them a nice bright yellow color. But I see your point.

2. Reentrant border color: I have a terrible memory, so I'd have to look up the color each time. Put it in the context help for the VI and I'd be OK with it. Also, I very rarely use reentrant VIs, so my opinion isn't very strong.

3. Everything else looks pretty cool. You spent a good amount of time on the graphics. They look nice, good job.

Since the effective size of the subVI node increases, the one thing I want explicity state is that this is an overlay: enabling it will not cause structures to auto-grow or items to move.

I like it being a hold-down key such as ALT. Perhaps the combination of CTRL+ALT? I don't remember what all the shortcuts are.

[SteenSchmidt]

Yes, definetely an overlay (just like a context menu) that only lives as long as you hold down the key. It's not an object on the BD, nor does it change any objects on the BD (except for any subVI settings you might modify on purpose using the feature).

About reentrant VIs: Each and every time I make a subVI I consider its reentrancy setting. Execution depends on it, and I don't think I have made any application in the last several years where I didn't have to consider carefully which components are loaded when, which are used at what points in time, when are the components blocked and when are they free etc. It may be due to execution parallelism, latency requirements, state caching, template like behavior, memory footprint, or a number of other factors. So for me a subVI's reentrancy setting is very important. But of course this is individual. As may a number of the other elements I mention be.

Cheers,

Steen

[GregSands]

I'll kudo this just for your graphics - very nicely done!

I'm not sure how well it would work though:

• speed - in order to display all that info quickly, it would have to be preloaded, which would slow down loading, and also would use extra memory
• visibility - I'm guessing you'd only see what is currently visible, which would mean that anything in other cases/events would be hidden - it would be time-consuming to go through checking each one
• duplication - if the same subVI is used several times, it will show every time

That makes me think that a different implementation might work better - what about having those graphics in the VI Hierarchy window?  Not that I currently use that very often either, but I might if it was more useful.  Alternatively, the Project window might be a better place to have it - in fact, what if the VI Hierarchy view and functionality was somehow merged into the Project window, as another way of viewing the information alongside Items and Files?   In any case, I'm not sure that seeing this info in the block diagram is necessary.

Also, the Code Complexity measure might be another one of interest to show.

[SteenSchmidt]

I actually think the best (really the only that makes sense) location of this feature is in the BD, as I'd use the information provided in the context of the surrounding code. Whether a subVI is inlined or not, and its priority, doesn't make any sense unless you consider its call site. This feature were it in the VI Hierarchy or in the project most of the info would be out of context and thus impossible to decide configuration of.

I'd probably use this feature for a quick check and correction of a certain subVI that I'm currently reviewing the surrounding code of, much more than actually for locating subVIs in the code. So it's not so big a deal that I'm not able to review all subVIs at the same time.

About the speed of loading this information... well, the subVIs are already in memory, so I'm not sure it would be that taxing to get to the proper information. And in the event you want to change some subVI propert, it wouldn't involve more resources than in the case where you open the VI Properties of that subVI manually.

Cheers,

Steen

[A-T-R]

It's a nice idea, and just like GregS said, this deserves Kudos not only for the idea itself, but for the time you invested by creating the good graphical description!

@ Steen: I'm with you! Your justifications "against" GregS's objections just get to the point!

[Norbert_B]

Steen,

really well thought out feature suggestion. Kudos for this.

BUT: I am not sure if such overlay should focus so much on performance setting in the first instance.

Here my concerns:

a) Color code: Hard to read if not done regularily (forgetting color/meanings) and not suitable for color blind users (if they do work with LV at all since we got a LOT of colors, some very similar....

b) SubVI Priority: Referring to your linked idea, i am not sure if i like it. We are talking about priority levels comparable to the ones a "standard OS" understands.

Meddling with priorities always bears the risk of unwanted effects (like priority inversion, ...) so it is not suggested to be used by newbloods. Open up priorities to multiple levels (100+) will create additional issues.

But i do concur that displaying priority settings in the call would be useful (it is already suggested to mark "subroutine" priority setting in the icon of the subVI!)

c) What is "Optimum SubVI Configuration"?

d) What means "greyed out" vs. "solid"?

What i really like:

a) The bug is cool 😉

b) The work you put into displaying your thoughts. We have a good basis to discuss on. Keep up that work!

c) The general idea

What i would change:

a) Some of the symbols, meaning...see my concerns.

b) I would not bind this to a key combination (except if it would be a toggle like Ctrl+h for context help). I would rather add an option in the BD options dialog to enable/disable this view of subvis. It should be comparable "Place front panel terminals as icons" or "View as Icon" setting for subVIs. So subVIs should have an additionl new type of view (Icon, Expandable Node, Expanded Node) like "Configuration Settings".

c) Rethink really important settings to be displayed here. Things like "automatic error handling" make sense for the debugging part, but does not refer to the fact of building an EXE later on (debugging/automatic error handling will be disabled by default!). Here what i like to see:

• Priority if changed from "normal"
• Reentrancy (maybe/maybe not including configuration)
• Debugging Enabled/Disabled (might be valuable information for the developer to evaluate differences between VI/EXE runtime behavior)

Optional additional information:

• Number of callers/instances
• Symbol for "not executable" comparable to locked XControls

just my thoughts,

Norbert

[SteenSchmidt]

Thanks Norbert, for your thorough comment. I'll try to address your points below, in order of simplest to most complex to address 😉

Optional additional information:

1) Number of callers/instances. A good idea but quite difficult to gain much meaning out of, isn't it? I mean, it's not certain that all modules using that subVI in the final application are currently in memory, and the number of resulting reentrant instances can't always be predicted. All in all an impossible number to calculate.

2) Symbol for "not executable" comparable to locked XControls. This is a great idea. Locked/broken symbol would be a nice addition.

Colors/glyph layout:

There are people much more experienced at addressing these issues than me, so I'd let it be up to the UX guys to design the look-and-feel of this feature. Both in regards of color blindness but also to make it look the proper NI/LabVIEW way.

Interface:

Personally I'm not in favor of making subVI icons permanently larger than their current size. I don't ever use the expandable subVI node look and I'm not a fan of Express VIs due to their size either. I realize I may be something of a dinosaur in this respect , but I don't think subVIs have be be any bigger in the BD. But the more I think about it, the more I agree that this interface should be easier to get at than needing to hold down a key (combo). How about making it just pop out on mouse over, and disappear again when the mouse leaves the overlay?

I suggest that subVI icons look as they do now in the BD. When you mouse over a subVI icon the overlay appear, even making it easier for you to wire the subVI because the connector pane temporarily is visible (this connector pane will illustrate which terminals are active, maybe their required/recommended/optional mode and more). As long as the overlay is visible you can activate various tip strips, for example giving the subVI location on disk and stuff like that. And you can of course click/modify the various settings within the "yellow area" that we discuss in this proposal. The "yellow area" could possibly vary in size if there are situations where the amount of information varies. Such an overlay could even be a way to configure certain native LabVIEW primitives instead of the current context menus (stuff like async/sync reads, include/exclude limits, polymorphic instance selection perhaps, etc.).

What are important/optimum settings?:

This is hard to answer. Personally I find that the current way to enable/disable debugging in LabVIEW could use an overhaul. You define in each subVI if it allows debugging, but that doesn't make any sense for reentrant VIs on Real-Time for instance. You can defeat some of these settings within the LabVIEW options as well. You can even enable automatic error handling in an executable with the LabVIEW.ini. I feel you should be able to configure debugging and error handling ('catch all errors' output window during development?) on a more global level, making the IDE/App Builder act on these global changes, but that is a completely separate topic. For now I'm open to suggestions about what makes a setting important enough to show up in this "shortcut" subVI overlay.

Grayed vs. colored generally means disabled vs enabled, but this doesn't fare equally well for all types of glyphs. It would require an entire design specification to outline this, so first: what should be available in the interface?

VI Priority:

Pitfalls like priority inversion is already taken care of at thread level in the scheduler today by priority inheritance. The problem does not get any bigger or smaller due to the way we configure subVI priority. I merely suggest a simpler and more consistent way to configure subVI priority. Timed structures use a priority number today, while they could just as well have stuck with the thread compartment model of subVIs.

So, the number of available threads in the system at any one time can be difficult to predict, thus assigning priority for a subVI on the assumption that resources (threads) are available in some quantity is making the programmer's job of prioritizing sections of parallel code hard bordering to impossible. I really like the way priorities are assigned in timed structures, as it's really simple. You get a direct interface to the number of logical CPU cores available, which is really the finest quantization that makes sense, and then you can prioritize code running on each CPU from there. Having a number of (basically virtual) execution systems that seem to coexist in parallel actually obfuscates the lesser number of resources that your code in reality battles over.

Therefore I suggest making everything that is prioritizable being so just by a priority number (no more weird IO thread(?) selection), and then let the scheduler administer the game from there (optimum number of threads, isolating a CPU for system perhaps, etc.). Then you could set a priority for an entire VI, and at certain places in the BD maybe override this with a "priority structure" if necessary. It could even be spiced up by being able to override the priority for each VI reflection in the code by using a subVI call configuration (maybe only for preallocated reentrant reflections to avoid allot of priority pro- and demotions). Simple, and much easier for people to understand. And no more risk of mixing VI execution priorities with various different timed structure priorities (which often yield highly surprising results).

The subroutine "priority" should be gone in any case as we have inlining now (almost the same, close enough I think to allow this simplification).

Cheers,

Steen

[vt92]

I think this is a great overall concept.  NI should seriously consider implementing the idea in some form or fashion.

[fabric]

Kudos for the idea of a visual indication of a sub VI's execution properties.

Personally I really like the idea of a hold-down key to trigger this view. As far as the specific information goes, this is generally going to be a matter of user taste. My taste:

• Definitely need a way to see the reentrancy settings!
• Unsaved changes indicator could be useful
• Connector pane info seems pretty useful
• (Other stuff I could live without...)

Note: I suggested a related idea to allow viewing of VI properties such as reentrancy in the project window. We *definitely* need a better way to view this kind of info in bulk!