A better way to define the output of unwired output tunnels

[altenbach]

This one of my very old ideas and goes all the way back to InfoLabVIEW. I recently got reminded in this thread to write it up as an idea. You might have heard it before. If not, read it :D)

Currently, an output tunnel gets the default value for the given datatype if "use default if unwired" is enabled and a case executes where it is not wired. Recently, we also got the "linked tunnels" feature, which is more like an editing assistant.

Many times we have a big stack of cases but the computation of many outputs is shared by many cases, maybe with one or two notable exceptions. 😉 It would be cool to be able to define this shared "default" code only once so it is executed unless we create an exception case.

My suggestion is to have a new, special case that allows us to define the output of each tunnel for cases where it does not receive an overwriting input.

The image shows a few possibilities for an event structure (same applies for all other relevant structures).

A: A reference is wired across by default. We don't need to wire across any other case.

B: Nothing is defined, so it acts like today. This is the default, so everything is automatically backwards compatible with existing code.

C: A number is incremented with each iteration unless we overwrite in a specific case

D: The default output is based on the operations of several inputs.

E: If a tunnels is unwired, we get NaN (or whatever we need) instead of zero. For I32 me might want -1, for example.

F: Same as A. This is similar (but not exactly the same) as linked tunnels. (I.e. It also applies to existing unwired cases)

G: This tunnel is defined in all cases. If we add an unwired case later it would act like B.

H: (not shown): certain global event terminals (e.g. time) should also be available in the "default definition case", because we might want to utilize it for a default output.

 Downconversion would be somewhat messy. It would probably need to wire the relevant default operations into all cases where an output is not wired, keeping the functionalty the same.

Message Edited by altenbach on 07-11-2009 10:45 AM

[GregSands]

Great idea, though it does make it more difficult to know what will happen at an unwired terminal without looking at the Defaults case. I especially like being able to do E & A, but C or D could prove confusing for a while! I would suggest two enhancements:

- a different unwired box signifying that the default behaviour is not the "default" behaviour.

- a mouseover on an unwired box could overlay (semi-transparently?) the Defaults case temporarily, or some other popup of the new action.

[Intaris]

I'm split on this one.  One one hand I can appreciate the idea but on the other I can only think it decreases the readability of the code....

[AristosQueue (NI)]

Looking at case G, it seems like there needs to be some way to say, "There is no default. You must wire this in every case." I'm thinking of the state transition enum that often occurs in state machine diagrams -- whatever state you're in, that state is responsible for specifying its next state. Having a default state defined would seem more likely to lead to "I forgot to wire that" errors, since you'd no longer have a broken VI. Do others agree with me? If so, what would we add to the diagram to indicate "this tunnel has no default"?

[altenbach]

G is just dark because it is wired in all regular cases. If we would add a regular case where it unwired, it would automatically look like B. For people that never use this idea, and for legacy code, things will look as always. (Sorry, posting via phone...)

[altenbach]

Maybe we could add for clarity the following: If we hover directly over a shaded tunnel, and the currently visible case is unwired for that tunnel, the case code should momentarily bleach and the default code Leading to that tunnel show instead (maybe elevated with a drop shadow).

[Ray.R]

I'm with Intaris on this one..

It would be okay if you could turn off the "Ouput Tunnel Defaults" feature.

I'm worried about novice programmers who would not have a clue about the proper use of this feature.

Or old guys that forget those new features, or suddently jump from LV7.1 to LV2012.

I'm not yet sold on this one...

[alejandro5042]

Perhaps doing it this way hides important functionality in a special case users may not know exists. Moreover, does this special case execute before, after, or simultaneously with the actual case it is trying to execute? Naturally, it should be simultaneous but then you get into debugging questions about how to best represent that at runtime.

I believe this related idea does a better job displaying this behavior:

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Add-feedthrough-shift-register-nodes-to-Event-and-Case...

[JackDunaway]

---

@alejandro5042 wrote:

does this special case execute before, after, or simultaneously with the actual case it is trying to execute?

---

This case does not execute - it's a "dummy" case that stores "macros" to define the action the compiler should fill in for unwired linked input-output terminals. Note how the event banner does not have a case number in it (just says "Output Tunnel Defaults") and the background of the "case" is greyed.

[altenbach]

>  I'm worried about novice programmers who would not have a clue about the proper use of this feature.

> Or old guys that forget those new features, or suddently jump from LV7.1 to LV2012.

If you study all this once more, you'll see that this is of absolutely no concern. Everything will look and act exactly as before. There is no additional case plugging up the thought process when we flip through the cases, unwired output tunnels get the default for the datatype, etc.

Unless you willfully use this feature, it is completely invisible! Only once customized defaults are used for output tunnels, the tunnels might take a slightly different look to show that we are not in Kansas anymore.

We only see that "special" case if we right-click and say "define unwired outputs" or some other mechanism, e.g. press a little button in the upper right corner of the case/event structure. Once we are happy, we [x] out of it. (lets place a grey x in the upper right corner!). Maybe we could also go to that case when we double-click an output terminal, for example. Exact UI mechanics to be determined and improved.

As I said before, often the current default behavior for unwired tunnels is not what I want. For DBLs I often would like an NaN. Other related suggestions cannot do "math", e.g. base the default output on the result of several inputs.

Many times cases share a lot of code that needs to be repeated in each case, just because one or two cases are slightly different. Wouldn't it be more economical to define the common code exactly once. Much less error prone, much more maintainable. A single change is sufficient if we need to modify the common code.

Personally, I still really like this idea! 😄 (not just because it is mine ;))

[Ray.R]

Thanks for the additional explanation.  I may have to read it again so that it sinks in..  It "clicked" in my mind..  Okay... It is different from what my brain had understood.  With the additional details, my scale went towards "I like it & I could use it".  So kudos..

It is basically like having a state machine with an initialization state where if the output of the tunnel is unwired, instead of going to the default value for that type, it defaults to the value from the initialize state.  Yes.  This I like.  And it is more versatile than the other suggestion that I read..

Thanks Christian.

🙂