We've launched our new site at www.openlighting.org. This wiki will remain and be updated with more technical information.
Difference between revisions of "RDM Discovery"
From wiki.openlighting.org
(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…") |
|||
| Line 3: | Line 3: | ||
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. | 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. | ||
| + | == Process Overview == | ||
| + | |||
| + | == Failure Modes == | ||
=== Responders that reply outside their range === | === Responders that reply outside their range === | ||
| Line 23: | Line 26: | ||
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 | 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 | ||
| + | |||
| + | == Example Implementation == | ||
| + | |||
| + | The implementation of the RDM discovery algorithm as used in the [[Open Lighting Architecture]] can be seen [http://code.google.com/p/linux-lighting/source/browse/common/rdm/DiscoveryAgent.cpp here] | ||
[[Category:Articles]] | [[Category:Articles]] | ||
Revision as of 19:10, 20 October 2011
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.
Contents
Process Overview
Failure Modes
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
Example Implementation
The implementation of the RDM discovery algorithm as used in the Open Lighting Architecture can be seen here
