Scheinwerfer in Aktion Wissenstransfer Veranstaltungstechnik
Copyright © Alle Rechte vorbehalten. Made by Herbert Bernstädt:  Kontakt | Impressum
Weiter (nach rechts). Zurück (nach links). Nach oben (übergeordnet). Zurück.
Fehlersuche Topologie OSI Schichten V-LAN Spanning Tree 5-4-3-Regel TCP/UDP Hardeware Adressierung
Grundlagen DMX RDM ACN Ethernet Architektur

Zurück zu:

Auf Google Lesezeichen posten
Auf Facebook posten
Auf Twitter posten
Auf Delicious posten
Auf Digg posten
Auf LiveJournal posten
Auf Newsvine posten
Auf Reddit posten
Auf Stumble Upon posten

Themen dazu:

Ethernet Protokolle

Eigenschaften und Funktionen

TCP, UDP, Multicast, Broadcast, Unicast, Multiuser, Echtzeit


Die Wahl eines Ethernet-fähigen Lichtstellpultes ist heute nicht ausschließlich von den Pultfunktionen abhängig, sondern immer mehr auch von den Funktionen, die über das Netzwerk zur Verfügung gestellt werden können. Hier ist die Grundkenntnis der wichtigsten Unterscheidungsmerkmale der Netzwerke erforderlich, wenn man eine richtige Systementscheidung treffen will.

Die unterstützten Funktionen reichen von einfachem Übertragen von DMX-Universen, Dimmerrückmeldungen, bis hin zur Übertragung von kompletten Showdaten, Dezentralisierung der Rechenleistung, bis hin zur hierarchische Mehrbenutzer-Anwendungen oder framegenauer Steuerung von Medienservern, verzögerungsfreier Ausgabe auch bei sehr großer Kreisanzahl, geschweige denn die Anbindung an andere Protokolle und deren Funktionalitäten wie VGA, MIDI. Oder Anbindung von Steuerungssystemen für Architektur oder Mediensteuerungen oder gar Integration der Bühnen und Tontechnik wie es z. B. ACN erlauben würde. Da jedes Systemhaus Funktionalität mit unterschiedlicher Priorität behandelt, sind dementsprechend verschiedene Protokolle mit unterschiedlichem Funktionsumfang auf dem Markt. Somit müsste bei der Auswahl einer Lichtsteueranlage nicht ausschließlich das Pult betrachtet werden, sondern vielmehr die Möglichkeiten, die durch das Netzwerk geschaffen werden können.

Jeder Hersteller kann eines der herausragenden Merkmale seines Protokolls mit einem Schlagwort wie z. B. Echtzeit beschreiben. Nur was bedeutet das für den Anwender? Zum Beispiel wird oft von Multicast gesprochen. Zunächst muss man wissen, dass im Ethernet ein Gerät zu einem anderen Kontakt aufnehmen kann. Dann kann ein Gerät auch alle anderen ansprechen. Anschließend merkte man jedoch, dass es aus Performancegründen durchaus sinnvoll wäre auch nur bestimmte Gruppen von Geräten anzusprechen. So wurde Multicast entwickelt, welches Informationen innerhalb von Gruppenzugehörigkeiten versendet. Hier werden also Gruppen definiert und das Netzwerk regelt bzw. ist verantwortlich, dass eine Zustellung an jedes einzelne Gerät innerhalb der Gruppe erfolgt. Dies ist bei größeren Verbünden besonders interessant, bei denen viele Daten ausgetauscht werden müssen, so wie bei Video- oder Audio-Files - damit eignet sich Multicast bestens für die Anforderungen in der Veranstaltungsbranche. Dagegen wird mit Broadcast immer an alle gesendet, dabei werden alle mit dem Datenpaket konfrontiert und alle Leitungen sind dementsprechend blockiert. Dies hat allerdings auch den Vorteil, dass nicht direkt adressierte Geräte mithören können und gegebenenfalls diese Informationen verwerten können. Aus diesem Grunde wird Broadcast gerne eingesetzt, um Netzwerk-Konfigurationen durchzuführen. Im Gegensatz dazu ist Unicast eine Sender/Empfänger-Beziehung für jedes Gerät, bzw. wenn Teilnehmer direkt untereinander Daten austauschen kann man auch von Peer to Peer sprechen oder private Transmission.

