LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

messenger channel wire behavior

Solved!
Go to solution
Highlighted

Hi All,

I'm just starting to use channel wires and was hoping to use them in projects. I've attached a very simple sample to use the multiple writer/reader capabilities that messenger channels were supposed to embody. If you run the VI, however, you'll notice that with this config (no acknowledgement, all terminals default values) the read instance that actually receives the change alternates between the two loops since, I guess, a messenger is after all a lossy buffer. I would have expected the data written in the event loop to be received at all read instances in light of the advertisement of messengers being a 'many-to-many communications channel'. 

If the messenger is replaced with a tag channel, however, it does operate as expected, ie, each loop will see the changed value from the event loop, which is the way I want to eventually use it. The drawback here, though, is that continuous
reads (polling) are performed at the frequency specified by the timeout value. I guess I've misinterpreted the 'many-to-many' description of messenger channels in that single writer/multiple reader applications will not have simultaneous loop data refreshes. Can anyone please shed more light on this? Thanks in advance,

lb

 

0 Kudos
Message 1 of 22
(1,840 Views)
Highlighted

I've used Message Channels a lot, but my only "safe" installation of LabVIEW 2017 is on a VM at work (installing LabVIEW 2017 on two of my machines "afforded me the opportunity" to reformat the C: drive and reinstall everything, except, of course, LabVIEW 2017 ...).  I'll fire the VM up tomorrow morning ...

 

Bob Schor

0 Kudos
Message 2 of 22
(1,795 Views)
Highlighted

Ok Bob, would appreciate it.

0 Kudos
Message 3 of 22
(1,781 Views)
Highlighted

I use a lot Tags and Streams in my projects, Tags for lossy "Notifier-like" data broadcast (one to many), Streams for lossless "Queue-like" data/command sending (one to one). (edit: or many to one)

 

I did not start to use so far Messenger channels, but I started to play with your VI, and I will write again when I get some news.

(I have LV 2017 32bit.)

 

Edit: actually I always thought that Messenger channels are many-to-many lossless communication options, but it looks like it is not the case?? I keep testing, and searching some older posts in the Channel forum board...

 

Edit2: There is an example here: c:\Program Files (x86)\National Instruments\LabVIEW 2017\examples\Channels\Channel Message Handler\

It has some operations with Messenger channel, and using the ID. My problem is that this example is a bit too complicated to really play with Messenger channel and understand it better. Also, there is only one Messenger reader, so this example is not really useful for us 😞

 

Edit3: and the corresponding white paper is a bit "dumb", it says the Messenger channel is a many-to-many communication, and then shows a two-to-one example 😄 http://www.ni.com/white-paper/53423/en/

0 Kudos
Message 4 of 22
(1,777 Views)
Highlighted

I think we got mislead by the naming "many-to-many". This is a lossless communication, but if you have multiple Messenger readers, one of them will take a msg, so it is lost for the other Reader nodes, as I understand at this point...?

Read also this: https://forums.ni.com/t5/LabVIEW-Channel-Wires/Questions-Comments-about-Messenger-Channel/gpm-p/3455...

 

Actually what I would like this channel type "to be", is like a lossless Tag channel: so i can send a Msg from multiple sources, and read the message either at ALL reader nodes, or only at the specified ones. This would be very useful, using a single Channel wire to have a real lossless Many-to-many communication!

 

Some time ago when I first had a look at the Messenger channels, I really thought the "ID" value is something like a label. So I could specify an ID at the Write side, and only read the Msg at those Reader nodes, where I use the very same ID. This would make sense.

 

I try to understand what is behind the current Messenger channel behavior, but it does not make too much sense to me...what I describe above, would make more sense... (and I know, I could program and wrap up channels to mimic what I describe above, but this is the point using channels: already prepared functionality without further programming...)

 

edit: and to have our life even more complicated, there are existing bug(s) with Channels, read this: https://forums.ni.com/t5/LabVIEW/Messenger-Channel-Wire-ack-read-write-behavior/m-p/3702724/highligh...

0 Kudos
Message 5 of 22
(1,765 Views)
Highlighted

OK, I see the problem -- you are designing a Producer/Consumer system, but instead of having a single Consumer that decides "What did I get, and how do I consume it", you have multiple Consumers who squabble over the crumbs.

 

Here is a Very Simple Consumer/Producer of "Messages", where the "Message" is just a String ("Command").  Note that there is also something called a Queued Message Handler, where the Message is a Cluster having the "Command" part and a "Data" part -- I've coined (for myself, feel free to "borrow" the term "Channel Message Handler" where Channels replace Queues.

 

