Before I dive into the channel (wires) what do you think about them?

[Ben]

I admit my projects have delayed my entry into LV 2016 and the new Channel wires. But I was looking at them today and since they seem to cover many of the variations of the Queues I generally use to share information between threads, they look like a nice addition to my arsenal.

Has any of you started using them and either liked what you found or disliked any aspect of them?

Please share your thoughts!

There are no wrong answers, I am just trying to see if some of you that are in front of me on the LV Upgrade path can offer any insight.

Thank you!

Ben

[Bob_Schor]

I am possibly the #1 Fan of Channel Wires (I may have to arm-wrestle with Jeff K and AQ for this honor).  I've been using them for all of the code I've written recently, particularly for all new development work.  I've replaced the Queued Message Handler with the Channel Message Handler, the Queued State Machine with the Channel State Machine, etc.

Thus far, I haven't been concerned with "speed" as much as "clarity" and "simplicity", and the ability to "see at a glance" what is going on.  Particularly when dealing with "relatively slow" things, such as responding to Front Panel Events (UI processing) and not-time-critical State Machines (QMH or QSM), the structure of the CMH or CSM model is so much clearer that any few millisecond delays in processing are (for my purposes) trivial.  Plus there are speed-optimized versions of several of the Channels.

There are a few tricks.  I'm hoping to start an NI Blog (tentatively to be called "A Little BS") that discusses such issues as "What to do when you make enough changes in your channel-based code that the Channel routines fail to recognize your changes and generate persistent "missing VI" warnings" and "How to finesse the requirement that you cannot pass data into an Asynchronous Clone using a Channel" (I'm secretly hoping that my "clever" work-around becomes unnecessary in a future release).

Bob Schor

[Ben]

---

@Bob_Schor wrote:

...

There are a few tricks.  I'm hoping to start an NI Blog (tentatively to be called "A Little BS") that discusses such issues as "What to do when you make enough changes in your channel-based code that the Channel routines fail to recognize your changes and generate persistent "missing VI" warnings" and "How to finesse the requirement that you cannot pass data into an Asynchronous Clone using a Channel" (I'm secretly hoping that my "clever" work-around becomes unnecessary in a future release).

Bob Schor

---

Thank you Bob.

Care to write a bit more about those issues?

Ben

[billko]

I can't say I'm a fan yet, mostly because I haven't had the opportunity to try them out yet.  I'm hoping that I will learn to use it as I learned to use the conditional tunnel.

[Hooovahh]

Love em'.  Early on I was hesitant because it seemed to be yet another technology for talking between loops and isn't as flexible as some of the other ones.  Like for instance with a user event I can create N user events in a for loop and create a pretty elaborate publisher subscriber architecture.

But where channels wires are most useful to me, is not in these large architecture changes, but in the smaller ones.  There's been plenty of times when my requirements changed, and all the sudden I realize I need another small helper loop, or worker loop to do something dedicated.  I could implore a higher level architecture to help with data between these loops, but for small simple data types that I don't expect to change its stupid simple to just work with channel wires.  

Like I had a power supply actor that was very event driven.  It would get a message to turn on the PSU, and it would.  Periodically it would check that the connection was still there and reconnect if necessary but this wasn't very often.  Then I had a requirement to have a constant power mode.  For this I needed to constantly be adjusting the current setpoint, based on the load.  I could have updated the timeout of my main loop to be much shorter but there was still the overhead from the framework, and other things that could hold up my timing.  So an easier solution was just to have a parallel timed loop that I could have my main loop command it to start, and stop.  The data types of information going in and out of this timed loop didn't need to be dynamic, and I don't expect it to be changed.

So I wouldn't recommend trying to replace your polished architecture with channel wires (however it might work) but I would recommend using them for simple things at first like stopping a worker loop that should be doing extra, more dedicated stuff.

[crossrulz]

Since 2016 came out, I just have not had an application to experiment with.  But I see channels as a perfect fit for replacing a queue in a Producer/Consumer set up, mostly since it has a finished flag with it.

