E1.20 RDM (Remote Device Management) Protocol Forums

E1.20 RDM (Remote Device Management) Protocol Forums (http://www.rdmprotocol.org/forums/index.php)
-   RDM Interpretation Questions (http://www.rdmprotocol.org/forums/forumdisplay.php?f=5)
-   -   Response to GET:QUEUED MESSAGE when NACKing query (http://www.rdmprotocol.org/forums/showthread.php?t=1245)

prwatE120 February 24th, 2016 02:17 PM

Response to GET:QUEUED MESSAGE when NACKing query
If a controller sends a GET:QM to a responder, what PID should appear in the responders reply when the responder is NACKing the query?

Reasons for the NACK might be Format Error, Data out of Range etc.

ericthegeek February 24th, 2016 04:07 PM

I ran into this when I was implementing queued messages also.

My conclusion is that if you are NACK'ing the GET QM, then you should have the QM PID in the response.

If the controller sees another PID in the response (say IDENTIFY_DEVICE), then it will assume that it just retrieved a queued NACK for an Identify that it sent in the past, rather than realizing that it's actually a NACK for the GET QM.

A controller probably should accept STATUS_MESSAGES in the PID also, although in my implementation I only put the STATUS_MESSAGES PID in the response when I'm ACK'ing a GET:QM.

sblair February 24th, 2016 04:53 PM

Agree with Eric here. The only logical thing to respond in the NACK with is QM.

prwatE120 February 24th, 2016 05:33 PM

I have also coded along the lines that Eric has, and reply with QM as the PID in the NACK.

We might all think it is logical, but it is not defined behaviour as per the E1.20 document, which states the response to a QM shall be a STATUS_MESSAGE response.

10.3.1 "A responder with no messages queued shall respond to a QUEUED_MESSAGE message with a STATUS_MESSAGES response. "

Where do we state that this does not apply to a NACK from a responder with no messages queued ?

Are we happy to allow either PID in NACK responses, and add this behaviour to an E1.20 erratta ?

All times are GMT -6. The time now is 10:28 AM.

Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2021, vBulletin Solutions, Inc.