VIs without Front Panels - or with several!

[GregSands]

This is a shameless plug for a new idea I've submitted to the Idea Exchange suggesting that by default, a VI should not have (or need) a Front Panel. Connections to the con-pane are defined from the Block Diagram - after all that's where the data is used, and the subVI interface to that data should be specified. One (or more) Front Panels can then be added which provide a user interface to the BD data (controls/indicators). Perhaps one is the standard run-time view, and another is a debugging view (like an enhanced Probe window). Or for many subVIs, there may be no FP at all.

Kudos (or critique) welcome!!

[asbo]

I think this response isn't as thorough as the idea probably deserves, but in short it's an interesting perspective but seems like a pretty radical change to the LV paradigm. The FP and BD are pretty comfortably categorized functionally and I don't often find myself disagreeing with the delegation of functionality. The fact that it would be such a tremendous change to business as usual doesn't bode well for it being implemented.

[Grampa_of_Oliva_n_Eden]

This is a shameless plug for a new idea I've submitted to the Idea Exchange suggesting that by default, a VI should not have (or need) a Front Panel. Connections to the con-pane are defined from the Block Diagram - after all that's where the data is used, and the subVI interface to that data should be specified. One (or more) Front Panels can then be added which provide a user interface to the BD data (controls/indicators). Perhaps one is the standard run-time view, and another is a debugging view (like an enhanced Probe window). Or for many subVIs, there may be no FP at all.

Kudos (or critique) welcome!!

What part of the FP do you not like?

Re-entrant sub-VI techincally can have multiple FP (one FP for each instance).

If the FP is never shown it can be stripped in the build.

So please forgive when I ask "what missing or what are you trying to achieve?

Curious,

Ben

[GregSands]

What part of the FP do you not like?

First up, it's not that I don't like Front Panels! Rather, the idea comes from the recognition that, as evidenced by a fair number of ideas in the Idea Exchange, FPs often add unnecessary work to developing VIs. I was trying to pull a number of different ideas together into a solution, sparked by reading this idea which suggests adding yet another layer to a VI - and questioning whether we can reduce complexity instead of increasing it.

There's been some discussion on how to limit the FP to show only what's needed for the user interface (e.g. here). Having unneeded (from the interface point-of-view) controls and indicators on the FP means we need to work around issues such as edit-vs-run-time displays, setting up tab orders, rescaling controls (but only some of them) as panels change size, disabled code, and so on. The basis of my suggestion is not that we shouldn't have FPs, but that FPs should only contain what is needed to be seen by the user.

Secondly, the data that needs to be seen during development or debugging is often very different again. When we use a Probe, we essentially create a virtual indicator. Take the Probe Window slightly further in its development, and we now have a second FP, which contains another set of controls/indicators for showing, or setting, the data during execution.

Also, for many VIs, the variables that are passed through the conpane interface are not required to be shown in the user-interface - Error clusters for example. It makes sense to be able to link the conpane directly to BD controls, and therefore there is no need for the controls/indicators to appear on the FP at all - many subVIs without user interaction wouldn't need an FP defined at all. To me, the conpane has a much stronger link to the BD than the FP, as it is there to provide the programming interface to the code. The downside would be that it is perhaps more difficult to find terminals on a crowded BD, but that could be enhanced (e.g. mouse-over the conpane, and everything fades except for terminals).

Perhaps there would even be the opportunity to see the FP as a virtual cluster.

seems like a pretty radical change to the LV paradigm.

The LV paradigm presumably arises from the concept of Virtual Instruments, where the controls/indicators are what you define your instrument by - and much early code was all contained within one VI! This idea suggests that LV has perhaps grown past that stage, with far more emphasis now on subVIs, classes, libraries, etc which are maybe more like patch panels or breadboards (still thinking as an engineer!) - things that are hidden from the end-user. I don't see it as such a radical change - more a response to the way that LabVIEW is being used anyway - to make that process easier and more transparent.

Edited September 13, 2011 by GregSands

[Daklu]

I absolutely agree with you Greg. The front panel is a throwback to the days of widget-based programming. In some ways LV reminds me of programming in VB6. Widgets are great for RAD--which certainly is part of Labview's core audience--but as many of us have experienced they become too restrictive when trying to do something outside of the predefined functionality they provide. On top of that, widgets tend to couple business code to the UI, which hurts in the long run.

I recall other discussions where AQ or another blue commented that they are working towards the point where a block diagram can be loaded without loading the front panel, but it's a slow and tedious process. Perhaps once they accomplish that we can toss the fp altogether.

[Petru_Tarabuta]

+1 kudos.

I have just added a comment (comment page 2, comment number 15) to Greg's idea on the LabVIEW Idea Exchange: 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!

"

[drjdpowell]

I think your second point is wrong; VIs without the front panel loaded don't use any resources.  EXEs don't even include the code for those front panels.  

[ShaunR]

On 7/6/2024 at 12:23 PM, Petru_Tarabuta said:

As examples, why should the following routines have a GUI?

Because I can immediately test the correctness of any of those VI's by pressing run and viewing the indicators.

On 7/6/2024 at 12:23 PM, Petru_Tarabuta said:

But debugging is generally a very short stage in the lifetime of a VI.

Nope. That's just a generalisation based on your specific workflow.
If you have a bug, you may not know what VI it resides in and bugs can be introduced retrospectively because of changes in scope. Bugs can arise at any time when changes are made and not just in the VI you changed. If you are not using blackbox testing and relying on unit tests, your software definitely has bugs in it and your customers will find them before you do.

