Czym jest sACN? Wyjaśnienie ANSI E1.31

Czym jest sACN

sACN to standard o znacznie dłuższej nazwie: ANSI E1.31-2025, Technologia rozrywkowa, Lekki protokół strumieniowy do transportu DMX512 przy użyciu ACN. ACN to Architektura Sieci Sterujących, ANSI E1.17, z której E1.31 pożycza ramki pakietów.

Mała ciekawostka, którą warto znać, ponieważ myli ludzi piszących o tym: skrócenie „sACN” nigdy nie pojawia się w samym standardzie. ESTA używa go nieformalnie w swoich własnych biuletynach ("znany również jako sACN"), a wszyscy w branży to mówią, ale nie znajdziesz go, ani rozwinięcia „Streaming ACN”, w opublikowanym dokumencie. Jeśli chcesz być precyzyjny, nazywaj to ANSI E1.31 i zauważ, że sACN to powszechne skrócenie.

Standard jest publikowany przez Program Standardów Technicznych ESTA, ten sam organ, który stoi za DMX512 (E1.11) i RDM (E1.20). Jest to otwarty amerykański standard narodowy: każdy może go pobrać i wdrożyć bez opłaty licencyjnej. Ta otwartość jest głównym powodem, dla którego sACN tak szybko rozprzestrzenił się w konsolach, węzłach, serwerach multimedialnych i oprogramowaniu.

Co robi, jest wąskie i celowe. Bierze 512 slotów uniwersum DMX, owija je w pakiet UDP z kilkoma dodatkowymi polami i przesyła przez sieć IP. Nie konfiguruje urządzeń, nie odkrywa urządzeń, ani nie przesyła RDM. Szybko przesyła poziomy oświetlenia do wielu miejsc jednocześnie.

Jak sACN podróżuje: multicast i port 5568

sACN działa na UDP na porcie 5568. Ten port jest poprawnie zarejestrowany w IANA, pod nazwą usługi sdt (Transport Danych Sesji), co jest małym, ale rzeczywistym znakiem dojrzałości standardu.

Sprytną częścią jest adresowanie. sACN zazwyczaj używa multicast, a numer uniwersum jest bezpośrednio wbudowany w adres multicast:

• Pierwsze dwa bajty to zawsze 239.255.
• Trzeci bajt to wysoki bajt numeru uniwersum.
• Czwarty bajt to niski bajt.

Więc uniwersum 1 to 239.255.0.1, uniwersum 2 to 239.255.0.2, a uniwersum 300 to 239.255.1.44. Istnieje również forma IPv6, w zakresie FF18::83:00:00:00 w górę, zbudowana w ten sam sposób z ostatnich dwóch bajtów.

Ponieważ adres jest pochodną uniwersum, odbiornik nie musi być informowany, skąd pochodzą dane. Po prostu dołącza do grupy multicast dla uniwersów, którymi się interesuje, a sieć dostarcza tylko te. Dlatego duża instalacja może działać na jednym kablu bez konieczności indywidualnej konfiguracji każdego węzła.

Jedna subtelność, o której standard wyraźnie mówi: uniwersum jest identyfikowane przez numer wewnątrz pakietu, a nie przez adres, na którym dotarło. Odbiornik nigdy nie powinien zakładać, że te dwa się zgadzają.

Unicast jest również dozwolony, a odbiornik musi akceptować sACN wysyłane bezpośrednio na jego własny adres IP. Problem jest jasno określony w standardzie: sACN nie definiuje sposobu odkrywania tych adresów, więc w przypadku unicast musisz ręcznie konfigurować adresy IP docelowe. To jest w porządku dla dwóch węzłów, ale bolesne dla dwudziestu.

Uniwersa: ile ich jest i które numery są zastrzeżone

Standard pozwala na numery uniwersów od 1 do 63999. Uniwers 0 jest zastrzeżony i nie może być używany, a także wszystko od 64000 do 65535, z jednym wyjątkiem: uniwers 64214 jest zastrzeżony dla odkrywania uniwersów.

Dwie inne zasady wprowadzają zamieszanie:

• Najwyższe 256 adresów multicast IPv4, od 239.255.255.0 do 239.255.255.255, są zarezerwowane przez IANA do innych celów, więc urządzenia E1.31 nie mogą na nich transmitować. Jeśli te uniwersa kiedykolwiek będą używane, muszą być przesyłane unicast.
• sACN numeruje uniwersa od 1, a DMXDesktop również, więc numer, który ustawisz, to numer, który wychodzi. Art-Net jest wyjątkiem, ponieważ zaczyna się od 0.