Diese Adressierungsarten können auch Auswirkungen auf das Verhalten von Switches, Routern oder Bridges haben. So werden z. B. bei Broadcast die Datenpakete an alle Ports gesendet, wodurch damit alle Ports eines Switches belegt sind und somit keine anderen Geräte über den Switch parallel verbunden werden können.

Die Eigenschaften von UDP und TCP, die beide auf der Schicht 4 des ISO/OSI-Modells angesiedelt sind, bzw. warum Multicast eigentlich nur über UDP gut arbeiten kann, erklären sich wie folgt. TCP (Transport Control Protocol) garantiert eine fehlergesicherte zuverlässige Transportverbindung zwischen zwei Rechnern. Weiterhin werden die Paketempfänge bestätigt, um bei verlorenen gegangenen Paketen erneut das Datenpaket zu senden. Das erfolgt im "Tree way Handdshake", zur Verdeutlichung:


Sender: Ich sende Daten

Empfänger: Ja sende Daten zu mir

Sender: Gut, es geht sofort los

Sender: - sendet die Daten

Sender: Ich habe fertig

Empfänger: Alles erhalten

Sender: Ich kappe die Kommunikation

Empfänger: mach doch!


Wenn dann ein Paket verloren gegangen ist, was bei großen Datenaufkommen und sehr geringen Headroom vermehrt auftritt, dann wird das verlorene Paket noch einmal gesendet, was das System zusätzlich belastet. Diese Art von Feedback und wiederholten Sendungen ist nicht Ideal, wenn an viele Stationen gesendet werden soll. UDP (User Datagram Protocol) ist wesentlich einfacher aufgebaut und verzichtet auf Bestätigungen für erfolgreiche oder nicht erfolgreiche Versendung. So gesehen könnte bei verlorenen Datenpaketen UDP ein Problem werden. Dem muss aber nicht so sein, denn die Fehlerberichtigung kann dann in der Applikationsschicht 7 stattfinden. Der Vorteil von UDP ist der schnelle Datendurchsatz, weil er auf den ganzen Overhead verzichtet. So ist der Datentransport mit UDP gerade bei sehr großen Datenmengen enorm schnell.

Eigenschaft

TCP

UDP

Ende zu Ende Kontrollrolle

ja

nein

Zeitüberwachung der Verbindung

ja

nein

Flow Control (Über das Netz)

ja

nein

Reihenfolgerichtige Übertragung

ja

nein

Erkennung von Duplikaten

ja

nein

Fehlererkennung

ja

Einstellbar

Fehlerbehebung

ja

nein

Adressierung der höheren Schichten

ja

ja

Three Way Handshake

ja

nein

Größe des Header

20-60 Byte

8 Byte

Geschwindigkeit

langsam

schnell

Belastung der Ressourcen

normal

gering

Unicast

ja

ja

Broadcast

nein

ja

Multicast

in Entwicklung

ja