On 7/6/2024 at 12:23 PM, Petru_Tarabuta said:

If I need to debug my VI, I will use a Front Panel during the debugging session.

Again. That's just your specific workflow.

The idea of having "debugging sessions" is an anathema to me. I make a change, run it, make a change, run it. That's my workflow - inline testing while coding along with unit testing at the cycle end. The goal is to have zero failures in unit testing or, put it another way, unit and blackbox testing is the customer! Unlike most of the text languages; we have just-in-time compilation -  use it.

On 7/6/2024 at 12:23 PM, Petru_Tarabuta said:

Once I’m happy that the VI works well

I can quantitively do that without running unit tests using a front panel. What's your metric for being happy that a VI works well without a front panel? Passes a unit test?

On 7/6/2024 at 12:23 PM, Petru_Tarabuta said:

A VI may exist in a codebase for 30 years, out of which it may be debugged for a total of 1 hour.

It may be in the codebase for 30 years but when debugging I may need to use the suspend (see below) to trace another bug through that and many other VI's.

There is a setting on subVI's that allow the FP to suspend the execution of a VI and allow modification of the data and run it over and over again while the rest of the system carries on. This is an invaluable feature which requires a front panel

On 7/6/2024 at 12:23 PM, Petru_Tarabuta said:

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

This is simply not true and is a fundamental misunderstanding of how exe's are compiled.

Can't wait for the complaint about the LabVIEW garbage collector.

On 7/6/2024 at 12:23 PM, Petru_Tarabuta said:

Diagram-only VIs would constitute a significant improvement

We'll agree to disagree.

Edited July 7 by ShaunR

[mcduff]

On 7/6/2024 at 7:29 AM, drjdpowell said:

I think your second point is wrong; VIs without the front panel loaded don't use any resources.  EXEs don't even include the code for those front panels.  

 

9 hours ago, ShaunR said:

This is simply not true and is a fundamental misunderstanding of how exe's are compiled.

Excuse my ignorance and stupidity, but I never really understood the following settings in the Compile Settings. I always leave them as the default value. Do those settings remove both Front and Diagram from VIs in the EXE? I know the setting may affect debugging an EXE file and possibly some of the tools to reconstruct VIs from an EXE, but should I be checking or not checking those options in an EXE? Thanks

[ShaunR]

10 hours ago, mcduff said:

 

Excuse my ignorance and stupidity, but I never really understood the following settings in the Compile Settings. I always leave them as the default value. Do those settings remove both Front and Diagram from VIs in the EXE? I know the setting may affect debugging an EXE file and possibly some of the tools to reconstruct VIs from an EXE, but should I be checking or not checking those options in an EXE? Thanks

These are for shared libraries.

• Quote

   

  • Use default save settings—Saves the VIs using default save settings. The default save setting for the VIs you add to the Exported VIs and Always Included listboxes on the Source Files page is to remove the block diagram. The default for all other VIs is to remove the block diagram and the front panel. Remove the checkmark from this checkbox to change the default settings for each item you select in the Project Files tree.
    • Remove front panel—Removes the front panel from a VI in the build. Removing the front panel reduces the size of the application or shared library. If you select yes, LabVIEW removes the front panel, but Property Nodes or Invoke Nodes that refer to the front panel might return errors that affect the behavior of the source distribution. LabVIEW enables this option if you remove the checkmark from the Use default save settings checkbox.

      Note  If you execute the Run VI method after placing a checkmark in the Remove front panel checkbox, the Run VI method will return error 1013.

    • Remove block diagram—Removes the block diagram from a VI in the build. LabVIEW enables this option if you remove the checkmark from the Remove front panel checkbox. If you remove the front panel, you also remove the block diagram. As a result, if you place a checkmark in the Remove front panel checkbox, a checkmark automatically appears in the Remove block diagram checkbox.

   

  •  

 

[Neil Pate]

On 7/7/2024 at 2:34 PM, ShaunR said:

Because I can immediately test the correctness of any of those VI's by pressing run and viewing the indicators.

Nope. That's just a generalisation based on your specific workflow.
If you have a bug, you may not know what VI it resides in and bugs can be introduced retrospectively because of changes in scope. Bugs can arise at any time when changes are made and not just in the VI you changed. If you are not using blackbox testing and relying on unit tests, your software definitely has bugs in it and your customers will find them before you do.

Again. That's just your specific workflow.

The idea of having "debugging sessions" is an anathema to me. I make a change, run it, make a change, run it. That's my workflow - inline testing while coding along with unit testing at the cycle end. The goal is to have zero failures in unit testing or, put it another way, unit and blackbox testing is the customer! Unlike most of the text languages; we have just-in-time compilation -  use it.

I can quantitively do that without running unit tests using a front panel. What's your metric for being happy that a VI works well without a front panel? Passes a unit test?

It may be in the codebase for 30 years but when debugging I may need to use the suspend (see below) to trace another bug through that and many other VI's.

There is a setting on subVI's that allow the FP to suspend the execution of a VI and allow modification of the data and run it over and over again while the rest of the system carries on. This is an invaluable feature which requires a front panel

This is simply not true and is a fundamental misunderstanding of how exe's are compiled.

Can't wait for the complaint about the LabVIEW garbage collector.

We'll agree to disagree.

^ 100% all these things.