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)
-   -   status error queued?/status id definnition (http://www.rdmprotocol.org/forums/showthread.php?t=1154)

luiscolo January 18th, 2013 12:49 PM

status error queued?/status id definnition
 
Hi everyone!
I'm working on the "collection of queued and status messages"
I have a couple of questions:

1) Consider the following case:
a responder has it's queue message empty
the temperature sensor is in overtemp condition,

may the responder flag a pending message queued in it's message count?
in the next queued message request it will inform the overtemperature condition with a status message,

Is this a valid mechanism? I know it's not exactly a queued message, but if the controller, for any reason, do not requiere status messages and based on the "non queued messages" info, may pospond their known about the overtemp info,

2) Based on the "power state defines", a responder could fail to re-enable his power supply to return to normal state from standby or shutdon state, how it must inform this? there is no status id definition for power supply failure,

I think i can create a sensor that monitors the power supply (in fact it's an optocoupler that monitor this condition), and report an undervoltage error, but is not the exactly case, do you think that we may add the ppower supply failure to the status id definitions or only (and not straightly) create a virtual sensor that monitors if the supply succeds to turn on and repoort them as 12V (for example) or if it fails report them as 0 volts?

thanks in advance and sorry for my poor english,
Luis Bolster

nomis52 January 18th, 2013 08:46 PM

Quote:

Originally Posted by luiscolo (Post 2544)

1) Consider the following case:
a responder has it's queue message empty the temperature sensor is in overtemp condition,

may the responder flag a pending message queued in it's message count?
in the next queued message request it will inform the overtemperature condition with a status message,

That's how I consider it to work but other's probably disagree. The queued message acts as a signal to the controller that it should send a GET QUEUED_MESSAGE. It's legal to respond with a STATUS_MESSAGE at that point since it's just another PID.

Simon

sblair January 18th, 2013 09:13 PM

Will it break anything if you do that? Probably not.

The intent when we wrote that language was that the Message Count was only for Queued Messages and not Status Messages. The language of E1.20 keeps queued messages and status messages as seperate concepts in the document.

The issue that lead to Message Count/Queued Messages being added was a way to simplify ACK_TIMER for controllers so that they would have an alert when an ACK_TIMER was satisfied so the contoller could get the info without having to track all the ACK_TIMERS and also to alert the controller when a user changed something on the device manually, like the DMX Address.

sblair January 18th, 2013 09:50 PM

Actually there is a case where doing that can kind of break things. If the device has a warning or advisory status message that is in the Message Count and the controller is asking only for STATUS_ERROR level messages when it does a GET: Queued Messages then it will just keep spinning on trying to get that queued message that will never get delivered.

luiscolo March 15th, 2013 09:15 AM

Hi everyone again!
Still blocked on the status collection messages.
In reference to the previous,

in an overtemp condition,
must I queue an overtemp condition on the status queue and repoort an error queued message for sensor value?

sorry for the circular thread, but I can't find a logic criteria for this collection from the standard.

Thank you again for the time spent to this, regards,
Luis

sblair March 15th, 2013 03:13 PM

When the controller requests QUEUED_MESSAGES from the device if there are no queued messages to report, the device can then respond back with STATUS_MESSAGES.

In my implementations I would add the error condition to my status messages queue to report back. I keep seperate queues for status messages vs. queued messages.

Since it is a status message I would not increment the queued message count field. When the controller requests QUEUED_MESSAGES then you can report the status message back providing there are no queued messages indicated as pending.

Some controllers may also use the STATUS_MESSAGES PID directly to request status messages rather than relying completely on QUEUED_MESSAGES PID as the delivery. That can be useful if the responder is "chatty" with it's use of queued messages.

If you have an error condition that is important to get back, I would suggest internally prioritizing your use of queued messages so the status message is not always sitting at the back of the bus. In other words queue important messages, but you may choose not to queue up or delay queueing less significant messages until the status message has been delivered.

There are different ways it can be implemented, but this is how I would personally implement it myself.


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

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