Scheinwerfer in Aktion Wissenstransfer Veranstaltungstechnik
Copyright © Alle Rechte vorbehalten. Made by Herbert Bernstädt:  Kontakt | Impressum
Weiter (nach rechts). 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:

Netzwerk - Monitoring und Fehlersuche

Da ein Netzwerk ungleich viel mehr Aufgaben erledigen kann, und meist auch wesentlich größere Außmasse annimmt, ansonsten hätte man ja die standardmäßige DMX512 Verkabelung vorgezogen, ist durch die Komplexibilität die Fehlersuche auch ein wenig aufwendiger.

Auch sollte man noch über die Übertragungscharakteristika zwischen Broadcast (UDP) und Peer to Peer bzw. Multicast (TCP) unterscheiden, da sie im Netzwerk unterschiedliche Erscheinungsbilder beim Monitoring bilden. Aber nun erst mal zurück an die Wurzel:

Netzwerkfehler erkennen

Der Einfachste Fehler den man Suchen Kann, ist natürlich ein Fehler, der konstant vorhanden ist. Man erkennt sofort, das man den Fehler behoben hat. Dagegen sind Fehler die nur sporadisch auftreten wie ein Wackelkontakt nicht nett.

So kann z.B. eine Ruckelndes oder stehendes LED-Bild zwar vorgaukeln, das das Netzwerk in Ordnung ist, da ja alle Geräte miteinander kommuniezieren denn es ist ja ein Bild zu sehen. Dennoch ist hier z.B. das Ruckeln oder gar das Einfrieren ein typisches Anzeichen dafür das der Datendurchsatz im Netzwerk nicht stimmt. Medienserver und Pult sind warscheinlich nicht das Problem.

Auch wenn die einzelnen Netzwerkstationen mal miteinander verbunden sind und dann mal nicht, ist das warscheinlich kein Pultproblem, sondern ein Netzwerkproblem. Am Beispiel von MA-Net kann man z.B. sagen das dort ein "Bin noch am Leben" Signal über das Netz gesendet wird. Dies wird benötigt, damit das System erkennt, wenn eine Komponente ausgefallen ist, um dann wie beim Ausfall eines rechnenden Netzwerkknotens (NDP) die Gegenmaßnahmen zur Neuverteilung der Rechenleistung auf anderer rechnende Netzwerkknoten zu veranlassen, damit das System Lichtsprungfrei weiterarbeitet.

Eine Systematische Suche kann man anhand des OSI-Schichtenmodelles vornehmen und sich Schicht für Schicht dem Problem nähern. Dabei hat sich gezeigt, das es oft sinnvoll ist nicht in der Anwendungsebene zu beginnen, zumal dort auch die meisten Möglichkeiten vorhanden sind etwas zu verstellen, sondern besser man startet unten von der Basis aus.

Um sicher von kleinem auf größere Systeme zu "wachsen", kann man auch erst mal zwei Gerät mit einem Crossoverkabel verbinden. Laufen diese beiden Geräte einwandfrei, kann man dann sein System schrittweise erweitern. Mann fügt dann den Switch ein. Achtung, Crossoverkabel weglegen und nun normale Patchkabel verwenden. Mit einem Switch hat man auch bereits ein Tool zur Hand, mit dem man die Ports betrachten kann und kann damit bereits auf den Zustand der Kabel rückschießen. Aber auch die Status-LEDs an den Ports zeigen an, ob auf der Hardewareseite alles in Ordnung ist. Die LEDs an den Ports bzw. direkt neben den Ethernetsteckverbindern, der Ethernetkarten zeigen sehr zuverlässig die Hardewarseitige Verbindung an. Es ist kaum ein Fall bekannt, das diese LED-Anzeige mal defekt war. Also die LEDs der Netzwerkkarten kontrollieren, ob sie erwartungsgemäß blinken. Wenn trotz funktionierender Kabel die Geräte nicht miteinander kommuniezieren kann man die Adressierung Prüfen. Eigentlich alles, was man beim DMX auch gemacht hat. Nur prüfen wir nun den IP-Adressraum. Die IP-Adressen und die Subnet Mask sind bei den angeschlossenen Geräten zu erfragen, oder bereits über Funktionen vom Switch. Dann muss man die Switcheinstellungen kontrollieren ob z.B. ein V-LAN eingestellt ist oder eine Strom-Protection oder oder. Bzw. ob die eingestellten Ports für V-LAN 1 auch mit den Geräten für das V-Lan angeschlossen ist. denn jetzt darf man nicht mehr alles einfach in den Switch reinstecken wie es kommt, sondern muss die Ports benutzen die zum eingestellten virtuellen LAN zugehören. Manchmal hilft auch ein Reset am Switch oder das Einstellen der Werkseinstellung (default-werte) um das Problem zu lösen. Letzendlich auch den Switch mal austauschen. Schließt man einen Laptop mit einem Windows-Betriebssystem an, so liefert Windows zwei Programme mit, die auf unterster Ebene die Kommunikation überprüfen können.

