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 December 16th, 2015   #1
dj41354
Member
 
Join Date: Nov 2015
Posts: 31
Default GET_STATUS_MESSAGES for fault reporting

I'm starting on GET_STATUS_MESSAGES.
I have only two faults.. FAN_FAULT and OVER_TEMPERATURE_FAULT. Either will cause the light to discontinue normal operation where the main LED's go dim (depending on which fault), and the back panel LCD shows a fault message. The only way to recover (resume normal operation) is to cycle hard power, or in the case of the RDM implementation, reset the device.

My plan:
1) Implement GET_STATUS_MESSAGES & GET_STATUS_ID_DESCRIPTION and include them in the SUPPORTED_PARAMETERS list.
2) Define two custom Status_Message_IDs: 0x8000="FAN FAULT-RESET DEVICE" and 0x8001="OVER TEMPERATURE FAULT-RESET DEVICE"
3) Implement SET_RESET_DEVICE (and include it in SUPPORTED_PARAMETERS) so that a reset can be issued to see if a re-boot will clear the fault.
4) I will only ever have one of these faults present, because when one happens, the fixture doesn't even look for the other one to happen.. it goes into it's hard-coded fault mode.

Questions:
1) It looks like the Message Count field is not used to report that I have recorded a fault. It looks like it's reserved for GET_QUEUED_MESSAGE" commands.. is this correct?
2) I currently don't have STATUS_ADVISORY or STATUS_WARNING types. Do I need to code responses for requests of these types?.. and what would they be if I did? ACK's with no data?
3) I was planning on responding with the fault, whenever the light is in the fault mode, every time the GET_STATUS_MESSAGES or GET_LAST_MESSAGE is received. Only when the fault has been cleared with power cycle, or device-reset will these messages show clear.
4) I'm not planning on doing anything with STATUS_ADVISORY_CLEARED, STATUS_WARNING_CLEARED, and STATUS_ERROR_CLEARED.

I'm trying to keep this as simple as possible..
Does this plan sound ok from a system standpoint?.. any suggestions/tweeks that I should consider?

Thanks for your help with this..
Doug

Last edited by dj41354; December 17th, 2015 at 11:40 AM.
dj41354 is offline   Reply With Quote
Old December 17th, 2015   #2
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 375
Default

Quote:
Originally Posted by dj41354 View Post
I'm starting on GET_STATUS_MESSAGES.
That's good to hear. Status messages are a relatively advanced feature, so if you've gotten that far things must be going well.

Quote:
Originally Posted by dj41354 View Post
2) Define two custom Status_Message_IDs: 0x8000="FAN FAULT-RESET DEVICE" and 0x8001="OVER TEMPERATURE FAULT-RESET DEVICE"
The second string might be too long, strings are limited to 32 characters.

Quote:
Originally Posted by dj41354 View Post
1) It looks like the Message Count field is not used to report that I have recorded a fault. It looks like it's reserved for GET_QUEUED_MESSAGE" commands.. is this correct?
I don't think this is clearly specified in the standard, so it's not clear what the "correct" behavior is. You have to include Queued Messages, whether you include status messages in the count is up to you.

Quote:
Originally Posted by dj41354 View Post
2) I currently don't have STATUS_ADVISORY or STATUS_WARNING types. Do I need to code responses for requests of these types?.. and what would they be if I did? ACK's with no data?
Status types are cumulative, so if the controller requests Advisory or Warning, and you have one of your error messages pending, then you need to return the error (E1.20-2010 Table 10-1). If you have no status messages pending, then you can just ACK with no data.

Quote:
Originally Posted by dj41354 View Post
3) I was planning on responding with the fault, whenever the light is in the fault mode, every time the GET_STATUS_MESSAGES or GET_LAST_MESSAGE is received. Only when the fault has been cleared with power cycle, or device-reset will these messages show clear.
You definitely should not send it every time a GET STATUS_MESSAGES is sent. This can result in a giant log file on the controller, especially if it naively logs every status message.

Status messages are intended to be sent once with STATUS_(type) when the condition first occurs. Then, when condition no longer exists, it should be sent once with STATUS_(type)_CLEARED. At least that's how it's supposed to work.

The downfall is what happens if a message is delivered to a touring show's console moments before the console is unplugged and loaded on the truck? When the house console is plugged back in to the rig, it will never see the message since the fixture thinks it's already notified the controller.

There's no perfect solution to this conundrum.

My advice is to re-report any ongoing status conditions with a frequency that is proportional to the severity of that condition. "Dimmer Room Flood" might be repeated a few times a minute, "Line Voltage Low" a few times an hour, "Air Filter 1% used" once a week (With increasing frequency as it approaches 100% clogged).

