Scheinwerfer in Aktion
Weiter (nach rechts). Zurück (nach links). Nach oben (übergeordnet). Nach unten (untergeordnet). Zurück.
Grundlagen DMX RDM ACN Ethernet Architektur
Physik Anwendung Leuchtmittel Scheinwerfer Energie Dimmen Signale Pulte

Zurück zu:

Themen dazu:

Auf Delicious posten
Auf Digg posten
Auf LiveJournal posten
Auf Newsvine posten
Auf Reddit posten
Auf Stumble Upon posten
Infos zur Lichttechnik von Herbert Bernstädt
Copyright © Alle Rechte vorbehalten. Made by Herbert Bernstädt:  Kontakt | Impressum

Wissenstransfer Veranstaltungstechnik

Ethernet Netzwerk: ACN


ACN ist in aller Munde als kommendes Lichtsteuer-Übertragungsprotokoll

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

ACN wurde in der Entstehungszeit zunächst als Advanced Control Network bezeichnet und dann in Architecture for Control Networks umbenannt.




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

Zurück. Nach oben (übergeordnet). <--. Zurück (nach links). Weiter (nach rechts).