Es hat sicher jeder schon mal erlebt. Lichtpult, Art-Net-DMX-Knoten und Scheinwerfer sind ordnungsgemäß angeschlossen aber trotzdem bleiben die Scheinwerfer dunkel. Die Fehlerursache kann hier sehr vielschichtig sein. Neben defekten Kabeln, Scheinwerfern oder weiteren Teilen ist Fehlkonfiguration bei DMX-Adressen oder Universen eine mögliche Fehlerquelle. Wenn das aber alles korrekt konfiguriert und funktionsbereit ist, das Steuern der Scheinwerfer aber immer noch nicht funktioniert, kann es letztlich nur noch am IP-basierten Netzwerk liegen, was die technische Basis für die Art-Net-Kommunikation ist. Da ich mich hier schon öfters mit Fehlersuche beschäftigen musste, möchte ich hier in diesem Artikel meine Lösungsansätze und Werkzeuge mit euch teilen. Doch zuerst einige Grundlagen.

Was ist Art-Net?

Art-Net ist ein DMX-Steuerprotokoll über IP-basierte Netze. Das können Ethernet (LAN) oder WLAN sein. Theoretisch sind auch andere Übertragungswege auf dem OSI Level 2 möglich, was ich allerdings in der Praxis noch nie gesehen habe. Art-Net Nachrichten werden per UDP Broadcast (an alle Teilnehmer im Netz) oder per Unicast (an einen Teilnehmer) übertragen.

Art-Net verwendet die folgende Terminologie:

  • Node – Art-Net-DMX-Knoten übersetzt Art-Net- in DMX Nachrichten und umgekehrt
  • Controller – ist das Lichtpult oder andere Formen der Lichtsteuerung
  • Media Server (optional)

Jedes Gerät benötigt eine eindeutige IP Adresse. Diese muss gültig sein und zum Netz passen. Für den Aufbau des Netzes benötigt man noch ein oder mehrere Switche, ein Router oder auch die Kombination aus beiden.

Doch was bedeutet, dass die IP-Adresse gültig und zum Netz passen muss?

Ein IP-Adresse (v4) besteht aus 4 Teilen, die durch einen Punkt getrennt sind xxx.xxx.xxx.xxx. Der Wertebereich der Teile liegt zwischen 0…255. Bezüglich der Gültigkeit im Netzwerk gibt es allerdings einige Einschränkungen und reservierte Adressen.

Beleuchtungsnetze sind üblicherweise lokale Netze mit privaten IP-Adressen. Das heißt es kommen generell nur folgende Adressbereiche in Frage:

  • 10.0.0.0 – 10.255.255.255: Klasse A Netz mit 16.777.216 Adressen
  • 172.16.0.0 – 172.31.255.255: Klasse B mit 16 Netzen á 65.536 Adressen
  • 192.168.0.0 – 192.168.255.255 Klasse C mit 256 Netze mit á 256 Adressen

Das steht meiner Meinung etwas im Widerspruch mit der Art-Net Spezifikation. Hier gibt es nur das 10er Netz und ein 2er Netz (2.xxx.xxx.xxx), was es in der Definition der lokalen Netzwerke nicht gibt. Das ist auch eine mögliche Fehlerquelle, da es Hardwarehersteller gibt, die nur diese beiden Netze unterstützen (z.B. MA).

Über die Netzmaske kann man zusätzlich die Größe festlegen oder auch den gesamten Bereich auf mehrere Netze aufteilen. Für die Netzmaske gibt es 2 unterschiedliche Schreibweisen. IP-Adresse/255.255.255.0 bedeutet, dass es in der letzten Stelle 256 Adressen geben kann. In der anderen Schreibweise sieht das gleiche Netz folgendermaßen aus: IP-Adresse/24 (z. B. 192.168.178/24 bei meiner Fritzbox)

Das ist einfach eine Binärschreibweise:

255.255.255.0 entspricht
11111111.11111111.11111111.00000000 = 3 x 8 = 24

Man hat hier im Netz 256 mögliche Adressen. Die erste Adresse ist die Netzadresse. Die letzte Adresse ist die Broadcast-Adresse. Beide Adressen sind reserviert. Wenn ein Router im Netzwerk vorhanden ist, hat dieser üblicherweise die erste nutzbare Adresse = 192.168.178.1. D.h. es verbleiben 253 nutzbare Adressen für alle anderen Geräte im Netz:

  • 192.168.178.2
  • 192.168.178.254

Netzwerk Debugging

Wenn man die IP-Adresse der Geräte kennt, kann man mit dem ping-Kommando die Erreichbarkeit im Netzwerk überprüfen. 

