More examples or tutorials for Messengers with Ack?

[Blokk]

I am interested to dig deeper into the Messenger channels. Are more tutorials or examples than the ones shipped with LV2017 (for my slow mind I found them a bit minimalistic in explanations)? I am specially interested in how to use the Ack IDs...

By the way, as I understand, Messengers are like Queues, since we can have more than one Writer, but also more than one Reader (Streams can have only 1-1, not to mention the Replicate VI as a special case)? Maybe it is only me, but I could not find additional info via the help about Messengers. For example, do they behave like Queues, so they keep the order of the input msgs? And what happens when we have multiple Readers? We should never use more than one Dequeue (Reader) when we deal with Queues, I guess this problem here is solved using the Ack feature...?

Sorry if these were already discussed in the forum, but I could not find a single place which gives a exhaustive help/explanation about Messengers. So if you could post a link where I find more info, I will really appreciate it! 🙂

(so far I only played with the "simple" Messenger channel nodes, and I only used a single Reader and multiple Writers, to replace a Queue used as a command line between parallel loops; so I really wonder about Messenger scenarios including multiple Readers)

[wired-dan]

Messages do behave like queues and keep the order of the input. If you have multiple readers, once a message is dequeued by one reader, it is removed from the channel and not available to the other readers just like a queue.

In my experience, the ack functions don't behave in the way you would expect an ack to. The functions behave strangely based on what ack ids are read/written (I haven't tried them in 2017 yet). Because of that, I'm personally avoiding them.

What's more interesting to me is the channel message class, which enables some interesting things like merging two messages together (there's a shipping example of that)

[AristosQueue (NI)]

No, there are no further shipping examples in 2017 beyond what shipped in 2016.

There is a bug with the context help for Messengers in 2016 (the text is blank and the "Details" link doesn't work to take you to the full help)... that's fixed in 2017, but in 2016, you can still find help for those functions by searching the help files directly.

A writer says "I am waiting for Ack message ID 10". That writer will never miss the acknowledgement of 10, regardless of the order that the readers send the acknowledgements and regardless of whether the readers send the acknowledgements before or after the writer starts waiting.

[Ben]

I am into something else right now but...

The "ack" is an "ack" of the receipt of the message if I recall correctly.

Also...

Did the sender hang waiting for the ack?

I am still fixing bugs in other developers 2015 code so I have not been able to incorporate the channels yet.

Ben 

[Blokk]

It would be great to see some simple usage scenario with Messengers plus Ack. This particular Channel type still a bit vague to me...

First I thought I can specify an Ack ID at the Write node, then specifying the same ID at the Reader node, I could send messages dedicated to certain loops (modules). But we cannot specify ID at the Write Msg, but we get one just automatically as I understand. Then we need somehow get this ID into the other loop using the Ack channel type? Hmm, I am confused a lot 😄

[AristosQueue (NI)]

Every message sent gets a unique ID in sequence order. At the Read endpoint, one of the terminals gives you the ID of that message. You then use Write Ack to acknowledge that particular message.

The Write endpoint has an ID output so that elsewhere you can use Read Ack to wait for that particular ID to be acknowledged. The Write endpoint has a Wait For Ack Boolean input that, if true, will cause the Write to hang until the message being sent is acknowledged (i.e., it does the Read Ack internally).

[AristosQueue (NI)]

PS: You asked for more examples. I'm assuming you've already seen the example that uses Ack that shipped with 2016?

examples\Channels\Channel Message Handler\Channel Message Handler.lvproj

[wired-dan]

Acks have not worked properly for me since I first tried them. For an example, try this (I'm using 2016):

In the shipping example mentioned above, pressing "Do Something Else" will cause the channel writer in the event structure to wait till ack is received.

In the reading loop, change the case where the message ID is being written to the ack shift register. Instead of wiring from the get message function, wire a U32 constant with any non-zero value.

Create an indicator for the message ID from the get message function so you can see the message IDs on the FP.

Now run the example and see that the channel writer will unblock on any non-zero ack, regardless of the ID of the sent message. You can also see that the channel writer always returns an ID of 0 (which probably means it is accepting any ack, according to documentation for the read ack function)

[Blokk]

---

@wired-dan wrote:

Now run the example and see that the channel writer will unblock on any non-zero ack, regardless of the ID of the sent message. You can also see that the channel writer always returns an ID of 0 (which probably means it is accepting any ack, according to documentation for the read ack function)

---

But isn't it the expected behaviour? Since the channel writer's "Wait for Ack" is not wired, and its default value is False?

Hmm, I will play on with this example, not 100% yet for me 🙂 But this is the "expected behaviour" in my case, over the years I had to learn, I learn slower than average people 😄

Edit: wired-dan: sorry, I opened the first example VI, the second VI (with abort func) has indeed True wired to the Ack input! 🙂

[jkodosky]

Good and Bad news.

The Bad news is that there is a bug in the Messenger channel implementation and we'll get the fix in 2017 SP1.

The Good news is that you can easily fix it yourself right now!

Open the file <resource>/Channels/Messenger/))Channel.vi, open the diagram, and edit the "rdack","rdack2" case to wire the input ack id tunnel across to the output ack id tunnel like this:

What was happening was on the first call the ack id was not found, causing the caller (Endpoint.vi) to wait.  But the returned id was 0, so on the next call it attempted to wait for ack id 0, which is a no-op that returns immediately.