E1.20 RDM (Remote Device Management) Protocol Forums

E1.20 RDM (Remote Device Management) Protocol Forums (http://www.rdmprotocol.org/forums/index.php)
-   RDM General Implementation Discussion (http://www.rdmprotocol.org/forums/forumdisplay.php?f=4)
-   -   GET_STATUS_MESSAGES for fault reporting (http://www.rdmprotocol.org/forums/showthread.php?t=1235)

dj41354 December 16th, 2015 09:45 AM

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

ericthegeek December 17th, 2015 10:30 PM

Quote:

Originally Posted by dj41354 (Post 2964)
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 (Post 2964)
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 (Post 2964)
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 (Post 2964)
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 (Post 2964)
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 (Post 2964)
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.

dj41354 December 18th, 2015 10:15 AM

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..

ericthegeek December 18th, 2015 12:57 PM

Quote:

Originally Posted by dj41354 (Post 2966)
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 (Post 2966)
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 (Post 2966)
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 (Post 2966)
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!


All times are GMT -6. The time now is 04:21 PM.

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