E1.20 RDM (Remote Device Management) Protocol Forums  

Go Back   E1.20 RDM (Remote Device Management) Protocol Forums > RDM Developer Forums > RDM Interpretation Questions

RDM Interpretation Questions Discussion and questions relating to interpreting and understanding the E1.20 RDM Standard.

Reply
 
Thread Tools Search this Thread Display Modes
Old May 24th, 2012   #1
pkleissler
Task Group Member
 
Join Date: Oct 2008
Location: NJ
Posts: 19
Send a message via Skype™ to pkleissler
Default QUEUED_MESSAGE & Status Types

H All,

Have a few questions on queued messages. If the status type is set to error, warning or advisory, should only those types of messages be returned?

In the case of a proxy, should it forward the request to the end device even if it has a response in cue?

How would the proxy know that the queued message in it's cue is or is not one of those types?

Section 10.3.1 says to use type of GET_LAST_MESSAGE to retrieve the last queued message, but I believe that pertains to the controller already receiving it and wants it again. This same section also gives an example, but it uses the type ERROR, to retrieve a queued DMX address message, hardly an error.

I have seen one controller use GET_LAST_MESSAGE and another use ADVISORY. So far both work, only because my proxy does not check and returns the message in its cue if there is one.

Thoughts?

Paul
pkleissler is offline   Reply With Quote
Old May 24th, 2012   #2
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 353
Default

Quote:
Originally Posted by pkleissler View Post
Have a few questions on queued messages. If the status type is set to error, warning or advisory, should only those types of messages be returned?
Status Type only applies to Status Messages. Normal PIDs don't really have a Status Type associated with them.

The GET QUEUED_MESSAGE PID is unusual in that the responder can respond with a STATUS_MESSAGE response if there are no queued messages to send.

The "Status Type" field of a GET QUEUED_MESSAGE only applies in the case when the responder is sending status messages. If there is a queued message, the responder should send that instead regardless of the Status Type requested.

Quote:
Originally Posted by pkleissler View Post
In the case of a proxy, should it forward the request to the end device even if it has a response in cue?
No, a proxy does not have to always forward the request to the end responder. If the proxy has a queued message in memory, it can respond with that message on behalf of the end device.

