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.
|
