Ethernet-Netzwerk: ACN-Protokoll für die Lichtsteuerung
von Herbert Bernstädt,
ACN ist als kommendes Lichtsteuer-Übertragungsprotokoll in aller Munde. Es sind durchaus Parallelen zur Historie von DMX und der Entwicklung von ACN zu erkennen. Zurzeit der Wandlung von DMX zu einem Standard-DMX waren bereits viele unterschiedliche digitale und analog-multiplexe Protokolle von den verschieden Firmen entwickelt worden. Dies ist heute bei den Ethernet-basierten Protokollen ebenso. Damals wie heute werden spezielle firmeneigene Protokolle weiterhin gepflegt, da sie
eine bereits sehr hohe Verbreitung erfahren haben, wie z. B. das ArtNet, und
beinhaltet dies deutliche Performancevorteile für bestimmte Funktionen, wie z. B. beim MA-Net.
Bis heute haben sich hartnäckig z. B. D54-Verbindungen gehalten, da durch die analoge Wertevermittlung alle Zwischenstufen darstellbar sind, im Gegensatz zum 8-Bit-Wertevorrat eines DMX-Kanals. So sei hier vorweggenommen, dass nun mit dem ratifizierten und zertifizierten Standard-ACN eben nicht alle anderen Protokolle in die Zweitklassigkeit verdammt werden.
Anzeige
Im Folgenden werden die Möglichkeiten und Rahmenbedingungen von ACN behandelt – auch um dieses Protokoll mit den bereits behandelten, firmeneigenen Ethernet-basierten Protokollen vergleichen bzw. abschätzen zu können. Denn das ist die Grundvoraussetzung für eine richtige System-Kaufentscheidung.
ACN
ACN wurde in der Entstehungszeit zunächst als Advanced Control Network bezeichnet und dann in Architecture for Control Networks umbenannt.
ACN ist ein auf Ethernet basiertes Netzwerkprotokoll, das von der ESTA (Entertainment Services and Technology Association) mit der Kennung BSR E1.17 (BSR=Britisch standard regulation, ähnlich unserer DIN Bezeichnung) entwickelt wurde. ACN unterstützt ein einfaches Netzwerk für unterschiedlichste Informationen der Beleuchtungstechnik, muss aber nicht nur auf das „Licht“ beschränkt bleiben. Es sind auch Anbindungen für Bühnen-, Pyro-, Video- und Tonsteuerungen angedacht.
Damit neu entwickelte Geräte mit neuen Funktionen auch in Zukunft in dem Protokoll berücksichtigt werden können, wird eine DDL (Device Description Language) Datei eingeführt. In dieser Datei werden die Möglichkeiten dieses Geräts definiert und über das Netzwerk auch den Steuerkonsolen mitgeteilt. Die Steuerung kann somit die neuen Funktionen aufnehmen und dem Anwender zur Verfügung stellen, ohne dass er das neue Gerät erst neu anlegen muss. Somit wird auch deutlich, dass zukünftige Produkte, die ACN nutzen wollen, nicht auf Beleuchtungstechnik beschränkt bleiben müssen. Das Protokoll könnte sich im Laufe der Zeit soweit etablieren, dass man dann von einem Veranstaltung-Steuerungs-Protokoll sprechen wird, was jetzt jedoch noch reine Spekulation ist.
Bleibt zunächst festzuhalten, dass sich ACN auf der Schicht 7 des ISO/OSI-Schichtenmodells des Ethernets befindet sowie natürlich Hersteller- und Hardware unabhängig ist. Das führt soweit, dass ACN nicht zwangsweise einen RJ45-Steckverbinder benötigt, da die Hardwareseite wie oben beschrieben (Schichtenmodell) gar nicht definiert wird. ACN kann genauso über FireWire, Bluetooth, Wireless LAN, Glasfaser oder Sonstiges, was über das ein TCP/IP-Protokoll arbeitet, übertragen werden.
Die DDL (Device Description Language)regelt Aufbau und Inhalt der Daten, die übertragen werden sollen. Das DMP (Device Management Protocol) tauscht Anwendungsdaten zwischen einzelnen Geräten aus und der SDT (Session Data Transport) regelt, welche Geräte miteinander zu kommunizieren haben. (Bild: Herbert Bernstädt)
Zunächst schrecken Begriffe wie DDL, SDT oder DMP ab – zumindest wenn man am DMX-Gedanken verankert ist, dass das Pult doch nur die Moving Lights da hinten ansteuern soll. OK, es sind viele geworden im Laufe der letzten Jahre. Man möchte doch nur DMX von A nach B übertragen und warum kann das nicht so einfach sein wie beim ARTNet: zehn DMX Universen rein und verteilt wieder ausgegeben.
ACN geht aber einen gewaltigen Schritt nach vorne in die Zukunft, denn mit Dateien, die einer Konsole erst einmal mitteilen, was für Daten übertragen werden und was diese Daten bezwecken sollen, ist man mit Begrenzungen wie 8-Bit-Dimmwert oder 16 Bit bei Pan und finePan nicht am Ende. Viel mehr noch: es wird nie ein Ende der Definitionen geben, da der Hersteller immer neue Definitionen kreieren kann. So ist bei 32 oder 64 Bit das Ende nicht erreicht, man könnte auch Fließkommazahlen, Buchstaben, Zeiten oder Winkelcodierungen oder den jeweiligen Wertebereich und die Bedeutung, ob Effektdiskstellung im Strahlengang, Flammenhöhe eines Pyroeffekts oder was sonst noch was bedeutet, definieren und übertragen. Es wäre auch durchaus denkbar, dass man nicht mehr Pan- und Tilt-Werte überträgt, sondern nur noch die Vektoren oder Zielkoordinaten im dreidimensionalen Raum, wenn man zuvor die Örtlichkeit des Moving Lights angegeben hat. Das System kann in beinahe jede Größe hin beliebig skaliert werden. Damit werden Investitionen langfristig gesichert.
Natürlich ist nicht nur die Dimmerrückmeldung durch das bidirektionale Protokoll einfach zu realisieren, wobei die zurückgemeldeten Werte im Protokoll definiert werden (wie z. B. Lüfterzustand oder Modultemperatur). So kann z. B. die Dimmerrückmeldung von einem Pult ausgelesen werden, das ein anderer Hersteller entwickelt hat. Man ist nicht mehr im System der Hersteller gefangen. Hier sei aber nebenbei erwähnt, dass für die Rückmeldung bei Moving Lights bereits ein Patent vergeben wurde. Inwieweit mit dem neuen Protokoll eine Einigung mit dem Patentinhaber erfolgen wird, ist noch ungewiss.
Ein weiterer Vorteil einer so offenen Struktur ist, dass bei neu hinzugefügten Geräten ein Controller die Informationen des Geräts aufnimmt, mit seinen Ressourcen und den angeschlossenen Ressourcen abgleicht und demnach eine automatische Konfiguration wie Adressierung oder automatische Lüfter-Speedregelung des neuen Geräts entsprechend den bereits anderen installierten 23 Stück vornimmt. Auch Dritthersteller können von der offenen Datenstruktur partizipieren und praktische Zusatzgeräte entwickeln, die mit den verfügbaren Daten wie eine Plug-in Funktion erweitern können. Es wäre z. B. vorstellbar, Effektgeräte für komplexe Farbverläufe einzuschleifen, oder einen Color-Picker, wenn die Konsole diese Funktion nicht unterstützt. Hier sind auch viele softwarebasierte Shareware-Programme für die Zukunft denkbar. Und wenn Hebezeuge die gleiche Infrastruktur wie das Protokoll nutzen, so sind Synchronisierungen einfach zu realisieren. Wobei aber auch definiert werden kann, dass die Licht- und Bühnenautomation weiterhin vollkommen getrennt arbeiten und Informationen der „Licht-Seite“ nicht das Bühnenmaschinerie-System belasten und umgekehrt. So sind „Substrukturen“ mit ACN durchaus aufzubauen.
In einem ACN-System wird ein Controller eine „Get/Set_property“-Sendung zu den Geräten absetzen, die im DMP Protokoll definiert wurden. Diese Sendung wird mit dem SDT-Protokoll transportiert, das die Übersicht der Verfügbarkeit, Onlinestatus und die Gruppierungsstruktur der Geräte beinhaltet. Alle DMP- und SDT-Sendungen werden in individuelle Protokoll Data Units (PDUs) eingebettet, die dann über UDP und das Ethernet übermittelt werden. Neue Geräte werden über das feste Protokoll SLP erstmals in Empfang genommen. Deren besondere Geräteeigenschaften mit neuen Funktionen werden dann über die DDL definiert und stehen somit den Kontrollgeräten zur Verfügung.
Netzwerksteuerung
Mit dem ACN-Protokoll kann das Netzwerk initialisiert, konfiguriert und gesteuert werden. Bestimmte Typen von Lichttechnikdaten sind bereits im Protokoll standardisiert worden und können adressiert geroutet werden.
Fazit
Bei allen Vorteilen und Erleichterungen, die ACN den Anwendern bringt, ist dennoch ein wenig Vorsicht walten zu lassen. Viele Geräte sind ACN-Ready, jedoch versteht jeder einzelne Hersteller wieder etwas Anderes darunter. Auf der einen Seite bedeutet dies, dass nur noch die Software freigegeben werden muss und das Gerät läuft auf ACN. So war bereits Ende 2003 bei der ESTA ein Verbund von einem ETC-Dimmerrack, Strand 300 Konsole, Horizon Playback Einheit mit Faderbank, ein Martin MAC 250, Pathport und Sandnet Node zu sehen. Auf der anderen Seite der Skala ist der RJ45 Ethernet-Steckverbinder noch nicht einmal mit dem Mikrocontroller des Geräts verbunden, geschweige denn die Software dafür geschrieben worden. So wird gerade in der Anfangszeit oftmals die Situation auftreten, dass z. B. das Lichtstellwerk nicht mit dem Moving Light der Firma Y kommunizieren will, obwohl alles auf ACN ausgerichtet ist – weil hierzu z. B. noch die aktuelle Software auf die Konsole aufgespielt werden muss und gleichzeitig die Firmware des Moving Lights noch Probleme bereitet.
Aber auch hier hatten wir vor ca. 20 Jahren, sogar bis heute noch Probleme beim DMX, als die Breakzeit z. B. 44 µs oder 88 µs betrug. Selbst wenn nur 72 Kreise übertragen wurden, brachte das manchen Dimmer zum Straucheln. So ist es vorteilhafter bei einer neuen Technologie wie ACN, das Zusammenspiel vorher einmal zu testen, bevor man „auf der Straße“ ist. Denn nur dann ist ein rettender Plan B noch einfach zu realisieren.
Mehr Themen zu Netzwerktechnik und Protokollen werden auf folgenden Seiten behandelt:
