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
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 . The tests which cover the cases above are in DiscoveryAgentTest.cpp