Odkrywanie w sACN jest ograniczone i warto to zrozumieć, zanim zaczniesz szukać funkcji, która nie istnieje. Źródła ogłaszają, które uniwersa transmitują, wysyłając listę na uniwers 64214 co 10 sekund. To pozwala narzędziu monitorującemu pokazać, co jest w sieci bez dołączania do każdej grupy multicast. Ale w sACN nie ma odkrywania urządzeń: nic nie mówi ci, jakie węzły istnieją, jak się nazywają ani jak je skonfigurować. Jeśli tego chcesz, potrzebujesz Art-Net lub RDMnet.

Priorytet: jak sACN decyduje, które źródło wygrywa

To jest funkcja, która sprawia, że sACN jest atrakcyjny dla wszystkiego, co musi działać nieprzerwanie. Każdy pakiet danych sACN niesie wartość priorytetu od 0 do 200. Źródło, które nie obsługuje zmiennego priorytetu, musi wysyłać 100, dlatego 100 jest domyślną wartością prawie wszędzie.

Zasada jest prosta: dla danego uniwersum, odbiornik pobierający dane z kilku źródeł traktuje najwyższy priorytet jako ostateczne dane. Wyższe numery wygrywają. Tak więc zapasowa konsola wysyłająca na priorytecie 90 milczy pod główną konsolą na 100 i przejmuje kontrolę w momencie, gdy główna konsola przestaje działać. Bez przełączania, bez patchowania, bez interwencji operatora.

Priorytet stosuje się na uniwersum, a nie na kanale. Priorytet slot po slocie to osobny mechanizm, który E1.31 wspomina, ale nie definiuje.

Co się dzieje, gdy dwa źródła mają ten sam najwyższy priorytet, to miejsce, w którym implementacje się różnią, a standard jest w tej kwestii szczery. Definiuje dwa zachowania, scalanie (łączenie danych, zazwyczaj najwyższy priorytet ma pierwszeństwo na slocie) i arbitraż (wybór jednego źródła), i wymaga, aby każde urządzenie dokumentowało, które z nich stosuje, ile źródeł może obsłużyć i co robi, gdy ten limit zostanie przekroczony. Nie narzuca algorytmu.

Ostrzega jednak przed jednym, co jest również dobrą zasadą przy projektowaniu rigów: projektanci są "bardzo mocno zniechęcani" do algorytmów, które produkują różne wyniki z tego samego zestawu źródeł w różnych okolicznościach, takich jak akceptowanie pierwszego źródła, które się pojawi. Wówczas wynik zależy od kolejności, w jakiej włączono urządzenia, co jest ostatnią rzeczą, której chcesz w dniu pokazu.

W DMXDesktop priorytet jest ustawiany na uniwersum, od 1 do 200, domyślnie na 100.

Co się dzieje, gdy dane przestają płynąć

sACN działa na UDP, co standard jasno stwierdza, że nie oferuje potwierdzenia ani zapewnienia, że pakiety docierają. Więc interesujące pytanie nie brzmi, czy pakiety się gubią, ale co robi odbiornik w przypadku ciszy.

Trzy zasady rządzą tym:

• Limit czasu utraty danych: 2,5 sekundy. Jeśli odbiornik nie słyszy nic z źródła na uniwersum przez 2,5 sekundy, to źródło i uniwersum są uważane za rozłączone. W rewizji 2025 liczy się to tylko pakiety danych, więc źródło, które nadal wysyła pakiety synchronizacji lub odkrywania, ale nie dane, również wygaśnie.
• Keep-alive: co 800 do 1000 milisekund. Źródło, które nie ma nic nowego do powiedzenia, nie musi non-stop bombardować sieci. Wysyła trzy identyczne pakiety, a następnie przechodzi do jednego pakietu keep-alive mniej więcej raz na sekundę, co wystarcza, aby pozostać w oknie 2,5 sekundy.
• Czyste zamknięcie: flaga Stream_Terminated. Zamiast po prostu milczeć i czekać na wygaśnięcie limitu czasu, źródło, które zakończyło działanie, ustawia flagę w trzech ostatnich pakietach. Odbiorniki traktują to jako natychmiastowe, zamierzone rozłączenie, a nie błąd.

Oto część, którą prawie wszyscy mylą. Zapytaj grupę ludzi zajmujących się oświetleniem, co powinien zrobić węzeł, gdy dane przestają płynąć, a większość powie, że trzyma ostatni obraz. Standard mówi odwrotnie: brama musi zapewnić tryb, w którym, przy utracie danych ze wszystkich źródeł uniwersum, natychmiast przestaje transmitować DMX512. Utrzymywanie ostatniego obrazu jest dozwolone jako dodatkowy tryb, a nie jako wymagany. Jeśli twój rig gaśnie, gdy laptop przechodzi w stan uśpienia, to jest to zgodne działanie, a nie błąd, a naprawą jest skonfigurowanie węzła, a nie obwinianie oprogramowania.