Full Tracking zwischen mehreren Konsolen bedeutet einen ständigen Datenabgleich, damit die Konsolen zu jeder Zeit auf dem aktuellen Stand sind inklusive aller Showdaten. Im Havariefall ist so die zweite Konsole sofort auf dem aktuellen Stand der Show, ohne die Show erst laden oder auf den entsprechenden Cue-Übergang innerhalb einer Überblendung nachgeregelt werden zu müssen. Nebenbei bemerkt, sollte man hier den Begriff Tracking nicht mit dem Begriff Tracking-Mode verwechseln, der die Aufzeichnungsart des Lichtstellpultes beschreibt. Während die deutschen Lichtstellanlagen immer alles aufgezeichet haben, wenn Record bzw. Speichern gedrückt wurde (im englischen Sprachraum als Cue-Only-Mode bekannt), wird beim Tracking-Mode nur das Speichern nur von Veränderungen vorgenommen. Dies ist wesentlich Speicherplatz sparender, und ist zudem viel besser geeignet, um das von Moving Lights benötigte LTP-Vorgehen optimal widerspiegeln zu können. Nun aber zurück zum Thema. In einem Full Tracking Backup aufbauenden Master/Slave-System ist die Hierachie im Vorfeld so geklärt, dass bei Ausfall der Hauptkonsole unbemerkt die Havarie die Show übernimmt. Aber es werden bereits einige Kritiken an dieser Technik laut: Wenn man bedenkt, dass beide Pulte genau das Identische ausführen, dann kann es auch vorkommen, dass ein durch den Ablauf generierter Fehler sich dann naturgemäß auf der zweiten Havariekonsole fortsetzt. Somit hätte man nichts gewonnen.

Anzeige des Status der Pulte (Master / Slave) innerhalb der Session

"Multitasking Konzept" wird im Zusammenhang von Lichtstellprotokollen auch als Funktion beschrieben, bei der z. B. der Programmer an der Show arbeiten kann, während die Techniker ihre Wartungsarbeiten durchführen. Dass dabei von verschiedenen Eingabegeräten aus gearbeitet werden kann und derselbe Dimmerschrank reagieren muss, unterscheidet sich zu den bisherigen Systemen in der Art, dass beim Hochziehen eines Kreises und dem Abspeichern der Cue dieser Kreis selbstverständlich als Showkreis mitgespeichert wurde. Beim Multitasking kann der Designer seine Arbeit fortführen, während der Techniker ebenfalls seine Arbeit durchführt, ohne dass sie sich ins Gehege kommen, bzw. der zu testende Kreis beim Designer mit in der Cue abgespeichert wird. Multioperator oder Multi User bezeichnet die Fähigkeit eines Systems, bei der mehrere Programmierer auf mehreren Konsolen gleichzeitig an einer Show arbeiten können, die dann in einem einzigen Show-File gespeichert wird und dann z. B. auch nur von einer Konsole aus wiedergegeben werden kann. Dazu definiert man eine Session, zu der alle Geräte, die zu dieser Show gehören sollen, eingeladen werden (Join the session) oder wieder entfernt werden können (Leave the session) wenn z. B. die Programmierphase abgeschlossen ist und nun die Show gefahren wird. Dabei kann man die Zuständigkeiten eines Operators auch definieren und sie z. B. in verschiedene "Welten" aufsplitten. Dabei kann man einem Bediener einen bestimmten Bereich von Scheinwerfern zuordnen, für den er dann verantwortlich ist. Damit ist auch ausgeschlossen, dass er z. B. auf andere Bereiche, die sein Kollege betreut, zugreift und diese dann manipuliert, ob gewollt oder ungewollt. Aber es können auch Scheinwerfern mehrere Welten zugeordnet werden. Dabei hilft für die Klarheit wieder der Einsatz von Hierarchien.

Anzeige der verfügbaren Pulte im Netzwerk, IP-Adressierung, Prioritätenfestlegung hier in drei Klassen und Session Bildung.