Some implementers interpret "CLEAR_STATUS_ID" as a trigger to re-report any ongoing status conditions to the controller. The standard isn't exactly clear on what this PID is supposed to do. Nevertheless, I think this is probably good practice, even if it's not strictly backed up by the E1.20 text.

Quote:
Originally Posted by dj41354 View Post
4) I'm not planning on doing anything with STATUS_ADVISORY_CLEARED, STATUS_WARNING_CLEARED, and STATUS_ERROR_CLEARED.
If this were my product, I would not consider an over-temp condition to be a fatal error. When the operating temperature returns to normal I would issue _CLEARED and return to normal operation. Temperature events are often transient (someone turns off the air conditioning for the weekend and forgets to turn off the light). But, from a protocol standpoint, not using _CLEARED is perfectly fine.

_CLEARED makes sense for some status conditions that occur, and then get resolved (Under Voltage, Breaker Trip, etc.). But some status conditions are purely informational, and will never really be cleared. For example, "Lamp Replaced" or "system rebooted"; The operator might want to know that they have occurred, but there's no real end to those conditions that you'd ever report.
ericthegeek is offline   Reply With Quote
Old December 18th, 2015   #3
dj41354
Member
 
Join Date: Nov 2015
Posts: 31
Default

from ANSI E1.20-2010 Section 6 Message Structure:
sub-section 6.2.8 Message Count:
"The message count field is used by a responder to indicate that additional data is now available for collection by a controller. This data (which might be unrelated to the current message transaction) should be collected by the controller using the GET:QUEUED_MESSAGE command."

This paragraph certainly makes it sound like the Message Count field is used by QUEUED_MESSAGE, not STATUS_MESSAGES... so I guess I'm still unclear on this..

Questions:
1) Is it ok to implement STATUS_MESSAGES and not implement QUEUED_MESSAGE?
(you said in your 4th response to me above: "You have to include Queued Messages, whether you include status messages in the count is up to you."
2) If Message Count is not used with my implementation of STATUS_MESSAGES, how does the controller know to ask for device status?.. does the controller just do this occasionally on it's own?

Thanks for you help with this..
dj41354 is offline   Reply With Quote
Old December 18th, 2015   #4
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 375
Default

Quote:
Originally Posted by dj41354 View Post
from ANSI E1.20-2010 Section 6 Message Structure:
sub-section 6.2.8 Message Count:
...
This paragraph certainly makes it sound like the Message Count field is used by QUEUED_MESSAGE, not STATUS_MESSAGES... so I guess I'm still unclear on this..
It's a good question, and your interpretation is perfectly valid. The ambiguity arises because of Section 10.3.1 paragraph 3:
"A responder with no messages queued shall respond to a QUEUED_MESSAGE message with a STATUS_MESSAGES response."

This means that a status message can also be collected by a GET QUEUED_MESSAGE request, thereby fulfilling the requirements of the paragraph that you quote.

I think your interpretation (that only Queued Messages should be included in the message count) is the better interpretation, but there are others who disagree.

Quote:
Originally Posted by dj41354 View Post
1) Is it ok to implement STATUS_MESSAGES and not implement QUEUED_MESSAGE?
(you said in your 4th response to me above: "You have to include Queued Messages, whether you include status messages in the count is up to you."
I'll re-state it like this: "You have to include any outstanding Queued Messages in the Message Count field. Whether you include status messages in the Message Count is up to you."

By way of example: If you have 2 queued messages and 3 status messages waiting, then the message count could be 2 (queued messages only), or 5 (Queued plus Status messages). It's your choice, just as long as you're consistent.

Support for the STATUS_MESSAGES and QUEUED_MESSAGE PIDs is optional. You can support either one of them individually, both, or neither. It's entirely up to you.

Quote:
Originally Posted by dj41354 View Post
2) If Message Count is not used with my implementation of STATUS_MESSAGES, how does the controller know to ask for device status?.. does the controller just do this occasionally on it's own?
Many controllers will poll for status and/or queued messages on an ongoing basis. Common (but not universal) behavior is to poll each responder every few seconds.

Quote:
Originally Posted by dj41354 View Post
Thanks for you help with this..
Happy to help. That's why these forums exist. Hopefully you'll stick around, and maybe in a year or so you'll be the one answering questions!
ericthegeek 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 and simple status reporting Jim Acker RDM General Implementation Discussion 2 February 23rd, 2012 01:24 PM
Simple dimmer error reporting Milton Davis RDM General Implementation Discussion 3 November 7th, 2008 11:15 AM
COMMS_STATUS Error reporting prwatE120 RDM Interpretation Questions 0 January 20th, 2007 07:07 AM


All times are GMT -6. The time now is 02:27 AM.


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