E1.20 RDM (Remote Device Management) Protocol Forums  

Go Back   E1.20 RDM (Remote Device Management) Protocol Forums > RDM Developer Forums > RDM General Implementation Discussion

RDM General Implementation Discussion General Discussion and questions relating to implementing RDM in a product.

Reply
 
Thread Tools Search this Thread Display Modes
Old September 1st, 2011   #1
eldoMS
Junior Member
 
Join Date: Aug 2011
Posts: 8
Default Detailed questions on STATUS_MESSAGES

Hi

I have a question with regards to properly implementing and interpreting GET STATUS_MESSAGES.

I understand from the RDM2006 errata that there can be two types of RDM protocol support: either supporting or not supporting Status Type _CLEARED responses.

From a responder point of view, when I have a malfunction of some sort, e.g. a too low bus voltage or a too high temperature I can report this in a GET STATUS_MESSAGES reply with message(s) of a certain type and data values.

Several questions I have then from a responder viewpoint:
- how do I know _CLEARED is supported in the controller, or are most controllers already on that level? A controller without the support just ignores gracefully?
- do I only report once a certain failure (when it arises)? Or consistently with each STATUS_MESSAGE when _CLEARED is not supported? And if I need to report it consistently, how often?
- in the case of _CLEARED I only report ONCE that a certain condition was cleared?
- the PID CLEAR_STATUS_ID, what does it exactly do in this case? Is it a reset of the condition, that in a sticky example immediately comes again with a voltage or temp error and there will be another reporting of this in the next STATUS_MESSAGES (one time only?). Is this the controllers method to clear conditions and create a fresh list? How often could a controller do this? The _CLEARED method is used to remove a warning/error from the controller as soon as it is cleared instead of going via CLEAR_STATUS_ID?

Thanx

Marc
eldoMS is offline   Reply With Quote
Old September 1st, 2011   #2
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 358
Default

Quote:
Originally Posted by eldoMS View Post
- how do I know _CLEARED is supported in the controller, or are most controllers already on that level? A controller without the support just ignores gracefully?
A responder has no way to know if the controller supports the _CLEARED messages. All you can do is send the _CLEARED response and hope the controller handles it gracefully. There's really no other option.

Quote:
Originally Posted by eldoMS View Post
- do I only report once a certain failure (when it arises)? Or consistently with each STATUS_MESSAGE when _CLEARED is not supported? And if I need to report it consistently, how often?
This has always been unclear in the standard, and the 2010 revision doesn't address it.

If you report a failure that is still occurring with every status message response, the user will be flooded with messages. But, if you only send it once, if the message gets lost for some reason, there's no way to know that it's there.

My opinion is that a responder should re-send status messages that are still occurring in proportion to how serious the error is. You might want to re-send a "Dimmer on Fire" status every 30 seconds, but "Gel String getting old" would only need to be sent once a day or so. To be clear, this is not based on the standard. It's merely my way of working around what I see as a limitation in the standard. What is really needed is a "resend all currently occurring status conditions". CLEAR_STATUS_ID *might* be able to serve this purpose, but the text isn't really very clear on exactly what CLEAR_STATUS_ID should do.

Quote:
Originally Posted by eldoMS View Post
- in the case of _CLEARED I only report ONCE that a certain condition was cleared?
Yes, I agree with this, provided you follow the rules for STATUS_GET_LAST_MESSAGE so that a controller has a way to re-request a _CLEARED message that gets lost or corrupt.

Quote:
Originally Posted by eldoMS View Post
- the PID CLEAR_STATUS_ID, what does it exactly do in this case? Is it a reset of the condition, that in a sticky example immediately comes again with a voltage or temp error and there will be another reporting of this in the next STATUS_MESSAGES (one time only?). Is this the controllers method to clear conditions and create a fresh list? How often could a controller do this? The _CLEARED method is used to remove a warning/error from the controller as soon as it is cleared instead of going via CLEAR_STATUS_ID?
I have no idea what CLEAR_STATUS_ID is supposed to do. There simply isn't enough information in the standard. One interpretation is that if you have a ton of old status message that are queued up and waiting to be delivered, this PID can flush the queue and allow you to get newer messages.

A second interpretation is that it tells the responder to forget what it has already sent, and re-deliver any status conditions that are still occurring.

As I said earlier, I prefer the second interpretation since it's a feature the standard really needs, but I don't think the text is clear enough.
ericthegeek is offline   Reply With Quote
Old September 2nd, 2011   #3
sblair
Administrator
 
Join Date: Feb 2006
Posts: 419
Send a message via AIM to sblair Send a message via MSN to sblair
Default

Quote:
Originally Posted by ericthegeek View Post
I have no idea what CLEAR_STATUS_ID is supposed to do. There simply isn't enough information in the standard. One interpretation is that if you have a ton of old status message that are queued up and waiting to be delivered, this PID can flush the queue and allow you to get newer messages.

A second interpretation is that it tells the responder to forget what it has already sent, and re-deliver any status conditions that are still occurring.

As I said earlier, I prefer the second interpretation since it's a feature the standard really needs, but I don't think the text is clear enough.
Yes, that description is a bit terse. What is interesting is that it has been in since the original document and questions/issues have never come up about it before.

It is intended to pretty much do what it says which is to flush the status queue in the device. This is a SET message only with no other parameter data. So when a device receives this message it should flush all pending status messages it has queued.
__________________
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
STATUS_MESSAGES berntd RDM General Implementation Discussion 17 October 20th, 2009 11:05 PM
Cable shield connection questions berntd RDM Physical Layer/Hardware Discussion 0 May 26th, 2008 12:22 AM


All times are GMT -6. The time now is 07:39 PM.


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