Getting Started With Channel Wires

[jkodosky]

>"Wires imply execution order" now has a caveat "Except for Channel wires"

Here's another perspective. Say you live in a house with indoor plumbing and all is well.  Then someone shows how you can have conduit installed containing electrical wires and then you will be able to use electrical appliances in addition to your plumbing fixtures.  Is this a benefit for you?  You will have to relax your view that everything which looks like a pipe must carry water.  You will have to learn the subtle difference between conduit and pipe in order to connect the proper fixture, but the advantage will be the greater functionality you'll have in your house.  If you can adapt to that change you'll be in much better position to benefit later on from the addition of natural gas pipes, central vacuum system pipes, and so on.  Of course, none of these new technologies is obligatory, and if you don't derive any benefit you are free to ignore them.  

An introductory course on Channels was given at a university to a class of students who were just learning LabVIEW, and to a class of students who were seasoned LabVIEW users.  The new users caught on to the concept of Channels more quickly than the seasoned users, confirming the idea that the seasoned users had to unlearn the dogma that everything which (superficially) looks like a wire must imply execution order.  My take-away from this experiment is that we should teach Channels in the beginning LabVIEW course.  An interesting comment from a seasoned user was that Channels made things too easy and beginning users should be forced to learn the hard way first. 😉

--Jeff

[Ben]

Good analogy Jeff and the conduit vs plumping hit me again when I saw this diagram ...

Where, like a fancy restroom, I found two sinks.

I do have some unlearning to do.

I suspect this has something to do with type propagation but it will take me time figure where the type is coming from.

I will most likely be updating one of the axioms to...

Plumbing is like electrical wiring and Channels. When you do a good job few people will ever see what you did.

Ben

[jkodosky]

>Data Flow is left to right

Data flow from left to right seems like a general convention that aids in creating as well as understanding diagrams.  However, we sometimes find it convenient to bend the rule a little.  If we have a long skinny diagram it may be better to have it fit on one page than have to scroll back and forth to see it all.  In that case we typically put the second half below the first half and have a backwards flowing wire going from the right end of the first half to the left end of the second half.  A moment's reflection makes it clear what's going on so this is reasonable.

Using shift registers makes it possible to stick to the convention of left to right flow (because the shift register does the hidden back flow from right side to left side), but sometimes it is convenient to use a feedback node instead.  That introduces backward flowing wires, but again, it's easy to see what is going on as long as the extent of the backward flow isn't too long.

To make backward flowing wires more instantaneously recognizable I could imagine decorating wires that flow left or up with a background glyph pointing left or up.

>Sub-VI that run in parallel are generally arranged vertically

Now, a case can be made that having the same convention of left-to-right flow for Channels makes sense.  It certainly seems that a diagram such as examples/Channels/Stream Rate Conversion/Multirate FIR Filter.vi would not benefit from vertical arrangement.

A diagram like this looks similar to a LabVIEW Comms style diagram, and those diagrams definitely benefit from a convention of left-to-right flow.  It is probably true that applications using Channels will often need cycles (A sends messages to B, B sends to C, C sends to A) but that seems to be no worse than the backward flowing regular wires described above.  Seeing where the backward flowing Channels are could be enhanced using the same mechanism described above, using a background glyph.

It might be better to preserve left-to-right flow for both regular wires and Channels, and to relax the notion of having parallel processes stacked vertically.  And it turns out stacking vertically isn't as neat as it sounds.  Imagine a producer loop and a consumer loop connected by a Channel.  The Write Endpoint is inevitably at the right edge of the producer loop and the Read Endpoint is inevitably at the left edge of the consumer loop.  So, arranging the loops vertically, the downward flowing Channel also has to flow right-to-left.

And when you add the complication that cycles will require backward (upward) flowing Channels, preserving left-to-right flow and giving up on vertically stacking seems to be the preferable convention.

--Jeff

[jkodosky]

Okay, that diagram is not something to study or worry about.  It is confusing and should have been hidden or had an explanatory note because it's a trick to get around the limitation of another trick we use to make Channels fast.  What looks like a regular subVI call is actually a fast version of a call-by-reference which uses the reference on the Channel wire at runtime.  The subVI has an input Channel and an output Channel, only one of which is used for any endpoint instance.  To speed up the call we arbitrarily connect up the calling VI's Channel (only one, either input or output) to the subVI input Channel.  In the future we should figure out how to avoid having to do this trick while still getting the performance we want. 

--Jeff