I am trying to understand the behavior of the read/write ack nodes for Messenger channels. A simple example follows. In it I have a Messenger wire. No message are written to it. It is only used by ack read and ack write nodes. The behavior of the 'read Ack' node is not what I am expecting from the documentation.
I didn't find any bundled examples that use these nodes so I am now a bit lost on how to figure out if what I'm seeing is expected behavior.
I attached LV2017 and LV2016 vi's of the code snippet if you want to try it yourself.
Solved! Go to Solution.
Execution highlighting shows exactly what I say in the case descriptions.
My aim is to construct the simplest possible example that will allow me to see when the read ack node will and will not block, depending on what acks have been written.
How does it do what you expect? E.g.: In my 'case 1' the Read Ack doesn't block even if no acks are ever written to the channel! How can this be correct?
- no ack written, read value=0 :
- read always returns w/o timeout. Not what I expected from the help file which says: "The default is 0, which means the endpoint waits for any message to be acknowledged"
- no ack written, read value != 0:
- timeout on first pass. expected behavior
- ack write = <anything>, read value = 0
- read always returns w/o timeout
- this might be said to match the docs, not sure
- ack write = <anything>, read value = <anything except value written, and !=0>
- first read always doesn't time out, second always times out
- Not what I expected. I expected 1st read to fail since write/read id's don't match
- ack write = ack read != 0
- read returns w/o timeout twice, always times out on third call
- unexpected behavior. I expected the read to either complete once and not a second time or repeatedly (can't tell from docs).
I changed the test setup a bit, yours is a bit too confusing for me.
1) In this situation, it seems the reader simply returns immediately (since the message channel is not initialised?). The default channel to wait for is 0, but since it's not initialised, it will just stop waiting... Might not be expected, an error out would be useful.
2) I get a timeout on all passes. As expected.
3) There is a message, so it stops waiting, no timeout. As expected.
4) I get a timeout on any pass. Since the request ID was not send, as expected.
5) Returns immediately the first pass, timeout after that. As Expected.
So the Read Ack will wait for a time out period for the requested message, if the request message is 0, it will stop waiting (but doesn't clear the message). If the message channel has no writer, it stops.
Thanks for taking a look.
Putting aside cases 1-3 for now, I am not getting the results you describe on my end for cases 4-5, using the same block diagram.
What LV version are you running? I get the results below on two different machines. Both running LV 2017 x64.
4) Mine does not timeout on 1st pass, will on subsequent. (you said it yours times out on 1st pass, which is what I would think is proper behavior)
5) Doesn't timeout first two times. (you said it returns immediately only only first pass, which is what I would expect is proper)
Wow! I (foolishly) thought I knew and understood Channel Wires, particularly Messenger Channels (which I use all the time). However, I've never tried using Ack, and really don't understand it! Something (more) to learn ...
Yeah, either I am missing entirely the way this is supposed to work or the ack part of the framework is busted. Really doubt NI would release something completely broken though. Does anyone use this?
Only conclusions I have as of now:
1) ack read with id=0 is a no-op. Regardless of whether 0 acks, a 100 acks are written, ack read will always return immediately
2) ack read doesn't care what the ID of the message is. So long as there are as many acks written as read calls the read will never block.
Some additional screenshots below. Also can confirm it isn't some initialization issue, I can pass normal message around fine in parallel with test like above and the outcome is the same. Some screenshots follow.
More elaborate BD with background message passing. (outcome is the same)
You're not missing anything (except maybe a newer version of LabVIEW than you have right now).
The original example, and my spin-off example, do have the bug that you described in LabVIEW 2017SP0. So, it's a bug. It's supposed to work as you expect, but it doesn't.
Confirmed by NI. Form the email they sent me:
I wanted to thank you for bringing this to our attention, and after our conversation I did some digging and was able to find that this is a known issue. We have a Corrective Action Request (CAR) already open concerning this issue and it looks likely to be solved in the next upgrade of LabVIEW 2017.
No fix ATM.