Es sind durchaus parallelen zur Historie von DMX und der Entwicklung von ACN zu erkennen.
Zurzeit in der Wandlung von DMX zu einem Standard DMX waren bereits viele unterschiedliche
Digitale und Analogmultiplexe Protokolle von den verschieden Firmen entwickelt worden.
Dies ist heute bei den Ethernet basierenden Protokollen ebenso. Damals wie heute
wird es spezielle Firmeneigne Protokolle weiterhin gepflegt werden, da sie
a) eine bereits sehr hohe Verbreitung erfahren haben wie z.B. das Artnet, oder
b) beinhaltet deutliche Performancevorteile für bestimmte Funktionen wie z.B. das
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-Kanales. So sei hier vorweggenommen, das nun mit dem ratifizierten und
zertifizierten Standard ACN eben nicht alle anderen Protokolle in die Zweitklassigkeit
verdammt werden. Im folgenden werden die Möglichkeiten und Rahmenbedingungen von
ACN behandelt, auch um dieses Protokoll mit den in der folgenden Serie behandelten
firmeneignen Ethernetbasierenden Protokollen vergleichen bzw. abschätzen zu können
- der Grundvorraussetzung für eine richtige System-Kaufentscheidung.
ACN ist ein auf Ethernet basierendes Netzwerkprotokoll das von der ESTA (Entertainment
Services and Technology Association) mit der Kennung BSR E1.17 (BSR=Britisch standard
regulation, ähnlich unserer DIN Bezeichung) 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ätes 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 das zukünftige Produkte die ACN nutzen wollen nicht auf Beleuchtungstechnik
beschränkt bleiben müssen. Es könnte im laufe der Zeit das Protokoll soweit etablieren,
das man dann von einem Veranstaltung-Steuerungs-Protokoll sprechen wird, was jedoch
jetzt reine Spekulation ist. Bleibt zunächst festzuhalten das ACN auf der Schicht
sieben des ISO/OSI-Schichtenmodells des Ethernets befindet sowie natürlich Hersteller-
und Hardeware unabhängig ist. Das führt soweit, das ACN nicht zwangsweise ein RJ
45 Steckverbinder benötigt, da die Hardewareseite wie oben beschrieben (Schichtenmodell)
gar nicht definiert wird. ACN kann genauso über Firewire, Bluetouth, Wireless LAN,
Glasfaser oder sonstiges über das ein TCP/IP Protokoll arbeitet übertragen werden.
Zunächst wird man bei Begriffen wie DDL, SDT oder DMP abgeschreckt wenn man dem DMX-Gedanken
verankert ist dass man doch nur mit dem Pult die Movinglights da hinten ansteuern
will. OK es sind viele geworden im laufe der letzten Jahre. Man möchte doch nur DMX
von A-B übertragen und warum kann das nicht so einfach sein wie beim ART-Net - 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 von 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 Bit oder 64 Bit das Ende nicht
erreicht, man könnte auch Fließkommerzahlen, Buchstaben, Zeiten oder Winkelcodierungen
oder jeweiligen Wertebereich und die Bedeutung ob Effektdiskstellung im Strahlengang,
Flammenhöhe eines Pyroeffektes oder man sonst was bedeutet, definieren und übertragen.
Es wäre auch durchaus denkbar das 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 Movinglights 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, das für die Rückmeldung
bei Movinglights bereits ein Patent vergeben wurde. Inwieweit mit den neuen Protokoll
eine Einigung mit dem Patentinhaber erfolgen wird ist noch ungewiss. Ein weiterer
Vorteil einer so offenen Struktur ist, das bei neu hinzugefügten Geräten ein Kontroller
die Informationen des Gerätes aufnimmt, mit seinen Resourcen und den angeschlossenen
Resourcen abgleicht und demnach eine automatische Konfiguration wie Adressierung
oder automatische Lüfterspeedregelung entsprechend den bereit anderen installierten
23 Stück, des neuen Gerätes vornimmt. Auch Dritthersteller können von der offnen
Datenstrucktur partiziepieren und praktische Zusatzgeräte entwickeln, die mit den
verfügbaren Daten wie ein Plug in Funktionen 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 Softwarebasierende
Shareware Programme für die Zukunft denkbar. Und wenn Hebezeuge die gleiche Infrastrucktur
und Protokoll nutzen, so sind Synchroniesierung einfach zu realiesieren, wobei aber
auch definiert werden kann das die Licht und Bühnenautomation weiterhin vollkommen
getrennt arbeiten und Informationen der "Licht-Seite" nicht das Bühnenmaschineriesystem
belasten und umgekehrt. So sind "Substrukturen" mit ACN durchaus aufzubauen.
In einem ACN System wird ein Kontroller eine "Get/Set_property" Sendung zu den Geräten
die im DMP Protokoll definiert wurden, absetzen. Diese Sendung wird mit dem SDT Protokoll
transportiert, das die Übersicht der Verfügbarkeit, Onlinestatus und die Gruppenierungsstrucktur
der Geräte beinhaltet. Alle DMP und SDT Sendungen werden in individuelle Protokoll
Data Units (PDUs) eingebettet, die dann über UDP und dem Ethernet übermittelt werden.
Neue Geräte werden über ein das festes Protokoll SLP erstmals in Empfang genommen.
Deren Besonderen Geräteeigenschaften mit deren neuen Funktionen werden dann über
die DDL definiert und steht somit dien 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 Anwender bringt ist dennoch ein
wenig Vorsicht walten zu lassen. Viele Geräte sind ACN-Ready. Jedoch versteht jeder
einzelne Hersteller etwas anderes darunter. Auf der einen Seite bedeutet dies, das
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 Scala ist der RJ45 Ethernetsteckverbinder
noch nicht einmal mit dem Microkontroller des Gerätes verbunden, geschweige denn
die Software dafür geschrieben worden. So wird gerade in der Anfangszeit oftmals
die Situation auftreten, das z.B. das Lichtstellwerk nicht mit dem Movinglight 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 Firmeware des Movinglights noch Probleme bereitet. Aber auch hier hatten wir
vor ca. 20 Jahren, sogar bis heute auch Probleme beim DMX, als die Breakzeit z.B.
44 µsek. oder 88 µsek. betrug. Selbst wenn nur 72 Kreise übertragen wurden, brachte
das manch 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.
ACN, Advanced Control Network, Lichttechnik, Netzwerkprotokoll, BSR E1.17, DDL, DMP,
SDT, Netzwerksteuerung, Rückmeldumg, dimmer, SLP, Veranstaltung, Herbert, Bernstädt,
Herbert Bernstädt, hbernstaedt, Bernstaedt, Institut, angewandte, Veranstaltungstechnik