LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Messenger Channel Wire ack read/write behavior

Solved!
Go to solution

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.

ack_img.png

Some cases:

  1. 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"
  2. no ack written, read value != 0:
    • timeout on first pass. expected behavior
  3. ack write = <anything>, read value = 0
    • read always returns w/o timeout
    • this might be said to match the docs, not sure
  4. 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
  5. 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 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.

 

Thanks!

 

Download All
0 Kudos
Message 1 of 10
(2,947 Views)

Turn on execution highlighting to see what's happening.

 

The code does exactly what I would expect, but doesn't make much sense. Could you describe what you are trying to achieve?

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

 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?

0 Kudos
Message 3 of 10
(2,897 Views)

I'll have a closer look tomorrow. Might have run to conclusions... But AFAIK, the channel wires are basically queues with a wrapper, so I'm sure it can all be explained.

0 Kudos
Message 4 of 10
(2,876 Views)

AdamZeroK wrote:

 

Some cases:

  1. 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"
  2. no ack written, read value != 0:
    • timeout on first pass. expected behavior
  3. ack write = <anything>, read value = 0
    • read always returns w/o timeout
    • this might be said to match the docs, not sure
  4. 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
  5. 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.

ack_tmp2.png

 

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.

 

0 Kudos
Message 5 of 10
(2,840 Views)

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)

case4.png

 

 

5) Doesn't timeout first two times.  (you said it returns immediately only only first pass, which is what I would expect is proper)

case5.png

0 Kudos
Message 6 of 10
(2,822 Views)

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 ...

 

Bob Schor

0 Kudos
Message 7 of 10
(2,809 Views)

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.

 

generate random ack reads and writesgenerate random ack reads and writesack read id's are irrelevant (if not 0)ack read id's are irrelevant (if not 0)ack read w/ 0 is a no-opack read w/ 0 is a no-op

More elaborate BD with background message passing.  (outcome is the same)

random_acks_w_messages.png

0 Kudos
Message 8 of 10
(2,786 Views)

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.

0 Kudos
Message 9 of 10
(2,775 Views)
Solution
Accepted by topic author AdamZeroK

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.

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