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)
-   -   When to use Queued Msg VS Status Msg (http://www.rdmprotocol.org/forums/showthread.php?t=1056)

Mark_C January 11th, 2010 08:33 PM

When to use Queued Msg VS Status Msg
 
Greetings,

We have implemented RDM in a prototype LED pixel bar. I have treated each pixel as a subdevice with 3 channels (RGB), and the root with zero footprint. I am using Enttec's controller software to test the various functions and everything seems to work pretty well.

My confusion is on the queued messages versus status messages. It seems from the document that the two are separately maintained lists inside the controller, and one is accessed using the QUEUED_MESSAGE command and the other is accessed using the STATUS_MESSAGE command. Is that correct, and if so, how do I decide what things should go in each?

It appears from examples that things typically queued are non-error changes like DMX Address (assuming hardware dip switches on the controller), or controller or lamp hours. And things that don't get queued are things like errors (LED failure or overtemp). Am I close :)

Any help would be appreciated! Thanks!

Mark

sblair January 11th, 2010 09:34 PM

Mark,

Simply put there are two different lists of messages. The queued message list is for the device to report back a setting change of a PID. For example, if someone changes a setting such as DMX Address from the device's menu then it can use a queued message to report back to the controller the change in DMX Address.

Status Messages are for reporting back warnings or errors such as over temp information, a lamp reaching the end of it's life, or a failure of some kind.

The controller has the ability to retrieve Status Messages using the GET: QUEUED_MESSAGES from the device by indicating what level of status type it wants back (ERROR, WARNING, INFO, etc). The status message is only returned in this case if there are no queued messages to be reported.

If a controller ONLY wants to get status messages and not other queued message PID's then it can use the GET: STATUS_MESSAGES to retrieve them.

QUEUED_MESSAGES is not required to be implemented in a device (although VERY useful and encouraged). When it is not implemented, then GET: STATUS_MESSAGES is the only way for the device to report the information.

Hope that sheds some light.

Where are you located at? We have another RDM Plugfest happening Dallas in about 2 weeks and it would be a good chance for you to test with a wide range of devices and get all your questions answered by members of the Task Group in person.

Mark_C January 12th, 2010 12:59 PM

When to use Queued Msg VS Status Msg
 
Thanks Scott,

That's the way I interpreted it, but I was uneasy. Your response was very clear - and helpful!

We are in Overland Park, Kansas. It was my intention to try and get down there to the plugfest if our other travel schedules allow. It sounds like a great event.

Thanks for your help!

Mark

sblair January 12th, 2010 01:08 PM

Here's the schedule for that weekend: http://www.esta.org/tsp/meetings/index.php

It is next weekend (22-24th). We would love to have you attend and everyone else that has attended has found it invaluable enough they keep coming back. If you have any questions, please let me know.

Scott


All times are GMT -6. The time now is 05:33 AM.

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