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

[Thoric]

I LOVE this idea because it means that in all other cases where you want the scenario "A" to occur you don't need a wire trailing across your real estate.

I quite often have a need to use the structure's contained space for coding and the majority of the terminals just need wiring straight across (which the linked tunnels feature is excellent for), typicallyin Event Structures (think XControl facade block diagram). However this results in lots of horizontal lines that chop up my available space for code, which then often end up careering about to avoid running under other primitives/subvis. With this idea I could declare that unwired terminals receive their value from the corresponding input defined in the "Output Tunnels Defaults" case and free up all my real estate!

This is an example of one of my XControls, and you can see how the Display State datatype passes straight through one case of my case structure completely untouched. With this idea I could define scenario "A" in the new special case and avoid having to wire it up in the "0.." case, therefore avoid having to code around it. Other scenarios I encounter are much more serious with may terminals that need to pass straight through a case structure (like I said, think of an Event Structure in an advanced Producer loop), I just can't find one right now that I'm able to share publicly. Please, everyone, vote for this!

[JÞB]

I absolutely Love the idea  Suddenly largeish state machines and QMHs are more readable and can contain comments instead of wires!  I Can already tink of several ways to use this feature that would be drop-dead no-brainer code development enhancing.  Think "if not wired Enqueue!!!"

Definate Kudos

[JÞB]

We would need to put some limitations on what can be placed in the default definion case I suppose to save us from ourselves.  No async nodes, no structures (nested default tunnels could really get messey), no subvis that cannot be inlined and no debugging in the definition come to mind almost imidiately as suggestions.

If implemented I can imagine my forum solution count would also increase as the feature is adopted.

[m112]

I support this.  Or any similar solution to this glaringly painful problem.

[crossrulz]

m112:  If you support this so much, give it a Kudos.  NI looks at the Kudos count first when looking at the idea exhange.

[abeaver]

Bringing up an old topic here, I know. But has this idea or any like-idea been implemented. This is a wonderful idea.

[wiebe@CARYA]

Would there be restrictions on what can be in Output Tunnel Defaults?

What happens when we put VIs in there? Or property nodes? It might sometimes be useful, but I'd expect only the wire that's not wired to be evaluated, purely for performance reasons (not sure if that's feasible or desirable).

Would that code still be executed even if there is no tunnel that needs to know it's default? (I'm with Alejandro on this, it must execute, how else would it be able to do an increment or add two inputs?)

Would that case also be added to loops? In this thread this one is suggested as a solution, but that one is actually more focused on loops.

Just thinking of possible abuse\misuse\use cases...