Quote:
Originally Posted by pkleissler View Post
How would the proxy know that the queued message in it's cue is or is not one of those types?
Normal PIDs don't have a Status Type associated with them. The proxy can just pass them along to the controller in the order they were received from the responder. They don't even have to be in order, the proxy could rearrange the queued messages if it wanted to (although I'm not sure why you would do this).

The Status Type only matters for Status Messages. The packed structure returned in a STATUS_MESSAGES response has the Status Type contained within the data structure, so the proxy can look at the data and determine which status messages to return.

In general, I feel that a proxy should only collect status messages when asked by the controller. A proxy could collect status messages from its responders independently, and them pass them along to the controller when required. But then you run the risk of the proxy having to hold the status message indefinitely if the controller never asks for it, and you risk the possibility that the data may go out of date while it's sitting in memory.

If the proxy does collect status messages independently and buffer them until requested by the controller, it must be able to re-pack status messages dynamically. For example, the proxy is constantly collecting Advisory messages in the background, so it builds up a list of Advisory, Warning, and Error statuses in memory. When the controller requests Errors, the proxy will pull only the Status Type ERROR and ERROR_CLEARED from memory.

In general, the proxy should *not* reorder status messages, especially STATUS and STATUS_CLEARED. Receiving a "Dimmer on Fire" followed by "Dimmer on Fire Cleared" is very different then "Dimmer on Fire Cleared" followed by "Dimmer on Fire" (There's probably an Advisory Halon System Low message in there too).

Quote:
Originally Posted by pkleissler View Post
Section 10.3.1 says to use type of GET_LAST_MESSAGE to retrieve the last queued message, but I believe that pertains to the controller already receiving it and wants it again. This same section also gives an example, but it uses the type ERROR, to retrieve a queued DMX address message, hardly an error.
GET_LAST_MESSAGE is used when there is a dropped or corrupt response to ensure that status and queued message don't get lost. The DMX address response is appropriate because it's a Queued Message and not a Status Message. Status Type Error only applies if the proxy and/or responder is sending Status Messages.
ericthegeek is offline   Reply With Quote
Old May 24th, 2012   #3
pkleissler
Task Group Member
 
Join Date: Oct 2008
Location: NJ
Posts: 19
Send a message via Skype™ to pkleissler
Default

Thanks Eric,

To confirm, the status type in the Get QUEUED_MESSAGE only applies when the responder has no queued message to send, in which case it would send a status message reply response. This response should then follow table 10.1 for the type requested in the GET.

Paul
pkleissler is offline   Reply With Quote
Old May 24th, 2012   #4
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 353
Default

Correct, that matches my interpretation.
ericthegeek is offline   Reply With Quote
Old May 24th, 2012   #5
sblair
Administrator
 
Join Date: Feb 2006
Posts: 413
Send a message via AIM to sblair Send a message via MSN to sblair
Default

Everything that has been said so far matches with my interpretations and our intent when writing it.
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote
Old January 24th, 2014   #6
zano_villa
Junior Member
 
Join Date: Jan 2014
Location: Treviso, Italy
Posts: 11
Default Queued messages responses with Message Count = 0

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
zano_villa is offline   Reply With Quote
Old January 25th, 2014   #7
sblair
Administrator
 
Join Date: Feb 2006
Posts: 413
Send a message via AIM to sblair Send a message via MSN to sblair
Default

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
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote
Old January 27th, 2014   #8
nomis52
Task Group Member
 
Join Date: May 2010
Location: San Franciscio
Posts: 57
Default

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
nomis52 is offline   Reply With Quote
Old January 28th, 2014   #9
zano_villa
Junior Member
 
Join Date: Jan 2014
Location: Treviso, Italy
Posts: 11
Default About queued messages

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

Last edited by zano_villa; January 28th, 2014 at 07:57 AM. Reason: Best explanation
zano_villa is offline   Reply With Quote
Old January 28th, 2014   #10
nomis52
Task Group Member
 
Join Date: May 2010
Location: San Franciscio
Posts: 57
Default

Quote:
Originally Posted by zano_villa View Post
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
nomis52 is offline   Reply With Quote
Old January 28th, 2014   #11
sblair
Administrator
 
Join Date: Feb 2006
Posts: 413
Send a message via AIM to sblair Send a message via MSN to sblair
Default

Zano,

Can you explain the purpose and use of the DMX status advisory message? I'd like to understand it better to see if maybe there is a better solution we can propose.

Simon is correct in that once the messages are collected, they are purged and the message count = 0, UNLESS the condition occurs again and then a new status message gets queued up. One could implement a sensor that generates a status message every time the temperature changes by 1/10th of a degree, but in most situations that would just be viewed as noise and waste the network bandwidth.

At least as an advisory a controller can choose to not collect it, but it would be useful to understand your use case.

Thanks.
Scott
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote
Old January 29th, 2014   #12
zano_villa
Junior Member
 
Join Date: Jan 2014
Location: Treviso, Italy
Posts: 11
Default Issue resolved

Hello,

Actually the issue is resolved if status messages are asserted ONLY when the condition occurs and then, once the message is collected by the controller, the responder no longer has the message.

So STATUS MESSAGE is not generated as a result of a GET_QUEUED_MESSAGE or STATUS_MESSAGE request, but it's generated when the condition occurs and then queued, waiting for a controller request, and purged after been sent. Therefore it's in effect a queued message.

Is this a correct interpretation?

As further explanation I would ask if it is correct to write the last 2 indents of page 50 of the standard applied to QUEUED MESSAGES, namely:

"The responder shall maintain reported QUEUE information until it has been successfully delivered to the controller. QUEUED MESSAGE is considered successfully delivered when the responder receives a Status Type Requested other than STATUS_GET_LAST_MESSAGE.
The previously delivered QUEUED messages shall be cleared from the reporting queue once they have been successfully delivered to the Controller."

And a last question, please: if I have an queued ADVISORY status message and controller ask me for a ERROR type (so I respond with PDL of 0), shall I consider the status message sent?

Probably 10.3 chapter of the standard is the most unclear!

Thank you very much for your regard and accuracy in answers.

Zano_villa

Last edited by zano_villa; January 29th, 2014 at 05:46 AM.
zano_villa is offline   Reply With Quote
Old January 29th, 2014   #13
sblair
Administrator
 
Join Date: Feb 2006
Posts: 413
Send a message via AIM to sblair Send a message via MSN to sblair
Default

Quote:
Originally Posted by zano_villa View Post
Hello,

Actually the issue is resolved if status messages are asserted ONLY when the condition occurs and then, once the message is collected by the controller, the responder no longer has the message.

So STATUS MESSAGE is not generated as a result of a GET_QUEUED_MESSAGE or STATUS_MESSAGE request, but it's generated when the condition occurs and then queued, waiting for a controller request, and purged after been sent. Therefore it's in effect a queued message.

Is this a correct interpretation?
Yes. It is not technically called a "queued message" because that term has other specific meanings, but yes you generally keep some type of internal queue for status message events as they occur so that you can report them later when requested.

Quote:
Originally Posted by zano_villa View Post
As further explanation I would ask if it is correct to write the last 2 indents of page 50 of the standard applied to QUEUED MESSAGES, namely:

"The responder shall maintain reported QUEUE information until it has been successfully delivered to the controller. QUEUED MESSAGE is considered successfully delivered when the responder receives a Status Type Requested other than STATUS_GET_LAST_MESSAGE.
The previously delivered QUEUED messages shall be cleared from the reporting queue once they have been successfully delivered to the Controller."
If the message being returned back as part of a QUEUED_MESSAGE is a STATUS_MESSAGE then yes that still applies. The device needs to cache the status of the previous status message so it can resend if a STATUS_GET_LAST_MESSAGE is sent. It's basically there to cover the case of a lost response.


Quote:
Originally Posted by zano_villa View Post
And a last question, please: if I have an queued ADVISORY status message and controller ask me for a ERROR type (so I respond with PDL of 0), shall I consider the status message sent?

Probably 10.3 chapter of the standard is the most unclear!

Thank you very much for your regard and accuracy in answers.

Zano_villa
In that case I would not consider the status message sent because it was never actually collected. A reasonable controller implementation might frequently poll for higher priority status messages but only infrequently request Advisory level messages. In your implementation that could cause them to frequently get trashed before they were requested.

10.3 is a complicated section with lots of possible corner cases that you can see have been discussed on here previously. Your questions help as we go back and review these when we do revisions to the standard in order to clarify more and remove ambiguity.
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote
Reply

Bookmarks

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
RDM & DMX frames multiplexing DavidR RDM General Implementation Discussion 2 November 20th, 2010 04:10 AM
QUEUED_MESSAGE - ? berntd RDM General Implementation Discussion 9 November 24th, 2009 08:48 AM
capture & playback preset chris RDM General Implementation Discussion 1 August 4th, 2009 05:45 PM
Personality & Subdevices kocurr RDM General Implementation Discussion 1 July 8th, 2008 09:30 PM


All times are GMT -6. The time now is 04:56 AM.


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