ping 192.168.178.22
PING 192.168.178.22 (192.168.178.22): 56 data bytes
64 bytes from 192.168.178.22: icmp_seq=0 ttl=64 time=42.691 ms
64 bytes from 192.168.178.22: icmp_seq=1 ttl=64 time=65.820 ms
64 bytes from 192.168.178.22: icmp_seq=2 ttl=64 time=87.482 ms
64 bytes from 192.168.178.22: icmp_seq=3 ttl=64 time=113.199 ms
64 bytes from 192.168.178.22: icmp_seq=4 ttl=64 time=28.320 ms
…

Wenn das Gerät nicht erreichbar ist, bekommt man die folgenden Fehlermeldungen:

ping 192.168.178.22
PING 192.168.178.22 (192.168.178.22): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
…

Was macht man allerdings, wenn man die IP-Adressen nicht kennt? Dafür gibt es das arp-Kommando. Damit kann man sich den Arp-Cache ansehen, der alle kommunizierenden Geräte im Netz kennt. Hier im Beispiel sieht man, dass die 192.168.178.22 von meinem iPad verwendet wird.

arp -a
fritz.box (192.168.178.1) at 3c:22:43:65:1c:4d on en0 ifscope [ethernet]
ipadairmarko.fritz.box (192.168.178.22) at aa:b1:53:5e:64:53 on en0 ifscope [ethernet] 
markos-iphone.fritz.box (192.168.178.31) at bc:32:36:52:33:88 on en0 ifscope [ethernet]
? (192.168.178.255) at ff:ff:ff:ff:ff:ff on en0 ifscope [ethernet]
? (224.0.0.180) at 1:0:5e:0:0:b4 on en0 ifscope permanent [ethernet]
? (224.0.0.251) at 1:0:5e:0:0:fb on en0 ifscope permanent [ethernet]
? (236.1.0.2) at 1:0:5e:1:0:2 on en0 ifscope permanent [ethernet]
? (239.255.255.250) at 1:0:5e:7f:ff:fa on en0 ifscope permanent [ethernet]

Schwieriger wird es, wenn man die Adresse nicht kennt und diese nicht zum Netz passt. Dafür benötigt man spezielle Netzwerkdebugging-Tools, wie zum Beispiel Wireshark oder tcpdump. Diese können im Promiskuitiver Modus arbeiten (wenn es die Netzwerkkarte unterstützt). Das heißt, sie können auch Pakete erhalten, die nicht für dieses Netz bestimmt sind.

In meinem Fall ist es der Yarilo Pro LANdmx4, der die IP-Adresse 192.168.170.100 hat. Mein Netzwerk ist das 192.168.178/24, d.h. ich könnte keine Art-Net-Kommunikation mit diesem Knoten durchführen. Aber in Wireshark und in tcpdump kann ich die Pakete empfangen.

tcpdump -i en0 udp port 6454 -vv -X

In beiden Tools filtere ich auf UDP und dem Art-Net-Port: 6454. 

In diesem Fall mus man einfach die IP-Adresse des Konten an das Nezt anpassen, z.B. 192.168.178.100.

Artnet Debugging

Im oberen Beispiel sehen wir hier schon eine ArtNet-Nachricht (ArtPollReply). Mit dieser antwortet z.B. ein Knoten und teilt verschiedene Daten (Namen, IP-Adresse, Universen, Ports und Konfiguration) mit. Wenn diese Nachricht im richtigen Netz empfangen wird, kann diese der Controller auswerten und anzeigen. Wir sehen hier ein Beispiel aus der StageLight iPad App. Der LANdmx4 ist hier wieder richtig eingestellt.

Aber auch die DMX Steuerbefehle (z.B. ArtDmx) können über Wireshark oder tcpdump analysiert werden. Wenn ich in StageLight vom ersten Scheinwerfer den Dimmer auf max (255) und die Farbe Rot einstelle, sehen wir das auch in den Debugging-Tools.

tcpdump -i en0 udp port 6454 -vv -X
  • Kanal 1 : 255 – Dimmer
  • Kanal 2:  255 – Rot
  • Kanal 3:  000 – Grün
  • Kanal 4:  000 – Blau

In Wireshark sieht man das etwas besser, da man die DMX-Kanäle einzeln aufgelistet hat. Man sieht auch das die Nachricht an die Broadcast Adresse (192.168,178.255) geschickt wurde. D.h. alle Knoten können diese Nachricht erhalten.

Ich hoffe, ich habe das Thema ausführlich erklärt. Wenn ihr Fragen und Anregungen habt, schreibt es mir in die Kommentare.

Dass das auch mit Unicast funktioniert, könnt ihr gerne selber ausprobieren 😎
Ladet euch die StageLight App kostenlos im App Store herunter und aktiviert Unicast für das Universum. Wireshark ist auch kostenlos. Und los geht’s!

Links

Veröffentlicht von Marko

Founder at StageLight App

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

48 − 45 =