Was ist sACN? ANSI E1.31 erklärt

Was sACN tatsächlich ist

sACN steht für einen Standard mit einem viel längeren Namen: ANSI E1.31-2025, Unterhaltungstechnologie, leichtgewichtiges Streaming-Protokoll für den Transport von DMX512 unter Verwendung von ACN. ACN steht hier für die Architektur für Steuerungsnetzwerke, ANSI E1.17, von der E1.31 seine Paketstruktur entlehnt.

Eine kleine Kuriosität, die es wert ist zu wissen, weil sie viele Menschen verwirrt, die darüber schreiben: die Abkürzung "sACN" erscheint nie im Standard selbst. ESTA verwendet sie informell in ihren eigenen Newslettern ("auch bekannt als sACN"), und jeder in der Branche sagt es, aber Sie werden sie nicht finden, noch die Erweiterung "Streaming ACN", im veröffentlichten Dokument ausgeschrieben. Wenn Sie genau sein wollen, nennen Sie es ANSI E1.31 und beachten Sie, dass sACN die gängige Abkürzung ist.

Der Standard wird von ESTAs Technical Standards Program veröffentlicht, dem gleichen Gremium, das hinter DMX512 (E1.11) und RDM (E1.20) steht. Es ist ein offener amerikanischer Nationalstandard: Jeder kann ihn herunterladen, und jeder kann ihn ohne Lizenzgebühr implementieren. Diese Offenheit ist der Hauptgrund, warum sACN sich so schnell über Konsolen, Knoten, Medienserver und Software verbreitet hat.

Was es tut, ist eng und absichtlich. Es nimmt die 512 Slots eines DMX-Universums, verpackt sie in ein UDP-Paket mit ein paar zusätzlichen Feldern und streamt sie über ein IP-Netzwerk. Es konfiguriert keine Geräte, entdeckt keine Fixtures und trägt kein RDM. Es bewegt Lichtstärken schnell an viele Orte gleichzeitig.

Wie sACN reist: Multicast und Port 5568

sACN läuft über UDP auf Port 5568. Dieser Port ist ordnungsgemäß bei IANA registriert, unter dem Dienstnamen sdt (Session Data Transport), was ein kleines, aber echtes Zeichen für die Reife des Standards ist.

Der clevere Teil ist die Adressierung. sACN verwendet normalerweise Multicast, und die Universumsnummer ist direkt in die Multicast-Adresse eingebaut:

• Die ersten beiden Bytes sind immer 239.255.
• Das dritte Byte ist das High-Byte der Universumsnummer.
• Das vierte Byte ist das Low-Byte.

Universum 1 ist also 239.255.0.1, Universum 2 ist 239.255.0.2, und Universum 300 ist 239.255.1.44. Es gibt auch eine IPv6-Form, im Bereich FF18::83:00:00:00 aufwärts, die auf die gleiche Weise aus den letzten beiden Bytes aufgebaut ist.

Da die Adresse aus dem Universum abgeleitet ist, muss einem Empfänger nicht gesagt werden, woher die Daten kommen. Er tritt einfach der Multicast-Gruppe für die Universen bei, die ihn interessieren, und das Netzwerk liefert nur diese. Deshalb kann ein großes Rig über ein Kabel betrieben werden, ohne dass jeder Knoten individuell konfiguriert werden muss.

Eine Feinheit, über die der Standard ausdrücklich informiert: das Universum wird durch die Nummer im Paket identifiziert, nicht durch die Adresse, auf der es angekommen ist. Ein Empfänger sollte niemals davon ausgehen, dass die beiden übereinstimmen.

Unicast ist ebenfalls erlaubt, und ein Empfänger muss sACN akzeptieren, das direkt an seine eigene IP-Adresse gesendet wird. Der Haken wird im Standard klar formuliert: sACN definiert keinen Weg, diese Adressen zu entdecken, sodass Sie bei Unicast die Ziel-IPs manuell konfigurieren. Das ist für zwei Knoten in Ordnung und schmerzhaft für zwanzig.

Universen: wie viele und welche Nummern sind tabu

Der Standard erlaubt Universumsnummern von 1 bis 63999. Universum 0 ist reserviert und darf nicht verwendet werden, ebenso alles von 64000 bis 65535, mit einer Ausnahme: Universum 64214 ist für die Universumsentdeckung reserviert.

Zwei andere Regeln bringen die Leute durcheinander:

• Die obersten 256 IPv4-Multicast-Adressen, 239.255.255.0 bis 239.255.255.255, sind von der IANA für einen anderen Zweck reserviert, sodass E1.31-Geräte nicht auf ihnen übertragen dürfen. Wenn diese Universen jemals verwendet werden, müssen sie unicast gesendet werden.
• sACN nummeriert Universen ab 1, und das tut auch DMXDesktop, sodass die Nummer, die Sie einstellen, die Nummer ist, die ausgegeben wird. Art-Net ist die Ausnahme, da es bei 0 beginnt.

