LabVIEW Channel Wires

cancel
Showing results for 
Search instead for 
Did you mean: 

Questions/Comments about Messenger Channel

I decided to experiment with the messenger channel and it brought up some questions/comments. 

1. I like the idea of the abort feature, but it didn't work the way I originally thought it would. When I set the abort input to true on the Write with Abort the element that is read is the default value and not the value that was wrote. For example if I write "hello" the string "" is read. I dug into the code and it looks like if the abort is true then a default value is sent. I guess that the decision was made that if abort occurs then the normal value should not be returned. But I see some value in being able to process the normal message especially if that is a clean up message after the abort occurred. Also I couldn't find the behavior described in the documentation so it would be nice to have it documented if it isn't already.

2. I also noticed that you can't create another Write VI by right clicking on an existing channel wire.  It seems like there should be an easier way to copy the write without having to copy and paste. This is especially important if you have multiple cases where you are writing to the channel wire like a producer/consumer type architecture. I tried to right click the same element and create another Channel write, but when I wired it up to same channel wire, LabVIEW crashed.

3. I like the idea of having an Ack, but I didn't find it intuitive that to assert the ack you have to set the ack id on the next read. I was assuming there would be a separate assert ack function. It seems like I should be able to assert the ack right after the code where I processed it and not have to perform another read.  Is there any plans to create a separate function to assert the ack?  I figured it out by studying an example program for a while. I would recommend adding documentation to explain this behavior.  It might already be documented somewhere and I just couldn't find it.

4. When the Channel Writer is created it says that it is for many to many communications. What does this mean exactly?  I thought that it meant you could have multiple writers and readers at the same time.  I created a VI where I had one writer and multiple readers, but only one of the readers got the message.

5. I like the idea of the probes, but it seems like for the messenger channel the messages happen so quickly I can't really see what occurred. Is there anyway to see the history of what messages were sent using the probes?

Director of Engineering
G Systems, www.gsystems.com
Certified LabVIEW Architect
Certified LabVIEW Embedded Systems Developer
Certified Professional Instructor
GCentral
0 Kudos
Message 1 of 10
(10,563 Views)

2.  There are only two ways to create a Channel Writer (that I know about) -- right-click on an existing Wire or Connection and chose "Create Channel Writer" or copy-and-paste an existing Channel Writer (it doesn't have to be the same type -- you can wire something else to its input and right-click tell it to Adapt to Element Type).

4.  I believe "Many-to-Many" refers to the branching of the Channel.  Note that (for the most part) a Stream Channel has no branches.  With a Messenger, you can have branches that feature multiple inputs and also multiple outputs (hence "Many-to-Many").  However, the contents of the Channel are not duplicated, so if you have 5 readers, the Channel holds 5 elements, and each Reader takes a little time to process the data, each Reader will probably process one element ("in the order received"), after which the Channel will be empty.

I haven't specifically "played with" the other topics mentioned in your Post.  However, I really like the new Channels (and am busy incorporating them into my code).

Bob Schor

0 Kudos
Message 2 of 10
(10,082 Views)

Thanks Bob Schor for the response. I find the channel wires really interesting and am currently just exploring them to see how I could use them in my code as well.  I would be curious to hear more about your experiences and how you are using them in your code.  Hopefully others will share their experiences as well and shine some more light on the topics I mentioned.

Director of Engineering
G Systems, www.gsystems.com
Certified LabVIEW Architect
Certified LabVIEW Embedded Systems Developer
Certified Professional Instructor
GCentral
0 Kudos
Message 3 of 10
(10,082 Views)

The high speed stream channel can branch!  This is important since you can take a data source and branch it to display, storage, network streams etc.  I am not sure (in that I haven't implemented it) but you can pass the channel to a sub-VI that is dynamically launched.

There are all sorts of possibilities here that are graphically easy to understand but actually have a tremendous underlying complexity.

LabVIEW ChampionLabVIEW Channel Wires

0 Kudos
Message 4 of 10
(10,082 Views)

That's a serious bug that we will fix ASAP.

0 Kudos
Message 5 of 10
(10,082 Views)

I checked this morning. The HS Stream cannot fork. Sth, what are you talking about?

Untitled.png

0 Kudos
Message 6 of 10
(10,082 Views)

Maybe I am just nuts....  I remember there was an issue in LV 2015 and I couldn't fork the channel, but in 2016 I just righ click on the channel and ask it to make a branch.  I certainly don't want to contradict the expert here, but I did the obvious naive thing.

LV 2016 fresh install and what toolkits there are for Mac OS X.  No Red X's!

(just a thought while typing maybe I need to delete my LabVIEW Data Folder from the beta?)

Branching HS Stream.png

LabVIEW ChampionLabVIEW Channel Wires

0 Kudos
Message 7 of 10
(10,082 Views)

You are right.  The VI is broken.  I assumed it was broken because I didn't have the stop loops wired.  But it tells me that the channel cannot fork in the errors.

Seems to be a bug in that the channel does not display as "broken".  I don't display red Xs on broken wires since they are usually dotted and obvious.  In this case the channel core looks fine and should be "dotted"?

LabVIEW ChampionLabVIEW Channel Wires

0 Kudos
Message 8 of 10
(10,082 Views)

Definitely shouldn't be dotted --- there's nothing problematic with the type or with the nodes accepting the wire. But I can see the value in adding the red X to the wire.

0 Kudos
Message 9 of 10
(10,082 Views)

Well there is a syntax error at the fork.  As I said, I disable the 'red x" option since I find it redundant and it sometimes obscures things around it.  In all other cases that I can think of there is an additional visual indicator that there is a syntax error.  In this case if I disable the red X, then there is no indication at all.  The problem is at the branch in the wire.  For regular data flow wires it makes the entire wire invalid if there is a bad connection (or two sources etc.).  So even though there is no problem with the nodes at the end of the wires, the wire itself is the indicator that you did something wrong.

LabVIEW ChampionLabVIEW Channel Wires

0 Kudos
Message 10 of 10
(10,082 Views)