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

[Ben]

---

@jkodosky wrote:

>Data Flow is left to right

...

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

---

Yes that is what feels natural to me as well. For those situation were the data does loop back to form a cycle, the up and around wire will clearly flag that architecture.

I know I am preaching to the choir but ... Coding in LabVIEW manifests itself in the form of diagrams from our gestures and induendos (sp?). When properly structured the story of what happens in a diagram can be seen "at a glance". The path to my cube runs past all of the developers in our shop. That lets me peek over their shoulders as I come and go. More than just being nosey, it lets me review the code of the newbies s they are coming up to speed. Anytime I can not "read at a glance" the code, I stop and ask.

Moving forward with the Channel wires as the new tool in our tool box, I want to have a good idea how we should be using them. I am leaning toward sub-VIs interconnected using channels where ever I can avoid interactions with the GUI.

Take care,

Ben

[Ben]

---

@jkodosky wrote:

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

---

Too late!

The cat is out of the bag. (hopefully it is not Shroedinger's cat and it is killed now that the box is open).

I will not pester you about the details but I suspect there is a technique that could be useful... but I have no idea where when and how.

Hopefully curiosity will not kill this cat (smiley-wink)

Ben

[Ben]

Using sub-VIs and channel wires connecting the logical components I can achieve near Channel-nirvana

The only thing preventing this form of the CMH from being a Channel Diagram is access to the GUI.

Some of my associated created a set of VIs that will allow "by name access" to all GUI object references, that functionality was lacking for me because we had to know the class of the references to be able to cast the references to the correct type. It was also complicated by the challenge of ensuring any casting of the control references would be consist with any changes to the FP object themselves.

Example:

Booleans when "Latched when released" uses an property >>> value of variant. When set as Switched When Pressed" it is not a variant.

I would have to know all of the place a reference to a control was used to make sure I adapted the code if the control changed. Other type of FP objects are the same for example a Chart could be double, Waveform etc.

Using the approach of bundling the controls refs as I have shown above allows me to maintain the strict type of the reference for every control. Change the control , I see the coercion dot, I correct the Type defined cluster, ... if nothing breaks, I am done, if something does break, LabVIEW helps me find where that control reference is being used.

Why am I sharing this?

Because who better than the father of LabVIEW can invent a method to implement a truly wire-less VI?

Then the top level VIs could serve as both documentation on how an application is structured and the application itself.

I count myself as blessed that you have taken time to reply to my investigations.

Thank you,

Ben

[jkodosky]

>Then the top level VIs could serve as both documentation on how an application is structured and the application itself.

That is the goal!  In fact, it would be great if design could proceed top down as well as bottom up.  Put placeholder actors on the top level diagram and connect them with placeholder channels, so it really is just documentation at that point.  Then open each actor and refine it as a subnet of simpler actors, or as loop containing regular code.  As the actor implementation is fleshed out the channel types get defined and propagate.  The ultimate goal is to make the top level design "documentation" be as easy as drawing on the white board, with the advantage that as it gets refined it becomes the working application.

>...you have taken time to reply...

Thanks for your interest and enthusiasm!

Question for you: suppose the controls/indicators were on the actor panel as opposed to the top level panel so references didn't have to be passed in, but then there were an easy way to have the actor panel appear in a subpanel of the top level.  Would that be a workable paradigm?

--Jeff

[Ben]

---

@jkodosky wrote:

>Then the top level VIs could serve as both documentation on how an application is structured and the application itself.

That is the goal!  In fact, it would be great if design could proceed top down as well as bottom up.  Put placeholder actors on the top level diagram and connect them with placeholder channels, so it really is just documentation at that point.  Then open each actor and refine it as a subnet of simpler actors, or as loop containing regular code.  As the actor implementation is fleshed out the channel types get defined and propagate.  The ultimate goal is to make the top level design "documentation" be as easy as drawing on the white board, with the advantage that as it gets refined it becomes the working application.

>...you have taken time to reply...

Thanks for your interest and enthusiasm!

Question for you: suppose the controls/indicators were on the actor panel as opposed to the top level panel so references didn't have to be passed in, but then there were an easy way to have the actor panel appear in a subpanel of the top level.  Would that be a workable paradigm?

--Jeff

---

Please give me some time to think about that.

My target audience is often the Basic I and II graduate. I have to be careful not to develop code that is "too complicated" (actual quote from a customer after seeing an Action Engine in the code of one of my associates).

Sub-panels are border line complicated so I have to think about it.

Do have an idea in mind already?

Always curious,

Ben

[jkodosky]

Nothing definitive yet, other than maybe subpanels ought not be borderline complicated? 😉

--Jeff