Die Entdeckung in sACN ist begrenzt und es ist wichtig, dies zu verstehen, bevor Sie nach einer Funktion suchen, die nicht existiert. Quellen geben bekannt, welche Universen sie übertragen, indem sie alle 10 Sekunden eine Liste auf Universum 64214 senden. Das ermöglicht einem Überwachungstool, zu zeigen, was im Netzwerk vorhanden ist, ohne jeder Multicast-Gruppe beizutreten. Aber es gibt keine Gerätesuche in sACN: nichts sagt Ihnen, welche Knoten existieren, wie sie heißen oder wie man sie konfiguriert. Wenn Sie das möchten, benötigen Sie Art-Net oder RDMnet.

Priorität: wie sACN entscheidet, welche Quelle gewinnt

Dies ist die Funktion, die sACN attraktiv für alles macht, was kontinuierlich laufen muss. Jedes sACN-Datenpaket trägt einen Prioritäts-Wert von 0 bis 200. Eine Quelle, die keine variable Priorität unterstützt, muss 100 senden, weshalb 100 fast überall der Standard ist.

Die Regel ist einfach: Für ein bestimmtes Universum behandelt ein Empfänger, der Daten von mehreren Quellen erhält, die höchste Priorität als die endgültigen Daten. Höhere Zahlen gewinnen. Eine Backup-Konsole, die mit Priorität 90 sendet, sitzt still unter einer Hauptkonsole mit 100 und übernimmt sofort, wenn die Hauptkonsole stoppt. Kein Umschalten, kein Patchen, kein Bedienereingriff.

Die Priorität gilt pro Universum, nicht pro Kanal. Slot-für-Slot-Priorität ist ein separates Mechanismus, das E1.31 erwähnt, aber nicht definiert.

Was passiert, wenn zwei Quellen bei der höchsten Priorität gleichauf liegen, ist der Punkt, an dem sich die Implementierungen unterscheiden, und der Standard ist ehrlich darüber. Er definiert zwei Verhaltensweisen, merge (Kombination der Daten, allgemein hat die höchste Priorität pro Slot Vorrang) und arbitration (Wahl einer Quelle), und verlangt von jedem Gerät, zu dokumentieren, welche es verwendet, wie viele Quellen es verarbeiten kann und was passiert, wenn dieses Limit überschritten wird. Es schreibt keinen Algorithmus vor.

Es gibt eine starke Warnung, und es ist auch eine gute Regel für das Rig-Design: Designer werden "sehr nachdrücklich davon abgeraten", Algorithmen zu verwenden, die bei unterschiedlichen Gelegenheiten unterschiedliche Ergebnisse aus demselben Satz von Quellen liefern, wie z. B. die Quelle zu akzeptieren, die zuerst erscheint. Das Ergebnis hängt dann von der Reihenfolge ab, in der die Dinge eingeschaltet wurden, was am letzten Tag, an dem eine Show stattfindet, das Letzte ist, was man möchte.

In DMXDesktop wird die Priorität pro Universum von 1 bis 200 eingestellt, standardmäßig auf 100.

Was passiert, wenn die Daten stoppen

sACN läuft über UDP, was der Standard ausdrücklich sagt, bietet keine Bestätigung und keine Garantie, dass Pakete ankommen. Daher ist die interessante Frage nicht, ob Pakete verloren gehen, sondern was ein Empfänger bei Stille tut.

Drei Regeln regeln dies:

• Datenverlust-Timeout: 2,5 Sekunden. Wenn ein Empfänger 2,5 Sekunden lang nichts von einer Quelle in einem Universum hört, wird diese Quelle und das Universum als getrennt betrachtet. In der Revision 2025 zählt dies nur Datenpakete, sodass eine Quelle, die weiterhin Synchronisations- oder Entdeckungspakete sendet, aber keine Daten, dennoch ausläuft.
• Keep-alive: alle 800 bis 1000 Millisekunden. Eine Quelle, die nichts Neues zu sagen hat, muss das Netzwerk nicht ständig überfluten. Sie sendet drei identische Pakete und wechselt dann zu einem einzelnen Keep-alive-Paket, das ungefähr einmal pro Sekunde gesendet wird, was ausreicht, um innerhalb des 2,5-Sekunden-Fensters zu bleiben.
• Sauberer Shutdown: das Stream_Terminated-Flag. Anstatt einfach still zu werden und die Empfänger warten zu lassen, bis das Timeout abgelaufen ist, setzt eine Quelle, die fertig ist, ein Flag in drei letzten Paketen. Empfänger behandeln dies als sofortige, absichtliche Trennung und nicht als Fehler.

Hier ist der Teil, den fast jeder falsch versteht. Fragen Sie einen Raum voller Lichttechniker, was ein Knoten tun sollte, wenn die Daten stoppen, und die meisten werden sagen, dass er den letzten Look hält. Der Standard sagt das Gegenteil: Ein Gateway muss einen Modus bereitstellen, in dem es bei Verlust von Daten aus allen Quellen eines Universums sofort aufhört, DMX512 zu übertragen. Hold-last-look ist als zusätzlicher Modus erlaubt, nicht als der erforderliche. Wenn Ihr Rig ausfällt, wenn ein Laptop in den Schlafmodus wechselt, ist das konformes Verhalten, kein Fehler, und die Lösung besteht darin, den Knoten zu konfigurieren, nicht die Software zu beschuldigen.

