[SOUNDLIGHT]

DMX RDM - was ist das?

DMX RDM steht für "Remote Device Management", also "Gerätefernverwaltung" und ermöglicht die Abfrage und die Konfiguration von an den DMX Bus angeschlossenen Geräten. Es ist sozusagen ein "Plug and Play" System, bei dem der Controller die angeschlossenen Geräte identifizieren kann, sie auf ihre Möglichkeiten hin abfragen kann und sie daraufhin - grösstenteils automatisch- konfigurieren kann. Manuelle Einstellungen, wie z.B. das Setzen der DMX Startadresse, werden damit unnötig: ein Vorteil in zeitlicher Hinsicht und natürlich bei unzugänglichen oder schwierig erreichbaren Geräten. Der DMX RDM Standard ist mittlerweile als ANSI Norm E1.20-2006 erschienen und mehr und mehr Geräte werden mit RDM Funktionalität ausgestattet. Auf der PRO LIGHT & SOUND Frankfurt (1. bis 4. April 2009) zeigte SOUNDLIGHT-Chef Eckart Steffens in Seminarvorträgen auf dem Media Systems Congress erstmalig in Deutschland öffentlich in einem Kongress das Zusammenspiel unterschiedlicher RDM-Komponenten aus den Häusern Philips, Robe, Enttec, DMXProfi, Artistic License und SOUNDLIGHT. Auf der SHOWTECH 2009 Berlin (16-18. Juni 2009, Messe am Funkturm Berlin) wird ebenfalls ein lauffähiges DMX RDM System am Stand zu sehen sein. Gerade im Architekturlichtbereich, aber auch im Theater hat DMX RDM absolute Vorteile, da die Geräte-Einstellung und Verwaltung auf der Bühne entfällt: das hat jetzt alles der Controller (das Pult) im Griff. Jahrelang mußten wir darauf warten, jetzt ist RDM verfügbar: machen Sis sich selbst ein Bild!

Standard der Zukunft

Wer braucht das noch, wenn es schon EtherNet gibt? Damit geht doch auch alles, und DMX wird bald abgelöst. Diese Meinung hört man oft, und sie ist ebenso häufig wie falsch. DMX wird in der "letzten Meile" der Bühnenverkabelung bestehen bleiben, denn dort wäre eine sternförmige EtherNet-Verkabelung viel zu aufwendig und viel zu störanfällig. DMX RDM bietet in enger Abstimmung mit ACN, dem neuen EtherNet-Standard, eine übereinstimmende Funktionalität, sodaß die hier verwalteten Daten transparent weitergereicht werden können. ACN und RDM ersetzen sich nicht, sondern sie ergänzen sich vielmehr perfekt zum zukünftigen Teamplayer. Wer jetzt auf RDM setzt, ist damit schon bestens gerüstet, wenn ACN (erste Geräte sind auch hier schon in den Startlöchern...) in vollem Umfang verfügbar ist. Wer mehr dazu wissen möchte, der lese den Artikel "ACN and RDM: Working together to add real value" in Ausgabe 2/2009 der Zeitschrift "PROTOCOL" (www.esta.org). 		ESTA PROTOCOL SPRING2009

Technische Voraussetzungen

Die technische Voraussetzung für DMX RDM ist eine bidirektionale Kommunikation auf dem DMX Bus. Hier war bisher nur eine unidirektionale Kommunikation möglich: vom Controller (dem Lichtpult, dem PC, etc.) zu den angeschlossenen Geräten. Bei DMX RDM müssen die Teilnehmer antworten können. Das bedeutet: Empfänger müssen senden können, die Datenrichtung kehrt sich um. Für den Bus selbst heißt das: der Leitungsabschluß an nur einem Ende (wie bisher gehandhabt) ist nun nicht mehr ausreichend, die DMX Leitung muß wie bei Netzwerken beidseitig terminiert werden (bei einem RDM-fähigen Controller ist dann die Terminierung schon eingebaut). Und: in den Signalweg eingeschleifte Splitter müssen ebenfalls bidirektional arbeiten können, sonst würden die Geräteantworten nie beim Controller ankommen. Da Splitter bisher ebenfalls nur unidirektional funktioniert haben, müssen - und das ist die größte Herausforderung- alle DMX Splitter durch RDM-fähiges Material ersetzt werden.

 
Bus-Umschaltung nach einem RDM-Befehl mit folgender Antwort am SOUNDLIGHT RDM-Splitter 3404C-H

Auf gute Qualität der Datenleitungen ist bei RDM besonderer Wert zu legen, da DMX RDM hohe Anforderungen an die Datenqualität stellt. Die Zeiten der Verwendung billigen Mikrofonkabels sind damit endgültig zu Ende.

