Getting Started With Channel Wires

[Ben]

SHOULD I be allowed to but a case structure around a sub-VI that uses a channel wire?

I get his message

"

This channel wire enters and leaves the same structure. Because channel wires do not create dataflow dependency, it is semantically meaningless for a channel to pass through a structure. You must wire around the structure instead of through it.

"

When I try to do this...

So.....

Shouldn't putting a case structure around a sub-VI that uses a channel wire be equally illegal.

What type of use case should let me put a case structure around the sub-VI that it is allowed?

Ben

[Hooovahh]

---

@Ben wrote:

can I back-save to 2015 from code in 2016?

Is there any way to include the Extra files in the source code folder?

---

I have not done it but it is my understanding that this won't work.  In 2015 channel wires were implemented using XNodes and it was semi-experimental.  You needed to run a VI buried in your install folder to add support for them.  In 2016 channel wires are a bit more native and are no longer a series of XNodes and so I don't think the back saving mechanism would work.

[jkodosky]

The Running Average VI has an input channel and an output channel.  Putting a case structure around it isn't the cause of the problem.  Rather it is the false case where a connection is made between the two channels-- it's not legal to make a simple connection between two channels ("shorting" them out), you must copy from one channel to the other.  So, the false frame should have a loop that reads from the input channel and writes to the output channel.

Another potential problem exists with your design.  The case structure is going to run once at the start of the top level diagram and the behavior will remain fixed throughout the execution of the diagram.  Operating the Average button will not have any effect beyond the first read because it isn't in a loop.

One alternative is to push the case structure inside the the while loop inside the subVI.  The same would need to be done with the Average button, which would then be operated from the subVI's panel.  If you want the Average button to remain on the top-level VI then you could put it in the event structure and whenever it changes you could write to a Tag channel that also gets passed into the subVI.

One thing to keep in mind with your subVI implementation: when you switch averaging back on you will probably want to clear out old state data so you calculate the running average properly.

[Ben]

Thank you Jeff.

I was just playing with the new channel wires to see what I could get away and change my way of thinking to apply to the new Channel wire.

Rumour has it I can propagate the Channel wire via an Action Engine but I have to sneak on that idea carefully.

Edit:

As I mentioned in this thread I think the Channel wires are a great addition and will let me use my top-level to illustrate the architecture of an application such as the following in

image shows.

or this

... and not have to resort to PowerPoint to document that exchange of information.

Ben

[Ben]

Regarding the image I posted above....

The error that LV is flagging with the channel passing in and out of the while loop seems artificial.

Since channel wires do not imply execution order and there are only tow aspects of the channel wire that have any meaning at all namely "where does it start" and "where does it end".

I understand that what I drew is ugly and confusing and I would not normally code it that way.  My point is that the error flagged is contradictory to the nature of the channel itself.

Is there a subtle detail that I am missing?

Full disclosure:

I am just poking at the channel wire now and I need to go through all of the variations. I have a longer term target of converting something that I developed a while go that we call "Named Pipes" that can route message from place to place both across a network or within an application. it is nothing earth shaking and just an extension of he old OSI 7-Layer model and implemented in pure -G. But it would benefit greatly if I could present an easier to understand method to illustrate the logical connections and Channel sure look like a great way to present the nature of the named pipes without all of the details that cloud the view.

Take care,

Ben

[Ben]

Feedback:

The help for channel wire function say the live on a palette somewhere. From what I can tell they do not exist on any palette I found so far.

Ben

[jkodosky]

An earlier implementation based on xnodes had channel endpoints in a palette.  That's no longer the case and the documentation should be updated.

[jkodosky]

>The error that LV is flagging with the channel passing in and out of the while loop seems artificial.

Perhaps.  On the one hand, we didn't want people to make the mistake of thinking they were scheduling dependencies by routing a channel into and out of a structure.  On the other hand, our implementation underneath the channel uses a reference and requires a single "top-level" location where the static reference is inserted.  Allowing a channel to go in and out would greatly complicate the implementation and introduce opportunities for other misinterpretations and ambiguities (e.g., the case structure example where one case has two independent channels and the other case "shorts" them together).

[Ben]

In case you are curious Jeff, I started a thread in the LabVIEW forum that can be found here where I shared what I thought a Producer-Consumer should look like (same as what I showed above).

Judging by the number of Kudos that have been awarded in that thread the Channels and the new look seem to have struck a positive note.

Ben

[Ben]

Some feedback... for what it is worth...

1)

I rearranged things in the Channel Message Handler example as shown below.

The long wires and "bend-abouts" just seems more natural when laid out straight.

2)

I was expounding on the benefits of the Channel wire with a young CLA that teaches the NI LV classes. He has not liked what he has seen and feel they will realty complicate new developers learning LabVIEW because the age-old rule of "Wires imply execution order" now has a caveat "Except for Channel wires".

Expanding what we discussed...

In our shop I have established an standing suggestion that wire come in from the left and out on the right. Avoid Top and Bottom because it is not clear if the wires are an input or an output. So it is few and far between finding wires running up and down.

In our discussion we came to an idea that may help with being able to "read a VI at a glance" goal based on another common practice.

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

Combining those ideas we could establish a basic syntactical rule that Data Flow is left to right and Channel flow is top to bottom.

Re: confusing when data flow controls execution order is contained in the Channel Quiz example that exactly illustrates no data flow implied by channel wires.

But if we run our Channels top to bottom we will have wire bends and offsets between senders and receivers.

IDEA!

Add a right click option to the sender and receivers to allow developers to choose between two type of icon connectors.

A) The current method from a sender comes out the right and the channel is connected on the left for a receiver.

B) Sender channel come out the bottom and Receivers the channel comes in the top.

If that option was available I could have arranged the loops shown in the CMH loop vertically with no bends.

New users could learn that

>data flow is left to right with tunnels.

> Channles flow down (stream) with no tunnels.

Just sharing the thought as I find them.

Ben