QUEUED_MESSAGE & Status Types

[zano_villa]

Hello,

I need an explanation, please.

Point 10.3.1. of the standard seems to state that a receiver must always respond with a STATUS MESSAGE with PDL = 0 when it receives a GET QUEUED MESSAGE with no messages pending (MESSAGE COUNT = 0)

But this seems to be an incorrect interpretation.

In fact if I don't support GET_STATUS_MESSAGES, then I MUST respond with a
STATUS_MESSAGE with PDL of 0x00 (I must respond in this way even if I don't
support STATUS MESSAGES PID and this does not imply a STATUS MESSAGES
support as it is reported in the text)

But If I support GET_STATUS_MESSAGES, then I must respond with a STATUS
MESSAGE with STATUS TYPE requested.

A STATUS MESSAGE response with PDL = 0 doesn't mean that there are no
messages pending, this information simply is supplied by MESSAGE COUNT = 0.

Am I right?

Thank you

[sblair]

Zano,

I believe you have most everything correct.

If there are no Queued Messages (Message Count = 0) then you must respond to the GET:QUEUED_MESSAGES with a STATUS_MESSAGES response. If you don't support status messages then you would still respond with that PID, but with a PDL of 0x00. This is the same response that would go back if you did support Status Messages, but just didn't have any to report.

If you do support Status Messages, then you would use Table 10-1 to determine what Status Messages to return based on the Status Type Requested.

Let me know if there's still any questions here or if I missed something.

Thanks.
Scott

[nomis52]

This is how I would implement a responder. On receiving a GET QUEUED_MESSAGE:

- if the requested status type is STATUS_GET_LAST_MESSAGE, return the same response as last time.
- otherwise, if there are queued messages, decrement the pending message count and return the most urgent one
- otherwise, if there are status messages at or above the requested level (see table 10-1) that have not been collected, return one or more status messages.
- otherwise return a status message response with a PDL of 0

It's important that a controller be able to send GET QUEUED_MESSAGE and eventually receive an empty status message response. This tells the controller it's up-to-date.

How many times to try this depends on the number of proxies on the line and the number of status messages that are pending on the responder. The RDM tests try up to 25 times to get an empty status message response.

Simon

[zano_villa]

The issue is the third line:

- otherwise, if there are status messages at or above the requested level (see table 10-1) that have not been collected, return one or more status messages.

In my implementation I have DMX status situation regarded as an ADVISORY STATUS and it is always present. So, if I have not pending messages, and I still receive GET_QUEUED_MESSAGEs with ADVISORY_STATUS, must I send it only once and then return a status message response with PDL of 0 ?

I don't think so.

Thank you

Zano_villa

[nomis52]

Originally Posted by zano_villa

The issue is the third line:

- otherwise, if there are status messages at or above the requested level (see table 10-1) that have not been collected, return one or more status messages.

In my implementation I have DMX status situation regarded as an ADVISORY STATUS and it is always present. So, if I have not pending messages, and I still receive GET_QUEUED_MESSAGEs with ADVISORY_STATUS, must I send it only once and then return a status message response with PDL of 0 ?

I don't think so.

My interpretation (and from all but one device with the gear I've tested with) is that status messages are asserted when the condition occurs and then, once the message is collected by the controller, the responder no longer has the message. Therefore always returning an advisory status message breaks this model. It effectively tells the controller "I always have this condition and there is nothing you can do to clear it".

When we reopen E1.20 I'll be pushing to clarify this behavior.

In E1.33 always returning an advisory message may generate a lot of traffic on the device -> controller and controller to controller links. This is another reason why it should be avoided.

Simon