![]() |
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 |
Quote:
Quote:
Quote:
Quote:
Quote:
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:
_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. |
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.. |
Quote:
"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:
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:
Quote:
|
All times are GMT -6. The time now is 01:33 AM. |
Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2024, vBulletin Solutions, Inc.