Ruhe bitte!

Da beim erstmaligen Aufruf mehrere Geräte antworten können, würden sich deren Antworten überlagern und ein unleserliches Antwort-Telegramm ergeben. Das merkt der Controller und kann nun den Such-Adressraum sukzessive einschränken, bis er eindeutig nur einen einzelnen Teilnehmer identifiziert hat und dessen Antwort einwandfrei empfängt.

Damit ein einmal identifiziertes Gerät weitere Abfragen nicht behindert, wird es für das weitere Abfrageverfahren stumm geschaltet und erhält dazu einen MUTE-Befehl. Wenn es diesen korrekt quittiert, gilt es als gefunden. Dieser Teilnehmer ist nunmehr identifiziert, seine eindeutige UID kann sich der Controller merken und ihn später unter dieser Adresse stets direkt erreichen.

Sind alle Busteilnehmer gefunden und demzufolge gemuted (für die Erkennung stumm geschaltet), bleibt die Antwort auf eine Abfrage aus und der Controller weiß nun, dass keine weiteren Geräte mehr gesucht werden müssen. Er kann dennoch gelegentlich ein DISCOVERY-Kommando schicken, um festzustellen, ob zwischenzeitlich nicht doch noch neue Geräte hinzugekommen sind (zum Beispiel durch eine Erweiterung der Anlage). Alternativ bleibt ihm auch vorbehalten, alle Teilnehmer durch ein globales UNMUTE-Kommando wieder für eine neue Discovery zu aktivieren - dann allerdings muß der ganze Vorgang noch einmal wiederholt werden.

Frage - Antwort!

Sind alle Teilnehmer gefunden und eindeutig mit ihren Adressen identifiziert, dann kann ab sofort jedes Gerät individuell angesprochen werden. Auf jeden Befehl muß das Gerät mit einer modifizierten Befehlswiederholung antworten - so weiß der Controller, daß sein Kommando angekommen ist, verstanden wurde, und ausgeführt wurde - oder auch nicht (und dann möglicherweise auch, warum nicht). Das ist eine Struktur, wie man sie vom Militär oder aus Großküchen kennt - knapp aber effektiv. Buskollisionen kommen aufgrund der individuellen Ansprache nicht vor. RDM Kommandos sind kurz und die Antworten auch. Sie werden zwischen den "normalen" DMX Datentelegrammen übertragen und beanspruchen daher nur sehr wenig Sendezeit, sodaß eine RDM Kommunikation im laufenden Betrieb mit durchschnittlich weniger als 10% Bandbreitenverlust beziffert wird. Im Setup-Betrieb und bei der erstmaligen Geräteerkennung (DISCOVERY) sieht das natürlich anders aus; hier ist der RDM-Traffic dominant. Aber das ist ja auch die Einrichtungsphase und nicht der Show-Betrieb.

RDM-Telegramme enthalten neben dem Befehl die Absenderadresse und die Empfängeradresse und sind damit eindeutig zielgerichtet. Als Absenderadresse gilt die UID des Controllers, als Empfängeradresse die UID des DMX Gerätes. Mehrere Geräte gleichzeitig sind durch globale UID ansprechbar, wobei gilt:

UID = 53.4C.32.06.01.02 = nur SOUNDLIGHT Relaiskarte 3206 0102

UID = 53.4C.32.06.FF.FF = alle SOUNDLIGHT 3206 Geräte (*)

UID = 53.4C.32.FF.FF.FF = alle SOUDLIGHT Relaiskarten (*)

UID = 53.4C.FF.FF.FF.FF = alle SOUNDLIGHT Geräte

UID = FF.FF.FF.FF.FF.FF = alle Geräte aller Hersteller


RDM-Discovery Antwort mit codierter Geräte-UID

(*) SOUNDLIGHT verwendet die mittleren UID Bytes als Typenkennung, z.B. 3206 = DMX Relaiskarte 6-fach. Dies Verfahren ist zur Nachahmung empfohlen, es ist jedoch herstellerspezifisch und daher nicht notwendigerweise auf Produkte anderer Hersteller übertragbar.

Gib Info...

Um an die Daten eines Gerätes zu kommen, müssen diese abgefragt werden. Das geschieht mit Hilfe der GET-Befehle. Ein GET-Befehl wird mit oder ohne Parameter geschickt und gibt unterschiedliche Datenmengen als Parameter zurück, weshalb Befehle und Antworten jeweils eine entsprechende Parameter-Datenlänge (PDL) ausweisen müssen. Um die Sicherheit der Übertragung zu gewährleisten, wird zudem die vollständige Telegrammlänge angegeben und eine 16-Bit Prüfsumme über den gesamten Telegramminhalt angefügt. Stimmt irgendeiner dieser Parameter nicht, kann der Empfänger das Telegramm als ungültig deklarieren und die Antwort mit einer entsprechenden Statusmeldung versehen. Es bleibt dann dem Controller vorbehalten, die entsprechenden Aktionen zu veranlassen.


