Personal tools
The Open Lighting Project has moved!

We've launched our new site at www.openlighting.org. This wiki will remain and be updated with more technical information.

RDM Discovery

From wiki.openlighting.org

Revision as of 19:06, 20 October 2011 by Nomis52 (talk | contribs) (Created page with "This documents various scenarios that should be considered when writing software that performs RDM Discovery. Unlike DMX, RDM is bi-directional, which means bad devices cā€¦")
(diff) ā† Older revision | Latest revision (diff) | Newer revision ā†’ (diff)
Jump to: navigation, search

This documents various scenarios that should be considered when writing software that performs RDM Discovery. Unlike DMX, RDM is bi-directional, which means bad devices can trigger bugs in the controllers causing them to crash or go in to an infinite loop.

This page is not a substitute for the E1.20 standard, which takes precedence over all information presented here. It simply presents situations which designers of controllers should consider when writing their software.


Responders that reply outside their range

Responders that don't reply to Mute

Some responders may not reply to the MUTE_DEVICE message. This case must be differentiated from the case where the MUTE_DEVICE message is corrupted or lost so the responder never replies. The pseudo-code in the E1.20 standard attempts to mute each device up to 10 times before continuing.

Responders that don't mute

Not to be confused with the scenario above, some responders may acknowledge the mute request but continue to respond to discovery requests. If there is only one responder that behaves this way controllers should be able to succeed,


Responders that 'disappear'

Proxied Devices

The E1.20 states that a proxy shall not provide more than one DISC_UNIQUE_BRANCH response at once. This means that once the proxy has been located and muted, controllers must continue to