Block-Diagram-Only VIs (VIs without a Front Panel)

[Petru_Tarabuta]

I would like it if LabVIEW offered the option of creating Block-Diagram-Only VIs. These VIs would be just like regular VIs, but without the Front Panel window.

BD-Only VIs would be beneficial because:

• They would remove the need to spend a few seconds tidying up the Front Panel of every VI. In a large application most VIs do not have a user-facing GUI. Most of the time tidying up the FP is "busywork" that slows down the developer. (The alternative: creating BD code without ever looking at the FP results in the FP being a mess, which is even more undesirable than wasting a few seconds to tidy the FP up.)
• They would reduce the developer workload, thus making developers faster.
• They would reduce the surface-area of the codebase.
• They would replicate functionality that exists in all text-based languages where creating functions or methods does not involve "touching" a GUI.

BD-Only VIs would be my default choice for small, low-level VIs that serve as subVIs deep inside my application. For example, does a VI that takes "a", "b", and "c" as inputs, and outputs "3D Distance = sqrt(a^2 + b^2 + c^2)", really need a GUI (the Front Panel)? Do most class accessor VIs really need a GUI (the Front Panel)?

Notes

• I realise that implementing BD-Only VIs is not trivial. But I believe that the benefits would far outweigh the implementation cost.
• The Connector Pane functionality would have to be implemented in the Block Diagram. This has already been suggested by CaseyM in a comment to his popular Make the default behavior of opening a VI open ONLY the block diagram idea: "Hell, you could even add the connector pane wiring functionality to the BD - then I'd have even less reason to go to the FP on most VIs."
• Steen Schmidt has aluded to the need for BD-Only VIs in a comment from 2014 to the popular Allow ONLY the Block Diagram to be opened Without Front Panel idea: "But this idea of Jack's here is about being able to have the BD open only, and leave the FP closed. Not about having VIs without FP at all (that discussion is a totally separate one, which we will have hammered out in due time :-)."
• I would be happy if, for technical reasons, BD-Only VIs would use a dedicated file extension, for example ".vibd", similar to how malleable VIs use the dedicated file extension ".vim".
• It would be ideal if BD-only VIs could be converted to regular VIs, and vice-versa. But I would be happy if, for technical reasons, this is not possible or too difficult to implement.

Thanks!

[GregSands]

I had a similar idea on here many years ago: https://forums.ni.com/t5/LabVIEW-Idea-Exchange/The-Block-Diagram-should-be-the-central-VI-component-...

It was closed as completed, given similar functionality was present in NXG. Given that NXG is now dead, perhaps this idea is not so complete after all.

[fefepeto_kb]

I agree that it's not trivial. As LabVIEW user, I have done quite a few scripting tools. Based on that here are my thoughts:

• "They would replicate functionality that exists in all text-based languages where creating functions or methods does not involve "touching" a GUI." FPs act as headers in C and C++, and function definitions in modern languages, so it's not entirely true.
• The terminals on block diagram have way less properties than Controls on the front panel, like display option for numerics, the ability to define enum values, etc.
• Having terminals only would need a new method to implement default values for optional "parameters".
• Harder debugging since unable to see the high level inputs and outputs, forcing the use of debugging on VIs that are intended to be inlined and the use of probes.
• The non-GUI VIs front panels could be scripted to be cleaned up. Indeed I would advise to create a script that goes trough groups of VIs and does a generic cleanup like the Nattyfier: clean up front panel, move error Wires to the back, disable auto-grow on structures, etc. all with options that can be saved in an INI. Maybe multiple INIs for multiple types of VIs, i.e: GUI VI don't have the FP touched. Reference Quick Drop Keyboard Shortcut - Nattify VI - NI Community
• "Do most class accessor VIs really need a GUI (the Front Panel)?", YES, but the front panel of override VI could just be a reference to the parent class's VI's front panel. The reason for "yes" is the multitude of VIs with the same name for different classes, like Init, Construct, Destroy, Close. Doing active work on large number of classes is evident by the class name, but a new developer coming in the picture or taking a look a few months later can really help to understand what data is coming in to these VIs.

[Petru_Tarabuta]

Hi Greg,
Sorry that I hadn't come across your idea before, but I support it.

fefepeto_kb:

• "They would replicate functionality that exists in all text-based languages where creating functions or methods does not involve "touching" a GUI." I stand by this statement. Creating headers in C/C++ does not involve touching or working with a GUI. It is still done entirely from the keyboard, which is faster. It does not involve aligning controls and indicators and/or distributing them vertically or horizontally.
• "The terminals on block diagram have way less properties than Controls on the front panel, like display option for numerics, the ability to define enum values, etc." I agree. This is part of the implementation challenge.
• "Having terminals only would need a new method to implement default values for optional "parameters"." I agree. And, in addition to definding default values, it would be nice to be able to define the input value of controls (something equivalent to typing a value in a FP control). This is part of the implementation challenge.
• "Harder debugging since unable to see the high level inputs and outputs, forcing the use of debugging on VIs that are intended to be inlined and the use of probes." I agree that not having a FP to see the values of controls and indicators would make debugging slightly harder. It is for the programmer to decide on a VI-by-VI basis whether they would benefit from using a BD-Only VI or from using a traditional VI. I would be happy to use BD-Only VIs and use probes if/when I need to debug them.
• I am aware of Nattyfier and other tools that can help clean-up the FP. I have written similar small tools myself for my own use. These tools are helpful and reduce the overhead associated with tidying up the FP. But it would be best to not need to use any tool at all - the overhead would then be 0.
• "Do most class accessor VIs really need a GUI (the Front Panel)?" I still believe that the answer is no. While it might be helpful for a new developer to see the Front Panels, this is not a strong enough reason to force all such VIs to have a Front Panel. Again, it would be a case of each team adopting the style that suits them best. If the team believes that it would be best for them to use traditional VIs to help new developers, that's fine. But another team might still prefer BD-only VIs.