Mit Ipconfig kann man die Einstellungen des eigenen Rechners auslesen und mit mit Ping kann man die einzelnen Verbindungen überprüfen. Ist die Hardeware OK, folgt die Software und die Configurationen, die so vielfältig und schnell geändert werden, das dies hier nicht erläutert werden kann.



Werden Kabel im Installationsbereich verlegt werden, erfolgt danach eine Messung des Kabels. Die Messergebnisse sind dann in der Zertifizierung wiedergegeben. Es gibt verschiedene Stufen wie Cat 3, Cat 5, Cat 5e usw. Wenn das Kabel länger als 100m ist, wird es automatisch zum Cat 3 Kabel also ein Kabel für maximal 10 MBit/s. Interessant ist hierbei die Tatsache das für flexible Kabel wie wir Sie in der Eventtechnik nutzen, die Segmentlänge nicht 100m beträgt. Die Ursache liegt darin, das man bei festverlegten Kabeln mit starren Adern, die aufgrund der starren Adern bessere elektrotechnische Eigenschaften aufweisen, eine 90m strecke definiert hat, an deren Enden je ein 5m flexibles Verbindungskabel angebracht werden kann und somit 100m im ganzen erfolgt. Im fliegenden Betrieb mit flexilblen "Ethercon-Kabeln" können wir mit den flexiblen Litzen nur bis ca. 75m gehen, wenn man bei 100Mbit/s keine Paketverluste erleiden will. Werden aufgrund zu langen Kabelwege zu viele Pakete "verschluckt", dann kann z.B. das bewegte Bild einfrieren oder springen. Das sind auch die Art von Fehlern, bei denen dann sporadisch mal einige Geräte von einer Session abspringen. Benötigt man dennoch größere Strecken kann man immer noch auf Glasfaser gehen. Die Glasfaserklasse kann 550m schaffen im Multimode-Betrieb ohne Repeater. Im Singelmode sind auch 2 Km bis 10 Km überbrücken von Gerät zu Gerät und damit sind auch die größten Themenparks wie Disney World zu händeln. Auch ist auf Baustellen die Unsitte zu beobachten das Kabel für Festverlegung eingesetzt werden. Gut deren elektrotechnische Eigenschaft ist zwar besser, aber spätestens nach zwei mal aufwickeln ist der Kabelbruch einer Ader doch sehr wahrscheinlich. Mann sollte Kabel für die Veranstaltungstechnik in Roadtauglicher Ausführung einsetzen wie sie z.B. von Connex oder Sommer. Bei Patchkabeln muss man auch damit rechnen, das da jemand mal auf das Kabel tritt und bei diesen Querschnitten ist das sehr leicht beschädigt. Auch der Steckverbinder sollte dann als Ethercon ausgeführt sein.





