Licht

RDM: DMX mit Rückmeldungen

RDM steht für Remote Device Management und wird von der ESTA unter ANSI E1.20 geführt. RDM baut auf dem DMX-Protokoll auf, erlaubt aber im Halbduplex Rückmeldungen, um insbesondere das Setup beim Einrichten zu erleichtern.

RDM erlaubt sogar einen gemischten Betrieb mit älteren DMX-512-Geräten, wodurch der großen Verbreitung von RDM grundsätzlich eine große Hürde genommen wird. Mit einem alternativen Startcode (ASC) wird gekennzeichnet, dass es sich um eine RDM-Sendung handelt, ist der Startcode 0 werden DMX-Werte übertragen. Es können aber auch Nicht-RDM-Datenpakete übertragen werden. RDM-Pakete sind im Timing mit denen von DMX 512 und DMX 512-A identisch.

Anzeige

RDM nutzt nur die Leitungen der Pins 2 und 3. Im Livebetrieb wird während der Show der RDM Mode meist abgeschaltet, da die Verzögerung des nächsten Steuersignals durch Feedbackaktionen auf der gleichen Leitung, bei einem Fade Ruckeln in der Bewegung verursachen könnte. Im Einrichtbetrieb ist es möglich, dass sich die Geräte am Steuerpult anmelden und Statusinformationen senden. Damit kann beim Setup immens Zeit gewonnen werden, da sich z. B. die Moving Lights automatisch beim Steuerpult anmelden und je nach eingestellten DMX-Mode des Moving Lights die richtige Kanalbelegung erfolgen kann. Ein Adressieren der Geräte vor dem Setup kann auch entfallen, die Zuordnung und Einstellung des Setups kann dann bequem vom Pult aus erfolgen.

Damit sich die verschiedenen Geräte nach dem Einschalten bei einer Steuerung anmelden können, ist es unabdingbar, dass die Geräte nicht die gleiche Adresse aufweisen. Deshalb hat jedes Gerät weltweit eine eigene Nummer – die UID Unique Identifier besteht aus 6 Bytes. Die ersten zwei Bytes kennzeichnen den Hersteller. Der Hersteller definiert die weiteren Bytes und sorgt somit dafür, dass keine zwei gleichen Adressen entstehen. Mit dieser Nummer haben sich die Geräte bei der Steuerung angemeldet und der Benutzer kann nun jedem Gerät eine eigene, für ihn leicht einprägsame Kanalnummer oder Kennzeichnung vergeben.

RDM ist im Gegensatz zu DMX 512-A wesentlich genauer definiert. So wird zunächst der alternative Startcode (ASC) so gesetzt, dass alle angeschlossenen Geräte angemeldet werden können. Zum Zeitpunkt der Geräteanmeldung können verstärkt Datenkollisionen auftreten, da die Geräte von sich aus senden. Sind erst einmal alle Geräte gefunden und angemeldet, dann erfolgt nur noch die gezielte Anforderung an ein Gerät, dass es nun ein Feedback senden kann. Das Kontrollgerät übernimmt die Kontrolle und fragt nicht schneller als ca. alle 5 Sekunden jedes Gerät einzeln ab (Polling). Dadurch erfolgt das Feedback nach Zustand bzw. Status oder Fehlermeldung der angeschlossenen Geräte. So sind die Befehlsketten für Pan/Tilt flip oder invert Display bereits definiert. Auch können Parameter wie z. B. DMX-Adressen an das Gerät übertragen werden. Es kann aber nur ein Controller zugleich aktiv sein bzw. DMX-Werte senden.

Weiterhin unterscheidet RDM noch die Geräte in Proxy-Geräte, wie z. B. Booster-Splitter, und Geräte und Sub-Geräte, wie z. B. einen Dimmerschrank mit seinen Untereinheiten von Dimmermodulen.

 

Bezeichnung RDM (Remote Device Management)
Festlegung des Protokolls durch ESTA ANSI E1.20
BSR E1.20
Beschränkt auf einen Hersteller Nein
Senden und Empfangen halbduplex
Busstruktur Mehrpunktverbindung, 2-Draht
Kommunikation asynchron, seriell, asymmetrisch
Protokoll wird aufgesetzt auf EIA-485-A: 1998
Leitungslänge ohne Booster/Hub nicht definiert,

definierte Kabel 500 m

Max. Teilnehmerzahl
ohne Booster / Hub
32
Busabschluss notwendig 120 Ohm/0,25 Watt
Kommunikation Polling
Leitung geschirmtes Cat.6
Steckverbinder 5-poliger XLR (in Ausnahme RJ45)
Pin 1 Masse
Pin 2 und 3 DMX 512, RDM-Daten
Pin 4 und 5
Übertragene Kreise max. 512, Startbyte definiert
Auflösung 8 Bit (256 Werte werden unterschieden)
Übertragungsgeschwindigkeit 250 Kbit/s

 

Ist z. B. ein DMX-512-Aufbau mit Splittern ausgerüstet, und man erneuert das Steuerpult und den Dimmer mit RDM-fähigen Geräten, müssen aber auch die im System befindlichen Splitter RDM-fähig sein. Denn für eine Rückmeldung zum Pult müssen die Informationen in die Gegenrichtung „getrieben“ werden, was eine bidirektionale Elektronik voraussetzt. Die üblichen Booster und Splitter weisen dagegen meist nur Operationsverstärker auf, um das Signal vom Stellwerk zu verstärken. Ein Signal vom Moving Light zurück zum Pult wird dann mangels Treiberelektronik für den Rückweg nicht weitergegeben. Um Daten in beide Richtungen zu treiben, werden Tri-State-Halbleiter benötigt. Um eine direkte Rückkopplung zu verhindern, schaltet ein Controller den jeweils rücksendenden Treiber ab.

 

DMX-Splitter
Einfache Aufsplittung und anschließendes Boosten für unidirektionalen Datenfluss (z. B. DMX512), Operationsverstärker sorgen für einzel verstärkte Ausgänge eines Eingangssignales (Bild: Herbert Bernstädt)

 

Schaltbild von verzweigten Signalen, die bidirektional Daten senden können
Booster für bidirektionalen Datenfluss (z.B. RDM).
Für RDM müssen die Informationen auch zurück zum Pult gesendet werden können, deshalb muss der Signalverstärker auch in die Gegenrichtung arbeiten, realiesiert mit einem zweiten OP.

DMX 512 1990 stellt für viele Endgeräte ein vollkommen ausreichendes und einfaches Protokoll dar. Größere Anlagen, bei denen mehr Komfort durch rückmeldende Geräte wünschenswert ist, fordern auf den ersten Blick eine Erweiterung der DMX-512-Funktionen, so dass ein neues, abwärtskompatibles Protokoll wie RDM entsteht. Jedoch muss man sich hier fragen, ob bei komplexen Anlagen nicht ohnehin schon eine weit verbreitete und preisgünstige Alternative aus der Computerwelt, das Ethernet, kräftigen Anklang findet und somit ein neues Protokoll wie RDM überflüssig macht. Auch hier ein entschiedenes Jein. Bedingt durch die sternförmige Vernetzung des Ethernets wird man im Rigg wieder auf DMX wandeln, um dann von Gerät zu Gerät schleifen zu können. Möchte man dann eine Rückmeldung nutzen, benötigt man ein Signal wie RDM, um die Information bis zum Ethernet-DMX-Wandlerknoten (Node) zurück zu senden. So gesehen, werden wir zukünftig verschiedene Protokolle beherrschen müssen.

 

 

  • Kommentare für diesen Artikel

    Schreiben Sie einen Kommentar

    Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.