[Neil.Pate]

Well, taking this one step further, I would suggest that the terminals on the block diagram actually display the input/output values, just like a constant.

[leahmedwards]

Interesting idea. Reminds me of the way VI snippets works. 

I think personally I'd prefer to be able to temporarily set the IDE to not open Front Panels if I'm just statically reading code, as all of those extra subVI front panels make navigation more difficult. Either that or have a 'Hide Front Panel by default when opened in IDE' option as a VI property.

However I'd definitely want the option to bring Front Panels back again when I pressed Ctrl+E! I tend to use them to test my code in even the simplest VIs. 

[Taggart]

How do I vote twice for this?

[fefepeto_kb]

To leahmedwards, that idea is discussed here: Make the default behavior of opening a VI open ONLY the block diagram - NI Community.

This just makes cross referencing since this idea is mentioned there :D.

[Petru_Tarabuta]

Just realised another legitimate use case for diagram-only VIs: "VI Tree" VIs such as the ones that ship with many Instrument Driver Network drivers.

For example, Agilent 34401.lvlib:VI Tree.vi

I personally like to create VI Tree VIs for some of the libraries I create. They serve as a kind of functions palette where you can see at a glance all of the public VIs of the library, organised by category and, sometimes, with additional informative notes (free labels).

VI Tree VIs contain meaningful information only on their block diagram. The front panel could/should be excluded.

[Petru_Tarabuta]

I have just added a comment (comment page 2, comment number 15) to Greg's original idea: The Block Diagram should be the central VI component (not the Front Panel) .

For ease of reference, I copy the contents of that comment below:

"

+1. Diagram-only VIs (VIs without a Front Panel) would constitute a massive improvement to LabVIEW.

I strongly believe that LabVIEW is a "real" programming language. It certainly is Turing-complete (computationally universal). But I can see how the fact that each and every VI must have a front-panel (a GUI) can make LabVIEW seem like a toy language in the eyes of a professional text-based programmer (C, C++, C#, Java, Python, etc).

In a typical text-based application the number of GUIs is much, much smaller than the number of routines (I use this term to encompass the terms methods, functions, and procedures). This is logical and efficient. As examples, why should the following routines have a GUI?

• A routine that takes "a", "b", and "c" as inputs, and outputs "3D_Distance = sqrt(a² + b² + c²)".
• A routine that takes a string as input and removes all the whitespace from the beginning and end of that string (equivalent to Trim Whitespace.vi).
• A routine that reads or gets a field from an object (a getter accessor method).
• And virtually all other routines in a typical application!

These routines do not need GUIs. This is evidenced by the fact that millions of text-based programmers around the world have been implementing these sort of routines happily in their languages for decades without needing a GUI for each of the routines! Moreover, many text-based apps have no GUI at all (e.g. console apps, Windows service apps). This is a perfectly legitimate use case that LabVIEW should support too.

The fact that each and every VI must have a front-panel costs us (professional LabVIEW programmers) dearly in at least the following ways:

• Having to spend a few seconds, a few tens of seconds, or more on “tidying up” each front panel. Tools like pressing Ctrl + U on the Front Panel help a lot but you still need to remember to do it and on occasion they still require the programmer to manually adjust the position of the FP controls and indicators.
• Our applications are bloated. They carry around lots of FP-related state data and/or settings for each and every VI that is part of the application, even for the VIs that will never show their Front Panel to the user once the EXE is built. This is extremely wasteful in terms of memory and disk usage.

Some people say: “I like Front Panels because they help with debugging”. I agree that Front Panels generally help with debugging. I too like using Front Panels for debugging. But debugging is generally a very short stage in the lifetime of a VI. A VI may exist in a codebase for 30 years, out of which it may be debugged for a total of 1 hour. Solution: Give people the option to have a Front Panel or not, and to toggle between the two states. If I need to debug my VI, I will use a Front Panel during the debugging session. Once I’m happy that the VI works well and passes the unit tests I would remove the FP, thus removing the bloat of that VI. Let’s appreciate that text-based programmers have managed to create “small” applications such as operating systems (Windows, Linux) without needing a GUI for each routine they had to debug!

For these reasons, I believe that the fact that each and every VI must have a front-panel is an anachronism. Diagram-only VIs would constitute a significant improvement and would be another step towards LabVIEW being considered a real language, even by professional text-based programmers.

Around six months ago I unintentionally created essentially a duplicate of this idea: Block-Diagram-Only VIs (VIs without a Front Panel). That idea currently has 24 kudos. If possible, I would like those kudos to be merged with the kudos of this idea (45 kudos currently).

Thanks!

"

[Petru_Tarabuta]

Another example, found "in the wild", of a VI that doesn't need a Front Panel.

The native All Palette VIs.vi found at <LabVIEW installation folder>\vi.lib\Utility\Data Type.

This is essentially just another example of a "VI Tree" type VI.