Synchronisation, Vorschau-Daten und die Optionsflags

Jedes sACN-Paket trägt ein kleines Optionsfeld mit drei definierten Flags, und sie erklären mehrere Verhaltensweisen, die Sie möglicherweise gesehen haben, ohne zu wissen, warum.

• Preview_Data. Daten, die mit diesem Flag gekennzeichnet sind, sind für Visualisierer und Medienserver-Vorschauen und dürfen keine Live-Ausgabe steuern. So kann ein Designer einen Pre-Visualisierungsstream im selben Netzwerk ausführen, ohne den Raum zu beleuchten.
• Stream_Terminated. Der oben beschriebene saubere Shutdown.
• Force_Synchronization. Steuert, was ein synchronisierter Empfänger tut, wenn die Synchronisation verloren geht: einfrieren, bis sie zurückkehrt, oder mit neuen Paketen weiter aktualisieren.

Die Universumsynchronisation selbst existiert für Fälle, in denen mehrere Universen im selben Moment wechseln müssen, wie LED-Panels, Medienserver und schnelle Dimmer, bei denen einige Millisekunden Verzögerung sichtbar sind. Die Quelle entscheidet: Sie setzt eine Synchronisationsadresse in ihren Datenpaketen, und Empfänger halten diese Daten, bis das passende Synchronisationspaket eintrifft.

Zwei praktische Hinweise. Die Unterstützung für Synchronisation ist optional für Empfänger, während Daten- und Entdeckungspakete es nicht sind, sodass Sie nicht davon ausgehen können, dass ein Knoten dies implementiert. Und DMXDesktop verwendet derzeit keine Synchronisationspakete: Es streamt Datenpakete normalerweise, was die überwiegende Mehrheit der Rigs verwendet.

Was Ihr Netzwerk benötigt

sACN ist anspruchslos, aber Multicast hat einige Anforderungen, die die meisten Geschichten "es funktioniert an meinem Schreibtisch, aber nicht im Veranstaltungsort" leise erklären.

• IGMP-Unterstützung. Der Standard verlangt von Empfängern, IGMP Version 2 über IPv4 (oder MLD Version 1 über IPv6) zu unterstützen. So teilt ein Gerät dem Netzwerk mit, welche Multicast-Gruppen es möchte. Bei einem kleinen unmanaged Switch wird alles an jeden Port geflutet und es funktioniert einfach. In einem größeren verwalteten Netzwerk möchten Sie IGMP-Snooping ordnungsgemäß konfiguriert haben, mit einem Abfrager, oder der Verkehr wird entweder überall geflutet oder ganz verworfen.
• Verdrahtet, nicht drahtlos. Multicast über WiFi wird mit niedrigen Datenraten geliefert und ist leicht gestört. Verwenden Sie es für ein Fernbedienungs-Tablet, nicht für einen Lichtdatenpfad.
• Firewall-Regeln. Der UDP-Port 5568 muss eingehend auf jedem Computer, der sACN empfängt, geöffnet sein, und unter Windows muss die Schnittstelle die sein, die Sie denken, dass sie es ist. Laptops mit mehreren Adaptern, einschließlich virtueller von VPN-Software, senden häufig über die falsche Schnittstelle.
• Bildwiederholrate. Der Standard besagt, dass Quellen die maximale DMX512-Aktualisierungsrate nicht überschreiten dürfen, die E1.11 auf 44 Aktualisierungen pro Sekunde für ein vollständiges 513-Slot-Paket festlegt, es sei denn, der Benutzer aktiviert absichtlich höhere Raten für ein Universum, auf dem kein DMX-Gateway vorhanden ist. DMXDesktop gibt standardmäßig mit 40 Hz aus und kann zwischen 10 und 44 Hz eingestellt werden.

sACN, Art-Net und RDM: was sACN nicht tut

Zwei Fragen tauchen ständig auf, und beide haben klare Antworten.

Überträgt sACN RDM? Nein. E1.31 definiert überhaupt keinen Mechanismus für RDM, sodass kein Produkt RDM über sACN anbieten kann, egal wie es vermarktet wird. RDM über ein Netzwerk ist ein anderer Standard, RDMnet (ANSI E1.33). RDM über Art-Net existiert ebenfalls, aber das ist die eigene Erweiterung von Artistic Licence und kein ESTA-Standard. In DMXDesktop funktioniert RDM über USB-Schnittstellen und über Art-Net.

Ist sACN besser als Art-Net? Sie lösen sich überschneidende Probleme unterschiedlich. sACN hat Priorität, Multicast-Adressierung und einen formalen Standard dahinter. Art-Net hat Gerätesuche, Knotenkonfiguration und RDM. Viele Rigs verwenden beide gleichzeitig, was genau das ist, was Art-Net 4 erwartet. Es gibt einen vollständigen Vergleich nebeneinander im Art-Net vs sACN-Leitfaden.

Häufige sACN-Probleme

Fast jeder sACN-Fehler gehört zu einem dieser.