RDM-GET-Befehl mit Antwort

... und nimm dies!

Das Setzen von Einstellungen ist analog über SET-Kommandos möglich. Auch hier kann dem Befehl eine unterschiedliche Menge von Parametern mitgegeben werden, die auf den entsprechenden Zweck abgestimmt sind. So wird beispielsweise ein "ein/aus"-Kommando als 0 bzw 1 übermittelt, ein Text hingegen als ein Block von ASCII-Zeichen. Auch hier gibt die Parameter-Datenlänge (PDL) Aufschluß über den Umfang der übermittelten Informationen.


RDM-SET-Befehl mit Antwort

Jedes Controller-Kommando (ausgenommen globale Kommandos) wird vom Gerät beantwortet: Dazu erhöht der DMX Empfänger die Befehlsklasse um 1 (aus Kommando mach Antwort) und vertauscht Absender- und Empfängeradresse (da ja die Antwort vom Empfänger an den Absender zurück geht). Zudem wird die Parameterdatenlänge angepßt und die passende Prüfsumme berechnet und dem Telegramm angefügt.

Jeder Controllerbefehl wird fortlaufend durchnummeriert. Damit ein Bezug der Antwort zum Befehl erhalten bleibt, behält der Empfänger die Befehlsnummer in der Antwort bei - so ist dem Controller eine eindeutige Zuordnung möglich. Ist dem Empfänger, aus welchen Gründen auch immer, eine sofortige Befehlserledigung nicht möglich (z.B. weil eine Entladungslampe erst gezündet werden muß), dann kann er eine Aufschub-Statusmeldung zurückgeben. Der Controller wird dann frühestens nach der angegeben Aufschubzeit erneut den Befehl auf Ausführung prüfen.

Sonder-Startcode

Alle RDM Befehle werden mit einem Sonder-Startcode $CC (dezimal 204) gesendet, gefolgt von einem Sub-Startcode $01 (dezimal 1). Diese Zuordnung ist fest vorgegeben und nicht veränderlich; die definition des Sub-Startcodes dient zukünftigen Protokollerweiterungen. Ansonsten verhalten sich RDM-Telegramme wie "normale" DMX Telegramme. Durch den Sonderstartcode werden sie von herkömmlichen DMX Empfängern nicht verstanden und nicht ausgewertet, haben als für diese keine Bedeutung (alte Empfänger, die -nicht normkonform- eine Startcode-Prüfung nicht durchführen, können flackern. Solche Geräte sind ohnehin illegal und müssen entsorgt werden). Nicht-RDM-fähige Geräte können gemischt mit RDM-Geräten betrieben werden, sie werden dann jedoch von Controller nicht automatisch erkannt und müssen nach wie vor manuell konfiguriert werden. DMX Splitter und Merger müssen Datenpakete mit RDM-Startcode behandeln können, und bidirektionalen Datentransfer erlauben.

Damit ein sicheres Handling der RDM Telegramme möglich ist, gelten für DMX RDM eingeschränkte Timing-Parameter, die eingehalten werden müssen. Hier die wichtigsten Daten im Vergleich zum Standard DMX Signal:


Außerdem muss nach jedem RDM Telegramm ggfs. die Bus-Datenrichtung umgeschaltet werden, damit die Antworten übermittelt werden können. Im Gegensatz zum bisherigen Standard DMX dürfen die Telegramme daher nicht nahtlos aufeinander folgen. Hier die einzuhaltenden Zeitrahmen:


In grafischer Darstellung ist das vielleicht etwas übersichtlicher, daher hier in Balkenform:


Es ist wichtig, dass die genannten Zeiten sowohl von Sendern als auch von Empfängern eingehalten werden, da die Busrichtung zwischen den einzelnen Datenpaketen ggfs. umgeschaltet werden muss. In dieser Zeit dürfen keine Daten auf den Bus gegeben werden, da diese durch die Busumschaltung ggfs. zerstört und somit ein ganzes DMX Telegramm unlesbar machen würden. Im RDM-Betrieb werden daher auch Standard-DMX-Telegramme etwas "luftiger" übertragen. Der Abarbeitung der Daten auf Empfängerseite kommt das eher entgegen, da somit mehr Zeit für die Ausführung zur Verfügung steht (leider gibt es immer noch viele DMX Geräte, die mit einem normmäßig "eng" gepackten Signal nicht klarkommen: das sind jedoch eindeutig Gerätefehler und solche Modelle dürften die Bezeichnung "DMX512" demzufolge ja auch eigentlich gar nicht tragen!)

