Show/Hide reference terminals directly on controls

[SeanDonner]

One of the fundamental idioms in LabVIEW is "never use a local variable when wiring directly from/to the control will suffice."  As many of us know, local variables break the dataflow paradigm and should only be used in cases that necessitates them.

No doubt there is much value to using references to front panel controls in architectures such as a QSM, however, I felt like I was commiting sacrilege every time I was forced to wire these references from local variable-like reference nodes while leave dangling controls hanging about. 

Every control has a reference to it under the hood, so why not have the ability to show a reference terminal on the control itself; this way we can start our reference wiring straight from the control itself. 

 Control Values

                   

---

Control References

              

---

I suggest we show/hide the reference terminal using the same method Shared Variables show/hide the timestamp terminal

[altenbach]

Typically, my references are outside the main loop, while the terminals need to be in the loop or even in their respective event case (e.g. latch action booleans).

Most of the time I would probably not be able to utilise this suggested improvement. Can you describe a scenario where it offers a significant advantage?

[AristosQueue (NI)]

Linking the reference to the terminal gains you nothing performance wise or usability wise. A reference to the control coming out of the FPTerminal would have exactly the same performance characteristics as one placed elsewhere. There's no reason to link these two, and it just creates a confusing node, IMHO -- one where people might think it is ok to use the reference *because* it is attached to the FPTerminal.

[SeanDonner]

100% agreed that this suggestion adds nothing in the field of performance, that was never my intent. 

If you boil it all down, I believe my issue is with how the LabVIEW IDE makes reference nodes look nearly identical to that of local variables yet they are not symmetical in their nature.  The main discrepancy is that a FPTerminal node has no method to provide its reference on the BD like it does its value.  IMHO this creates a mixed message to students of LabVIEW where on one hand we say "a fundamental LabVIEW idiom is to maintain dataflow by obtaining FPTerminal values from a wire attached to the node itself" and then on the other hand we say "completely disregard what I just said about references, even though they look nearly identical to local variables, there is no method to achieve dataflow from a reference value back to the FPTerminal it references." 

[tst]

"...there is no method to achieve dataflow from a reference value back to the FPTerminal it references."

What does that even mean? The value is special because that *is* the data in "dataflow". The reference is not something which has anything to do with dataflow - it's simply a way to refer to the control itself (as opposed to the data, which is usually the important thing).

By the way, I'm not trying to be cynical or anything like that. I'm generally interested in how other people see things, because it's often useful to understand the misconceptions people have and sometimes you understand that there are things which you can also do better, so I'm actually interested in knowing why your second good has a question mark after it.

[SeanDonner]

Hi tst, thanks for the questions; I'm always open to critical thinking. 

As a graphical language, the way things look and feel convey just as much information to the programmer as the wiring diagram itself; much like body language does for human communication.  Pretend for a second that you have been using LabVIEW for a few months and you have the whole dataflow concept down and you understand why minimizing the use of local variables is a good thing.  Now you take a LabVIEW Core course and the concept of FPTerminal references are explained. You look at the "Bad!" example for values, then you look at the "Good?" example for references and you realize that the visual information looks nearly identical between the two but one method is highly discouraged and the other method is mandated (not just encouraged); and that's when many students go WTF?

I think it's fair to say that a reference to a FPTerminal is an attribute of said terminal and not some disjoint concept.  If you believe that, then hopefully you can see the discontinuity in how the IDE forces us to use references as disjoint nodes floating in space with no visual tie to the FPTerminal it references(1); my proposed solution shores up this gap.  Now let me be clear, just as there are completely legitimate uses for local variables, there are certainly legitimate uses for having reference nodes be local-variable like; altenbach came up with some very good examples of those.  It may even be that the cases for when my idea could be utilized would be a fraction of the cases for when you would use reference nodes as they currently exist; but I still believe that we should have the option to do it my way nonetheless.

Also, the statement about you wanting "to understand the misconceptions people have" is extremely relevant in this case because my proposed idea was highly influenced by the many experiences I've had as a LabVIEW CPI.

(1) Yes, the reference label has the name of the control it references by default but there is no way to remove the visual gap of space between the two

Regards,

-Sean

[Intaris]

But you can still have multiple references to the same control, you can't duplicate the terminal with it, so it only solves the visibility problem for a single reference, not for all of them.

[SeanDonner]

Your statement is factually correct but you would not do as you said even if we were talking about control values.  If you wanted to use a control value in more than one place, you wouldn't duplicate the control nor should you create a new local variable from the control, you would branch off the value wire which leads back to the control.  Similarly, if you needed to use the reference in more than one place, you branch off the reference wire rather than create a new local variable-like reference node; again this is all under the assumption that you can branch off the wire.

[Darin.K]

I knew this sounded crazy.

http://forums.ni.com/t5/LabVIEW/Changing-the-Property-Node-label-does-not-update-the-Terminal/m-p/18...

From a syntax point of view it makes sense.  A reference is just a number, its type may give it some special meaning, but at the end of the day it is a number and should be able to flow as freely in wires as other values.  DVRs are just references and they have wires.  Need more than one?  Branch it.  (Now I want to use the IPES to Get/Set properties).

The linking now is fragile since you can edit the label of references (why?), a wire is a simple way for your eye to follow the linking between a PN and its control.

[SeanDonner]

Hi Darin,

I'm going to read through that post when I get home but as of now It's not clear to me whether or not you think my idea is a good one

[Darin.K]

Great minds think alike

or

Fools seldom differ