[Bob_Schor]

For Producer/Consumer, Channels are ideal.  Much simpler -- instead of four functions (Obtain Queue, Enqueue, Dequeue, Release Queue), there are only two (Create Channel Writer, Create Channel Reader).  Furthermore, "turning off" the Channel is easy -- as Crossrulz notes, there is an input on the Writer to say "I've just sent you the last element, this channel is done!", i.e. Sentinels are a "built-in" part of the Channel architecture.  And, in case you want to say "the previous element was the Last "Real" Element", you can say "Channel is done" and "Ignore this element".

Another design/mnemonic feature of Channels is the Channels run in "proper" left-to-right manner.  I found it illogical to have information "flow backward" from an Enqueue wire (notice how most Queue wires are on the left side of the diagram?).  With Channels, Readers are on the Left, Writers on the Right.  It does lead to S-shaped Channels if you stack your loops vertically (as I frequently do), but the distinctive appearance of Channels makes this pattern recognizable and thus mnemonic in itself.

Bob Schor

[Ben]

Thank you for all of the insight so far!

I am back on a 2015 project again so I will still have to wait to have more fun.

Can any of your speak to the details of passing clusters, and using a channel between different sub-VIs?

Are there complications in creating type def of the channel wires and adapting if the cluster definition changes?

They do look like they will help not only in saving me time but that other odd thing that Bob alluded to...

In complex applications the queues end up being a type of virtual connection between code modules and documenting which modules interact with which is not always clear without resorting to outside documentation describing the interactions, decorations in the diagram illustrating interactions, or at the very least following the queue refs around and praying that the queues as no named queues between dynamically instanciated VIs.

The pipe could clear up the interactions and make them obvious.

Again, thank you!

Ben

[Hooovahh]

---

@Ben wrote:

Can any of your speak to the details of passing clusters, and using a channel between different sub-VIs?

Are there complications in creating type def of the channel wires and adapting if the cluster definition changes?

---

The steps are no different than anything else.  The data type put into the one end, propegates to the other from a write to a read.  So make a type def, write a tag using it, then create a reader tag and the output is the same type def.  And obviously updating the type def updates in all the places that use it.

---

Ben wrote: 

In complex applications the queues end up being a type of virtual connection between code modules and documenting which modules interact with which is not always clear without resorting to outside documentation describing the interactions, decorations in the diagram illustrating interactions, or at the very least following the queue refs around and praying that the queues as no named queues between dynamically instanciated VIs.

The pipe could clear up the interactions and make them obvious. 

---

That's NI's major talking point in why this is more desirable than the wireless programming that by reference can lead to.

[Bob_Schor]

---

@Ben wrote:

Can any of your speak to the details of passing clusters, and using a channel between different sub-VIs?

A channel is specific for a data type.  If you have a Cluster and do a "Create Channel Writer", you will get a Channel of that specific Cluster Type.  Note that just as Wires are colored according to their type, Green Channels carry Booleans and Paths, Blue are Integers, Orange are Reals, Pink are Clusters, etc.

As for channels between sub-VIs, that's exactly the point -- it is how you asynchronously pass data from Sub-VI A to Sub-VI B.  The moment (well, probably a few nanoseconds after) you put the data into the Channel Writer, it appears at its Channel Reader(s), whereever they are located.

Are there complications in creating type def of the channel wires and adapting if the cluster definition changes?

 At the present time, you cannot create TypeDefs of channels, only of their content (i.e. the Cluster that you might use to Create Writer).  When you first open a VI with Channel, LabVIEW will "do a little dance" and compile some code meant to implement the Channel.  If you change the definition of the TypeDef that "lives" in the Channel, LabVIEW will do another dance when it notices the change and update its Channel-implementation VIs.  Relatively seamless (except in some rare occasions when you get "name clashes" with another Project ...)

The pipe could clear up the interactions and make them obvious.

They sure do!

Again, thank you!

---

You are most welcome.

Bob Schor