Und wozu das alles?

Nur für Sie, den Anwender. Wer seinen Rigger mehrfach in schwindelnde Höhe schicken mußte, nur um ein paar fehlkonfigurierte DIP-Schalter neu zu setzen, und wer mit dem Steiger eine Gebäudefassade erklimmen mußte, um lediglich eine falsche Startadresse zu korrigieren, wird allein die wichtigste RDM-Möglichkeit schätzen: die automatische oder fernbediente DMX Startadressvergabe.

Hier sehen Sie unkonfigurierte Geräte, unsortiert, teilweise sogar mit überlappenden Adressbereichen. Mit DMX RDM genügt ein Mausklick, um das zu tun, was wir "einen DMX Bus defragmentieren" nennen: das geht schneller als Tetris und alle Geräte sind perfekt eingestellt:

  Geräteverteilung ungepatcht.... ein Klick und...

  alles ist neu gepatcht....

Und dann, nach dem Entdecken der anderen Möglichkeiten von DMX RDM (Geräte benennen, Betriebszeiten erfassen, Temperaturen und Betriebszustände überwachen etc.), geht der Spaß ja erst richtig los..... Dann sagt Ihnen ihr Pult rechtzeitig Bescheid, wenn beim Scanner "Fronttraverse 4 links" die Lampenlebensdauer erreicht ist, wenn beim Dimmer eine Sicherung ausgelöst hat, wenn ein Roadie irrtümlich das DMX-Kabel an Port 4 von Splitter 2 gezogen hat, die Nebelmaschine nur noch Fluid für 5 Minuten im Tank hat oder wenn.... oder wenn... oder wenn... Die Möglichkeiten sind atemberaubend und nahezu endlos.

 

Mehr Infos zu DMX RDM finden Sie bei unseren RDM Geräten, dem JESE GET/SET RDM Controller, und den SOUNDLIGHT RDM Kommandos.

Anwendungsbeispiele für RDM, Programmieranleitungen für unsere DMX RDM Responder und viele Informationen mehr finden Sie auf unserer RDM Präsenz www.dmxrdm.eu/rdm Schauen Sie doch mal rein!

Befehle und Antworten

Befehle und Antworten setzen sich aus jeweils drei Bytes zusammen: der Befehlsklasse (1 Byte) und der Befehls-ID (2 Bytes).



was ist....
...eine DMX Personality?
DMX Personalities kamen erst mit Movinglites auf und werden dort auch oft als "Modi" bezeichnet. Gemeint ist beispielsweise der Betrieb der Pan- und Tilt-Antriebe im 8-Bit Modus oder im 16-Bit-Modus (dann kommen nämlich zwei DMX Kanäle hinzu, die Kanalbelegung ändert sich und es ändert sich bei Personality-Wechsel also ggfs. auch der DMX Footprint).
...ein DMX Footprint?
Die Anzahl der von einem Gerät belegten (ausgewerteten) DMX Kanäle (DMX data slots).
...eine Discovery Response?
Alle RDM Telegramme beginnen - wie bei einem normalen DMX Telegramm- mit einem BREAK. Nicht so eine Discovery Response, da durch Überlagerung verschiedener, antwortender Teilnehmer Produkte entstehen könnten, die wie ein "normales" DMX Telegramm interpretiert werden könnten. Damit das nicht vorkommt, benutzt eine Discovery-Response eine Preamble (Vorspann) von 7 $FE-Bytes. Die nachfolgenden Daten werden verschlüsselt, damit das Telegramm möglichst aus ständigen Wechseln von High- und Low-Bits besteht und damit eine unbeabsichtigte BREAK-Erzeugung verhindert.
...eine Slot Info?
Bisher muß die Zuordnung der Funktion der DMX-Kanäle eines Gerätes einer Tabelle entnommen werden; Software hält meist Bibliotheken (Libraries) bereit. Verfügt des Gerät über eine Slot Info, kann es dem Controller die Nutzung des DMX Kanals elektronisch mitteilen.
...ein Label?
Eine Bezeichnung. So kann mit Befehl 0082 (DEVICE_LABEL) beispielsweise ein Text in das Gerät übertragen werden, unter dem es ansprechbar ist: z.B. "Verfolger Mitte".

Wir geben Ihnen auf unserer Homepage umfassene Informationen zum Thema DMX512:



zurück zur [SOUNDLIGHT] SOUNDLIGHT HOMEPAGE
Letztes Update: 19.08.2010 (C) SLH 1997-2010