Case Structure Tunnel Improvements

[Michael Aivaliotis]

The idea arose on Info-LabVIEW and was initiated by ggatling.

Adding the 'Use default if unwired' option to the case structure output tunnels was (IMO) a great idea.  But I would still like to take them one step further, though this might be a new kind of tunnel for case structures...

So often I have a case structure inside of a while loop and several shift registers on the while loop.  Each case usually operates on only a subset of the shift registers, so I spend a great deal of time (and diagram space) making wires from one side of the case structure to the other.  When I come back later, there is no readability advantage to having made all these wires that only serve to say this case does not operate on this data.  So....

How about a pair of tunnels for a case structure such that when the output is unwired it simply passes through the data that was on the input tunnel... much like a for loop shift register behaves when N=0, or like the dynamic event terminals on an event structure.

ggatling

If you want to speed up wiring of your tunnels, here is a utility that will do that for multiple cases in one shot. It doesn't eliminate the wiring but it makes it a whole lot easier:

http://forums.lavausergroup.org/index.php?showtopic=211

Here is the discussion and responses to this initial post:

Great idea. What I currently do to have a default case that has all the tunnels wired through, and then I just duplicate that case and delete the wire that is going to be modified in the case. But when you decide to add a shift register, you have go back and make space and wire up the new tunnels. And the through-wires take up real estate. So I am all in favor of this new construct. How about the "virtual pass-through"?

-- 

David Ferster

How about a pair of tunnels for a case structure such that when the output is unwired it simply passes through the data that was on the input tunnel...

I second the motion. Could the current tunnels just be modified

slightly to implement this idea? For instance when you wanted the data

to pass thru for a particular case you could right click on the tunnel

and select the "just passing thru" option that would display a small

arrow on each of the tunnels for that case. As you flip through the

cases, the tunnel image would have to update to no arrow if it was

wired. Of course the arrow on the case tunnel would have to be

distinctly different than the Sequence Local Arrows.

--

Brian Bean

I would prefer a even more flexible solution: Make a special, usually

hidden case with a name such as "_default outputs_". For example, you

would right-click on the case and select "define default outputs". Now

you see a case that has a different color. Here you can wire away and

define what the output terminals should receive in all the "regular"

cases *if* they are not wired. Only outputs you don't wire here would

receive the default for the data type as we have now. By default, this

case is empty, duplicating the current behavior for unwired outputs.

In your very special case, you would connect the desired input and

output tunnels across, but now the possibilities are truly endless.

Now you also have the opportunity to do math, e.g. insert a [+1],

[-1], etc as often needed. One output tunnel could receive a special

wired constant (1, -100, Inf, NaN, etc.) that would be more suitable

for the particular situation than the default for the data type we

have now. One output tunnel could receive a mathematical result of

multiple input tunnels.

Just some ideas ... (We can dream)

Christian Altenbach

This is a great idea! This would make state machines/QMHs soo much 

easier...

I do think the special case should not be among the usual cases, because 

it's not something that is selected by the "?" input. But there's plenty 

of room on top of the case structure to add a special thing to access 

this "define default outputs" diagram. Besides you don't want/need this 

feature on small cases.

Joris Robijn

Yeah I thought of this too. It would be very useful.  They could have the same behavior as the loop shift registers (remembering

last value when uninitialized, add elements to the left to remember latest N values). It could replace the while loop/case structure

combo in state machine and LV2 functional globals. Now just add a "next case" output terminal (to set the case that will be executed

next time) and you have a state machine in a single structure.

They could also be used in sequences to pass data from one frame to the next, keeping the left to right data flow (unlike sequence

locals).

jpdrolet

Since no one's mentioned this yet (although I'm sure I've seen it in these pages before), if you plan properly, you can consolidate all your shift registers into one cluster and then just replace using "bundle by name" the item that needs changing in any given case.

However, I must concur that for individual shift registers (like the state the program should go to next), it would be great if I could specify that the "default" value was, say, "Poll" instead of "Init" (where "Init" is the first state and thus currently the default state).

Just my $0.02 worth...

idaq

I'm not much in favor of NI adding some new visual variation on tunnels

on cases.  You'd have to add them as matched pairs of objects, much like

shift registers.  They would require some vertical spacing along the

sides of the case structure, like shift registers.  Even if the case

diagram area between them were freed up, they would still 'stack up'

along borders. Though they wouldn't wreck dataflow, they might make the

visual flow of data less obvious.  This is the same problem I have with

default-value output tunnels, though I understand why (with the advent

of the event structure) thisfeature became necessary.

I am intrigued by Christian Altenbach's suggestion of a 'default-values'

case - at first look, this doesn't seem like it would obscure dataflow,

in fact it could enhance it.  Until NI adds some new block diagram

feature for this, I'm content to string a set of wires across multiple

cases.  And that's why I wrote the tunnel wiring utility - I always need

to add a wire *after* the cases have been established.

David Boyd