|
RDM General Implementation Discussion General Discussion and questions relating to implementing RDM in a product. |
|
Thread Tools | Search this Thread | Display Modes |
September 26th, 2008 | #1 |
Task Group Member
Join Date: Jun 2006
Posts: 181
|
Incremental Discovery
A number of controller implementations have run into the challenge of a workable implementation of incremental discovery.
If you simply issue further DISC_UNIQUE_BRANCH messages, you will catch up with NEW devices that have been added, but may miss ones that have previously been connected and have been disconnected long enough for normal polling to have "lost" them. The standard makes no mention of responders un-muting just because they have been disconnected from the DMX line (and not power cycled). The unplugging, reconnection and failure to be re-discovered is a familiar problem and has been seen at the various plugfests I have run.. Early AL responder products (coded to a draft version of the standard) had adopted a policy which, although sound, was unfortunately NOT mentioned in the standard. They had decided to UNMUTE a responder after a timeout period based on loss of RDM/DMX traffic. This of course has its own challenges, as you would not want to unmute just because you had not seen any RDM commands for (say) the last 10 minutes, although there is an argument that it makes sense after several minutes of neither RDM or DMX traffic. It is also potentially a pain in an RDM only environment, where RDM is being used to collect sensor data and there is no DMX to be seen anywhere. Currently, I believe the best approach for “Incremental Discovery” as follows UNMUTE ALL then re-mute the ones you believe exist before sending the DISC_UNIQUE_BRANCH. The controller should timeout on any that have truly gone away and thus can then remove them from its table of connected devices. Another approach would be to keep a separate list of "lost devices" (ie lost since last Full Discovery") and attempt to communicate with them once last time before running an incremental discovery that is just a DISC_UNIQUE_BRANCH. This may be more efficient if the list of "lost" devices is small, and the number of known devices is large, as it would consume less bandwidth. For users of the RDMLabpack : I can confirm that the current RDMLabpack software (v2.6d) cancels IDENTIFY on receipt of an UNMUTE. This was done because the controller sending the UNMUTE might be different to the controller sending it last time around, (eg backup console taking over) and I did not want a new controller to discover a device and assume it was NOT in IDENT mode, when it was still, as a hangover from the sesssion with the original controller. Please don’t forget that our products (including the Labpack) cancel IDENTIFY mode after a timeout period (typically 90seonds). This was by design as with some simple RDM controllers it wsa too easy to step thru a rig and leave things in IDENTIFY mode and it became very cumbersome to get everything back to “Show Usefull” mode if you (a) did not have a Broadcast IDENT OFF command capability or (b) you don’t immediately know the UID of the various devices yiu have left in IDENT and thus cannot quickly find them to turn it off. A lot depends on the (usability) of your user interface as a controller. I would also draw your attention to the command in the RDMLabpack that allows you to get the responder to mis-behave by NOT muting when it should. This is an excellent way to break many simplistic controller discovery algortihms, and I would recommend you allow for such a scenario rather than spin forever …. as you don’t want a substandard responder implementation to make it look like the controller is severly broken. Peter Willis |
September 29th, 2021 | #2 |
Junior Member
|
Hi Everyone,
We are facing the same issue not on a controller side but on our node implementation for our profile fixture range. We do work on ARTNET/RDM :RDMNet being nor ready and MANET/ETC NET are proprietary protocol. We have about 60 PIDs implementation and we are going to limit the RDM data transfert to 16 fixtures to prevent long discovery. 16 units on a pipe is quite a large number already. We have seen that a lot of high end nodes do have an incremental discovery and you can remove it during the show but you would loose the possibility in this case to monitor if all your fixtures are present. Some manufacturers have a not so incremental discovery and a lot of traffic is generated. We might take the view of the post above and offering the possibility to have RDM incremental on and off probably on a control channel, display, RDM manufacturer pid and web interface that we have also. Anyone here who implemented this on a node?...we believe that no one yet implemented this on a fixture. We tested so far 3 major lighting console brand and we have 3 flavours of RDM implementations and discovery is part of this. Also they do not treat RDM the same when they use a DMX line and an ARTNET/RDM network. It is all part of the fun. |
Bookmarks |
Thread Tools | Search this Thread |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Discovery Response Preamble | prwatE120 | RDM General Implementation Discussion | 0 | January 20th, 2007 01:22 AM |
Discovery Checksum Problem Analysis | nic123 | RDM General Implementation Discussion | 3 | September 24th, 2006 11:25 PM |
4.2.1.1 In-line device Port Turnaround during Discovery | prwatE120 | RDM Timing Discussion | 1 | August 7th, 2006 11:52 PM |