View Single Post
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