Synchronizacja, dane podglądowe i flagi opcji

Każdy pakiet sACN niesie małe pole opcji z trzema zdefiniowanymi flagami, które wyjaśniają kilka zachowań, które mogłeś zauważyć, nie wiedząc dlaczego.

• Preview_Data. Dane oznaczone tą flagą są przeznaczone dla wizualizatorów i podglądów serwerów multimedialnych i nie mogą napędzać wyjścia na żywo. To sposób, w jaki projektant może prowadzić strumień pre-wizualizacji w tej samej sieci, nie oświetlając pomieszczenia.
• Stream_Terminated. Czyste zamknięcie opisane powyżej.
• Force_Synchronization. Kontroluje, co robi zsynchronizowany odbiornik, jeśli synchronizacja zostanie utracona: zamraża do momentu powrotu, czy kontynuuje aktualizację nowymi pakietami.

Synchronizacja uniwersum istnieje w przypadkach, gdy kilka uniwersów musi zmienić się w tym samym momencie, takich jak panele LED, serwery multimedialne i szybkie ściemniacze, gdzie kilka milisekund opóźnienia jest widoczne. Źródło decyduje: umieszcza adres synchronizacji w swoich pakietach danych, a odbiorniki trzymają te dane, aż przyjdzie odpowiadający pakiet synchronizacji.

Dwie praktyczne uwagi. Obsługa synchronizacji jest opcjonalna dla odbiorników, podczas gdy pakiety danych i odkrywania nie są, więc nie możesz zakładać, że węzeł to wdraża. A DMXDesktop obecnie nie używa pakietów synchronizacji: przesyła pakiety danych normalnie, co jest tym, na czym działa zdecydowana większość rigów.

Czego potrzebuje twoja sieć

sACN jest mało wymagający, ale multicast ma kilka wymagań, które cicho wyjaśniają większość historii "działa na moim biurku, ale nie w miejscu".

• Wsparcie IGMP. Standard wymaga, aby odbiorniki wspierały IGMP w wersji 2 na IPv4 (lub MLD w wersji 1 na IPv6). To sposób, w jaki urządzenie informuje sieć, które grupy multicast chce. Na małym niezarządzanym przełączniku wszystko jest rozsyłane do każdego portu i po prostu działa. Na większej zarządzanej sieci chcesz, aby IGMP snooping było poprawnie skonfigurowane, z obecnym zapytującym, inaczej ruch będzie albo rozsyłany wszędzie, albo całkowicie zablokowany.
• Przewodowe, nie bezprzewodowe. Multicast przez WiFi jest dostarczany przy niskich prędkościach danych i łatwo go zakłócić. Używaj go do tabletu zdalnego sterowania, a nie do ścieżki danych oświetleniowych.
• Reguły zapory. Port UDP 5568 przychodzący musi być otwarty na każdej maszynie odbierającej sACN, a na Windows interfejs musi być tym, którym myślisz, że jest. Laptopy z wieloma adapterami, w tym wirtualnymi z oprogramowania VPN, często wysyłają z niewłaściwego interfejsu.
• Częstotliwość odświeżania. Standard mówi, że źródła nie mogą przekraczać maksymalnej częstotliwości odświeżania DMX512, którą E1.11 ustawia na 44 aktualizacje na sekundę dla pełnego pakietu 513-slotowego, chyba że użytkownik celowo włączy wyższe częstotliwości na uniwersum bez bramy DMX. DMXDesktop domyślnie wyprowadza z częstotliwością 40 Hz i można ją ustawić w zakresie od 10 do 44 Hz.

sACN, Art-Net i RDM: czego sACN nie robi

Dwa pytania pojawiają się nieustannie, a oba mają jasne odpowiedzi.

Czy sACN obsługuje RDM? Nie. E1.31 nie definiuje żadnego mechanizmu dla RDM, więc żaden produkt nie może oferować RDM przez sACN, niezależnie od tego, jak jest reklamowany. RDM przez sieć to inny standard, RDMnet (ANSI E1.33). RDM przez Art-Net również istnieje, ale to własne rozszerzenie Artistic Licence, a nie standard ESTA. W DMXDesktop RDM działa przez interfejsy USB i przez Art-Net.

Czy sACN jest lepszy od Art-Net? Rozwiązują pokrywające się problemy w różny sposób. sACN ma priorytet, adresowanie multicast i formalny standard za sobą. Art-Net ma odkrywanie urządzeń, konfigurację węzłów i RDM. Wiele rigów korzysta z obu jednocześnie, co dokładnie przewiduje Art-Net 4. Istnieje pełne porównanie w przewodniku Art-Net vs sACN.

Typowe problemy z sACN

Prawie każdy błąd sACN to jeden z tych.