Es ist schon erstaunlich, das Bei Produktionen für 10.000  und mehr Netzwerkfähige Pulte zusammengescahltet werden, für 100.000  LED-Matrixwäde aufgestellt werden, 300 Movinglights dabei stehen, und das alles soll koodieniert werden mit einem Zentralen Gerät für den Datenduchsatz, nennen wir es mal switch, der dann nicht mehr als 50  kosten darf und den man sich beim Discounter kauft, denn dort hat man Ihn ja günstig gesehen. Das Damit die Show auf die Nase fallen wird ist vorprogrammiert. Abgesehen das diese Plasik-Switche nur das Heimnetzwerk brauchbar sind, aber für unsesre Zwecke hofnungslos überlastet sind, abgesehen von dem schlecht abgeschirmten und nicht 19" fähigen Plasitikgehäuse und separaten Steckernetzteil made in china für besonders wenig Geld. Hier muss man die Verantwortlichen ruhig mal schütteln, denn ein ordenlicher managebarer Switch der auch einen ordentlichen Trafik auf dem Backbone erlaubt kostet auch nicht mehr als 400  und das ist immer noch ein Bruchteil der Pulte oder LED-Wände oder Movinglights die an den Start gehen. Bei großen professionellen Shows werden oft Procurve Switch von HP eingesetzt.

Diesen kann man über Ethernet mit einem Laptop verbinden und per Browser die Konfiguration komfortabel einstellen und viel mehr noch, man kann sehen was dort auf dem Switch so alles angeschlossen ist und mit welcher Geschwindigkeit die Übertragung erfolgt. Wird z.B. an einem Port 10M/Bit angezeigt, obwohl dort eignetlich ein 100M/Bit Gerät sein sollte, so Kann man davon ausgehen, das das Kabel zu viel dämpft, also defekt ist, oder das der Prot am Switch ein Problem hat, nächsten Port probieren. Natürlich muss man auch wissen mit welcher Geschwindigkeit das eingesetzte Gerät arbeiten muss. Z.B. der Einsatz eines alten Artnet-Node der auf 10MBit/s arbeitet ist hoffnungslos überfordert bei einem 100MBit/s MA-Net, da er gar nicht so viele Informationen ignorieren kann, wie er müsste. Auch der Wille das 100 MBit/s Netzwerk über W-Lan zu übertragen ist nicht von Erfolg gekrönt.

Für den Procurve Switch ist auch ein Management-Programm verfügbar das sehr viele Analyse-Funktionen beinhaltet. Man kann anhand des Traffict z.B. erkennen, wenn Artnet z.B. alles mit seinen Bradcast belegt und ein parralelles Protokoll wie z.B. MA-Net nicht rechtzeitig dazu kommt sein Lebenszeichen zu versenden. Dann macht es z.B. Sinn beide Protokolle auf getrennten Wegen zu übermitteln. Dazu benötigt man nicht unbedingt ein weiteren Switch, sondern es reicht ein V-LAN einzurichten.

Um bei Problemen wenigsten festzustellen das bis zur TCP/IP Ebene alles funktioniert, liefern Windowssysteme über das Dosfenster Diagnoseprogramme an. Mit Ipconfig kann man die Einstellungen des eigenen Rechners auslesen.

Mit Ping und der Adresse des zu testenden Pultes erhält man vom Testobjekt ein Replay. Hat man dieses erhalten weiß man das die Hardeware OK ist. Ansonsten hilft zur Fehlereingrenzung auch ein Blick auf die Blinkenden Netzwerkkarten LED´s.

Eine Freeware die es in sich hat und ungemein hilft Problemen im Netzwerk aufzuspüren ist Etherreal. Die Anleitung ist auch unter Wikepedia abgelegt. Man sollte sich frühzeitig mit diesem Programm auseinander setzen, damit man dann anschließend im Problemfall auch weiss was man tut, denn es wird alles Protokolliert, und dann muss man wissen welche Protokolle für was benötigt wird.