Echtzeitsysteme bzw. Real-Time-Systeme definieren sich so, das bestimmte Reaktionen innerhalb eines vorgegebenen Zeitintervalles erfolgen oder Berechnungen innerhalb einer bestimmten Frist abgeschlossen sein müssen. Im Gegensatz zu Nicht-Echtzeitfähigen Systemen kann das Nicht-Eintreten des Ereignis dazu führen, dass das System vollständig verloren geht oder es zu einem schwerwiegenden Unfall kommt. Im Bereich der Hebezeuge ist dies sehr leicht nachzuvollziehen. Bei einer Sysnchronisierten Fahrt von einer Gruppe von Motoren, müssen die Antriebe Ihre Position untereinander nachregeln um eine bestimmte Tolleranzgrenze nicht zu überschreiten. Dazu müssen Sie die aktuelle Position eines jeden Zuges den anderen Zügen oder einer zentralen Überwachungseinheit übermitteln. Liegen die zum Vergleich benötigten Positionsstände nicht rechtzeitig zum Vergleich vor, muss von einer Störung ausgegangen werden, da nun man nicht mehr sicher sein kann, ob alle Züge noch innerhalb der Tolleranz liegen. Deshalb ist bei Bühnensteuerungen eine Echtzeitfähigkeit normal. Das dennoch "Echtzeitfähige" Übertragungen mit einer Busstruktur und dem Zugriffsverfahren CSMA/CD erfolgen kann, wird in der Form realisiert, indem man den eine sehr überhöhte Übertragunggeschindigkeit anwendet, die Teilnehmeranzahl begrenzt, die Übertragenen Daten in feste Protokollschemata presst, und keine anderen Geräte Zugriff auf diese Leitung haben. Unter diesen Voraussetzungen kann man mit extrem hoher Wahrscheinlichkeit ausgehen dass die Daten innerhalb der benötigten Zeitspanne dem Empfänger übermittelt wurden. Anhand diesem Beispiel wird aber deutlich, das die Topologie alleine nicht ausreicht um alle Vor und Nachteile erkennen zu können. Es spielt die Art der Zugriffmöglichkeiten bzw. der Zugriffsteuerung und die verwendeten Protokolle eine ebenso wichtige Rolle für die Performance der Netzwerktopologie.

Die Marketingfachleute der Eventbranche dehnen den Begriff ein wenig und meinen unter echtzeitfähig, wenn das DMX-Signal genauso schnell über Ethernet wiederholt wird wie es auch ohne Netzwerk vorher war. Das ist eigentlich kein Kunststück bei einer Übertragungsgeschwindigkeit eines 10BaseT-Netzwerkes, die ca. 40-mal so hoch ist, wie die des DMX-512-Protokolls auf RS-485-Basis und immerhin 400-mal schneller bei einem 100-Mbit/s-Netzwerk. Durch ein angewendetes Komprimierungsverfahren ist es sogar bei einem 10-Mb/s-Netz noch möglich 60 Universen ohne Zeitverzug zu übertragen, jedoch wird empfohlen bei über 20 Universen bereits ein 100 Mb/s Backbone zu verwenden.


Unter Backbone versteht man die Haupt-Datenübertragungsstrecke bzw. das Rückgrad eines Netzwerkes. Man versucht, um Fehlerauswirkungen möglichst klein zu halten, vom Backbone aus kleinere Segmente zu bilden, innerhalb deren dann die Endgeräte angeschlossen sind und dann erst auf den Backbone gelangen, wenn eine Verbindung von einem Segmente zum nächsten erfolgen muss. Somit sind Fehler wesentlich schneller einzukreisen als wenn jedes Endgerät direkt an der Backbone angeschlossen wären. Weiterhin kann der Informationstransfer innerhalb der Segmente bereits stattfinden, ohne dass der Backbone belastet wird. Weiterhin versucht man den Backbone so schnell wie möglich zu gestalten, um so möglichst einen reibungslosen ganzheitlichen Datentransfer zu ermöglichen, denn wie gesagt ist der Backbone so etwas wie die Stadtautobahn in Berlin. Aus diesem Grunde wird oft der Backbone auch als Glasfaserleitung ausgeführt, wobei ganz nebenbei auch längere Strecken problemlos bewältigt werden können.