One trick with Channels is that they appear to "break" the "Input on Left, Output on Right, Parallel Loops arranged vertically (suggesting "simultaneity")" Rule, but you'll see how I deal with this.  I'm attaching this as a LabVIEW 2016 Snippet and VI so you'll be able to use it with 2017, but those (like myself) who use LabVIEW 2016 can also "play".

 

Very Simple CMH.png

The Message Producer is a simple Event Structure that every time a Message is entered, it is put on a Messenger Channel.  If the Message happens to be "Exit", it exits the loop (and the Message Handler Loop, below it.

 

The Message Handler gets the Message through an S-shaped Channel that goes down, turns left, goes to the beginning of the Message Handler Loop, and goes in to a Channel Reader.  The Message is displayed and then acted upon using a Case Structure, one Case per Legal Message.  Any "unexpected" Messages (I used "Hello") go to the Default Case that warns of the Unexpected Message, and then generates its own Message, namely "Error".  Since this is a Messenger Channel, I take it out the right side, up, and join it to the Channel coming from the Event Structure, thus allowing the Message Handler to send Messages to itself.  It's not shown here, but what the Error Case does is simply use the Value Signaling Property of Message to send an Exit Message, stopping the Event Loop, and in the Message Handler, the Exit Case also stops the Message Handler.  Finally, there is a Valid Message ("Valid") that is the remaining Case for the Message Handler -- it does nothing, in fact, but if you run the routine and type "Valid", you'll see "Valid" appear in the Msg Indicator.

 

This is an exceedingly simple demo (believe me, I have more complicated CMH routines), but I hope is illustrates the idea(s) of Messenger Channels.  I use them a lot (more than any other Channel Wire so far).

 

Bob Schor

0 Kudos
Message 6 of 22
(1,755 Views)
Highlighted

I would like to show you an alternative to Messenger channels. I really like to use Dynamic User Events, and we also got Channel types (Event Messenger Channels) to make programming faster with these useful things!

Note that, I have here in one block diagram 3 Event Structures which is usually not a good idea, so this is only for demonstration purpose!

In my real applications those other Event Structure loops at the right are either inside parallel running subVIs, or in dynamically called VIs (like callable modules which register for Events fired from the Main-vi.

 

Because you can branch this Channel wire, you can register all Event Structures for these Events, and you can make a kind of label so you will know what is the target loop of the actual msg...

You can extend this example in a way that you can send msgs back to the main Event Structure from any of the "subVIs" or sending msgs between the subVIs.

 

Event_Channel.png

 

 

0 Kudos
Message 7 of 22
(1,754 Views)
Highlighted

Thanks Blokk,

That was a lot of information! So it sounds like channel wires, especially messengers, are a work in progress. So if I understand correctly, you could assign IDs to the messages, and with a do loop, send the same message to each reader using different IDs? Hmmm...I'll give it a try and report back. Thanks again for your help.

lb

0 Kudos
Message 8 of 22
(1,750 Views)
Highlighted

"This is an exceedingly simple demo (believe me, I have more complicated CMH routines), but I hope is illustrates the idea(s) of Messenger Channels.  I use them a lot (more than any other Channel Wire so far)."

 

Bob, your example VI is nice and works as you explained. But IMHO the OP does want two separate consumer loops. He thought (me too) that the "many-to-many" expression means we can have multiple writers (as in your example), but also multiple Readers! In your example you read the Channel at a SINGLE place!

0 Kudos
Message 9 of 22
(1,750 Views)
Highlighted

@lebecker wrote:

Thanks Blokk,

That was a lot of information! So it sounds like channel wires, especially messengers, are a work in progress. So if I understand correctly, you could assign IDs to the messages, and with a do loop, send the same message to each reader using different IDs? Hmmm...I'll give it a try and report back. Thanks again for your help.

lb


No! This is what I thought in the past. But the acknowledge IDs are working in a totally different way. So you cannot "label" msgs to target only a single Reader node. This was just my original wish 🙂

I would like a new Channel type, we could call it "Targeted Messenger Channel", where you can specify a target ID, and only those Channel Readers would get these msgs which has this particular ID specified (even during runtime).

 

If you have a look at my Event Messenger example above, the real problem with that is EVERY Event structure will react for all sent msgs. Yes, we can ignore msgs not to be handled in the actual loop using a cluster, but this is not too elegant. A "Targeted Messenger Channel" would be much more awesome! 🙂

0 Kudos
Message 10 of 22
(1,748 Views)