So kann man die Zeitdifferenz der Übertragung zwischen Universe 1 und 121 sehen, wobei die Zeitdifferenz natürlich eine endliche Zeitspanne ist, aber immerhin nur so klein sein darf, das dass menschliche Auge diese Verzögerung nicht wahrnimmt. Der Protokoll-sniffer geht dagegen sehr tief in die Netzwerk Stacks im Rechner und dann sollte man Filter für die Protokolle wie Artnet, ETC Net usw. angelegt haben, da ansonsten sämtliche Einträge die in die Tausende gehen angezeigt werden. Dagegen benötigen wir nur die Informationen der Artnet oder MA-Net Pakete. Um an die Protokolle heranzukommen muss man den Kontakt zu den Herstellern suchen, die dies bereits anbieten, zwar nicht alle aber immerhin von den wichtigsten sind Sie verfügbar. Aber mann kann sich auch über Porttabellen weiterhelfen, bei denen eine Zuordnung welcher Port z.B. Multicast zugeordnet ist, angezeigt wird. Daraus könnte man ja zur Not auch seinen eignen Filter bauen.


Bei schwer aufzufindenden Fehlern,benötigt man ein Netzwerk-Analyse-Messgerät wie z.B. das Fluke networks EtherScope Serie II aus der 8.000,00   Klasse. Das Gerät arbeitet ähnlich wie Etherreal ist aber jedoch vollkommen unabhängig von vorhandener Hardeware und jederzeit einsetzbar. Man erhält darüber hinaus noch eine Bandbreitenauslastung in Prozent angezeigt und kann nach Protokollen sortieren um z.B. zu sehen das an dieser Stelle ein Broadcaststurm vorhanden ist der das Netzwerk einfach lahm legt. Broadcast ist ja eine typische Artnet-Eigenschaft, und so kann man vermuten das der Medienserver der das Pixelmapping ausgibt auf den falschen Port oder Switch gesteckt wurde.











Wurde dann das "Bin noch am Leben" Signal aufgrund eines Netzwerkfehlers zu spät gesendet, meldet das Pult das das Gerät die Session verlassen hat. Somit vermutet man das das Gerät das Problem darstellt und nicht das Netzwerk, denn das hat ordnungsgemäß eine Meldung veranlaßt.

Auch wenn man ein Stabiel stehendes Netzwerk aufgebaut hat, kann es vorkommen, das im Laufe der Zeit (der fortlaufenden Programmierung der Show) plötzlich ein Ruckeln bei den Überblendungen einstellt oder Geräte sich ab- und wieder anmelden. Auch hier wind weniger die Geräte selbst nicht gestört, sondern durch das arbeioten an der Show werden die Showdateien die Übertragen werden müssen immer größer. Und so kann es vorkommen, daszu beginn das Showfile der Anlage und die Übertragung von 8 DMX-Universen über Artnet einwandfrei funktioniert haben. Aber nachdem das Showfile so groß geworden ist und evtl noch ein Par LED-Panele noch dazugekommen sind , benötigt dies zuviel Übertragungszeit zusammen mit der Artnetübertragung und das Netzwerk kann dann einbrechen.


Ein Kabel mit Leiterbruch oder verdrehten Kabeln ist schnell mit einem Durchgangsprüfer wie abgebildet schnell getestet.

Einfachster preiswerter Durchgangstester entdeckt Kabelbrüche Crosskabel und Verdrahtungsfehler

Aber Kabel für Digitalsignale die mit 100Mbit/s übertragen werden sind leider tückischer. Wie im Abschnitt Kabel bereits definiert, kann ein defektes oder Kabel oder minderer Qualität sich so verhalten, das es z.B. mit 10m sehr gut überträgt, aber bereits nach 90m wegen der Dämpfung sehr viele Signalrechtecke fehlinterpretiert werden und somit eine fehlerhafte Vermittlung stattfindet. Leider wird dann von dem System gemeldet, das ein Protokollproblem vorliegt und nicht das das Kabel das Protokoll kaput macht.

Brauchbarer Switch für die Veranstaltungtechnik

Heute verwendet man gerne den HP Pro Curve SX LC Mini GBIC. Der Unterschied zu HP Pro Curve LX LC Mini GBIC ist, dass nur Multimode-LWL benutzt werden können und somit nur Reichweiten von 550m überbrückt werden können. Dies reicht aber für die meisten Projekte aus.


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