Es werden aber heute bereits schon wesentlich größere und DMX-Universen verschlingende Installationen gefahren. Hierbei tritt ein anderer Effekt auf, wenn dann mal 40 DMX-Universen in der Show eine Überblendung fahren müssen. Nutzt man nur einen Zentralrechner, der in der Regel das Lichtstellpult ist, so ist verständlich, dass je mehr Kreise er bei einer 16-Bit-Überblendung berechnen und auf das Ausgabeboard schicken muss, die Zeitdifferenz wo der erste Kreis von null auf 100 % springt gegenüber dem 20.480-ten Kreis länger wird. Es entsteht eine Verzögerung, die in der Show sehr unschön anzusehen ist, wenn das erste Moving Light sich bereits in Fahrt befindet, während das letzte Moving Light, ungünstig auf der gegenüberliegenden Bühnenseite platziert, sich erst später anschickt, in die Gänge zu kommen. Richtig auffällig wird dies jedoch bei den kanalhungrigen LED-Bitmap-Walls, wenn das Bild sich eben nicht schlagartig ändert, obwohl dies die Designanforderung war. Abhilfe schafft dabei nicht der Einsatz des 100-Mb/s-Netzwerks, da der Rechner ja die Informationen nicht rechtzeitig ausgeben kann. Zur Lösung solcher Aufgaben benötigt man dann parallele Rechnerkerne oder dezentrale Rechnersysteme. Werden dezentrale Strukturen eingesetzt, so ist es wieder entscheidend, ob das Netzwerk diese eine skalierbare Erweiterung der Rechnerleistung zulässt. Jedoch muss auch sichergestellt werden, dass bei Einbindung von z. B. Medienservern zusammen mit den Bitmap-LED-Wänden das Gesamtbild synchron agiert. Dazu kann man über das Ethernet noch einen Zeitstempel senden bzw. diesen Zeitstempel in das Lichtstellprotokoll mit einbinden. Daraufhin können sich die Maschinen synchronisieren und man könnte dann auch mehrere Videoserver framegenau steuern.

Denn bei der Entscheidung handelt es oftmals um einen Systementscheid, denn die Anbindung von Fremdprodukten anderer Hersteller ist oftmals nicht mit gleichem Funktionsumfang möglich. Auch hier kann man Parallelen mit der Zeit vor DMX-512 erkennen, als jeder Hersteller mit seinem eigenen Protokoll der Konsole sich auch die Bindung an seine Dimmersysteme und Zubehöre sicherte. Heute jedoch sind über Zusatzgeräte wie Medienserver, Visiualisierung, LED-Matrixen, Dimmer- oder sonstige Rückmeldungen, Hausfunktions-Anbindung und vieles mehr wesentlich größere Auswirkungen im Bereich des Systementscheids spürbar und sollten dementsprechend Gewichtung erhalten.





Echtzeit, Multiuser, tracking, full backup tracking, Dimmerrückmeldung, framgenau, Trackingmode, session, leave, echtzeit, real time, Backbone, join, welten,Übertragungsgeschwindigkeit, Netzprotokoll, UDP, TCP/IP, Kommunikation, Broadcast, Unicast, Multicast, Multicast, Kreise, Bit, Refreshrate, Universen, HTP, LPT, LoTP, Patchsoftware, Knoten, File, Server, Node,  RDM,  Nodes, Videoserver, framegenau, Zeitstempel, Medienservern, Bitmap, Backbone, Welten, Hierarchien, session, Multiuser, Echtzeit, Tracking, Full, Backup, Master/Slave, Multicast, Broadcast, Unicast, TCP, UDP, Veranstaltung, Herbert, Bernstädt, Herbert Bernstädt, hbernstaedt, Bernstaedt, Institut, angewandte, Veranstaltungstechnik

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

Switch mit Optokoppler, ideal zum Aufbau einer Backbone. In der Praxis hat sich gezeigt, dass Lichtleitfaserkabel sich als Verbindung FOH zur Bühne sehr bewährt haben, da auch mechanische Extrembelastungen wie Überfahren mit einem Gabelstapler dem Kabel im ausgerollten Zustand keine Beschädigung hervorgerufen hat. Gleichzeitig ist man zum FOH potenzialfrei und kann sich keine elektromagnetischen Störungen einfangen. Nur das Ein- und Ausrollen sollte man Stagehands seines Vertrauens machen lassen oder selber zur Hand gehen, denn die Steckverbinder sind mit Vorsicht zu genießen und das Kabel ist empfindlich gegen Knicken. Und zu guter Letzt kann man die Frage mit ja beantworten, wenn es heißt "Darf es etwas mehr an Wegstrecke bis zum FOH sein?"