--- title: "Czym jest sACN? ANSI E1.31 wyjaśnione | DMXDesktop" description: "sACN wyjaśnione: jak ANSI E1.31 przesyła DMX przez Ethernet, jak działają multicast i priorytet źródła oraz co dzieje się po zaniku danych." canonical: https://www.dmxdesktop.com/pl/guides/what-is-sacn lang: pl source: /pl/guides/what-is-sacn --- # Czym jest sACN? Wyjaśnienie ANSI E1.31 **sACN to powszechnie stosowane skrócenie dla ANSI E1.31, otwartego standardu, który przesyła dane oświetleniowe DMX512 przez zwykłą sieć Ethernet.** Jeden kabel sieciowy zastępuje wiele kabli DMX, a jeden komputer może obsługiwać setki uniwersów w całym budynku. Jest publikowany przez ESTA, można go wdrażać za darmo, a niemal każdy nowoczesny produkt oświetleniowy go wspiera. Ten przewodnik wyjaśnia, jak sACN faktycznie działa: jak adresuje uniwersa, jak decyduje, która konsola wygrywa, gdy dwie nadają, oraz co się dzieje, gdy dane przestają płynąć. Każda figura tutaj pochodzi z aktualnej wersji standardu, ANSI E1.31-2025. Ostatnia aktualizacja 2026-09-16 ## Krótko mówiąc - •sACN przesyła uniwersa DMX512 przez UDP na porcie **5568**, zazwyczaj w trybie multicast, dzięki czemu jeden nadajnik dociera do wielu odbiorników bez konieczności konfigurowania każdego z nich. - •Numery uniwersów wynoszą od **1 do 63999**, a numer uniwersum mapuje się bezpośrednio na adres multicast **239.255..**. - •Każde źródło ma **priorytet od 0 do 200, domyślnie 100**. Najwyższy priorytet wygrywa, co pozwala na płynne przejęcie przez zapasowe konsole i zdalne sterowanie. - •Jeśli dane przestaną płynąć przez **2,5 sekundy**, odbiornik traktuje uniwersum jako odłączone. Wymagane przez standard zachowanie bramy to **zatrzymanie wyjścia**, a nie utrzymywanie ostatniego wyglądu. - •sACN nie przesyła RDM ani konfiguracji urządzeń. To terytorium Art-Net lub RDMnet (ANSI E1.33). ## [Czym jest sACN](#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](https://tsp.esta.org/tsp/documents/published_docs.php?utm_source=dmxdesktop.com), 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](#jak-sacn-podrozuje-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. Oprogramowanie oświetleniowe uniwersum 1, priorytet 100 ↓→ Przełącznik Ethernet IGMP snooping ↓→ Grupa multicast 239.255.0.1, UDP 5568 ↓→ Węzeł sACN konwertuje na DMX512 ↓→ Urządzenia łańcuch XLR5 Węzeł to jedyne miejsce, w którym sygnał staje się DMX512. Wszystko po jego lewej stronie to zwykły ruch sieciowy. ## [Uniwersa: ile ich jest i które numery są zastrzeżone](#uniwersa-ile-ich-jest-i-ktore-numery-sa-zastrzezone) 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](#priorytet-jak-sacn-decyduje-ktore-zrodlo-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ąć](#co-sie-dzieje-gdy-dane-przestaja-plynac) 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](#synchronizacja-dane-podgladowe-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ć](#czego-potrzebuje-twoja-siec) 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](#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](/pl/guides/art-net-vs-sacn). ## [Typowe problemy z sACN](#typowe-problemy-z-sacn) Prawie każdy błąd sACN to jeden z tych. | Objaw | Najbardziej prawdopodobna przyczyna | Co sprawdzić | | --- | --- | --- | | Nic nie dociera do urządzeń | Niekompatybilność uniwersum | Numer uniwersum węzła musi odpowiadać uniwersum, które wysyłasz, pamiętając, że sACN liczy od 1 | | Działa na jednej maszynie, nie na drugiej | Zła karta sieciowa | Wybierz adapter w sieci oświetleniowej jawnie i wyłącz wirtualne adaptery z oprogramowania VPN | | Działa przy biurku, nie działa w miejscu wydarzenia | IGMP snooping bez zapytującego | Przetestuj z niezarządzanym switchem, a następnie napraw zarządzaną sieć zamiast omijać problem | | Wyjście zamraża się, a potem wszystko gaśnie | Osiągnięto limit czasu utraty danych | Oczekiwane zachowanie po 2,5 sekundy ciszy. Sprawdź wysyłającą maszynę i celowo ustaw tryb utraty danych węzła | | Dwie konsole, migotanie wyjścia | Równa priorytet z obu źródeł | Nadaj zapasowemu niższy priorytet. Równe priorytety pozostawiają wynik regułom łączenia odbiornika | | Przerywane, tylko bezprzewodowe | Multicast przez WiFi | Przenieś ścieżkę oświetleniową do przewodowego Ethernetu | | Odbiornik nic nie widzi, sieć pokazuje ruch | Zapora blokuje UDP 5568 | Zezwól na przychodzący UDP 5568 na odbierającym urządzeniu | ## Najczęściej zadawane pytania Co oznacza sACN? +sACN to powszechny skrót od ANSI E1.31, standardu ESTA zatytułowanego "Protokół strumieniowy o niskiej wadze do transportu DMX512 przy użyciu ACN". ACN oznacza Architekturę dla Sieci Sterujących. Sam skrót nie występuje w standardzie, a rozwinięcie "Streaming ACN", chociaż powszechnie używane, nie jest zapisane w żadnym dokumencie ESTA. Jakiego portu używa sACN? +Port UDP 5568, zarejestrowany w IANA pod nazwą usługi sdt. Dane są zazwyczaj wysyłane na adres multicastowy w formie 239.255.., więc uniwersum 1 to 239.255.0.1. Ile uniwersów może przenosić sACN? +Standard pozwala na numery uniwersów od 1 do 63999. Uniwersum 0 oraz 64000 do 65535 są zarezerwowane, z wyjątkiem uniwersum 64214, które jest używane do odkrywania uniwersów. W praktyce twoim ograniczeniem jest sieć i oprogramowanie, a nie protokół. Czy sACN wspiera RDM? +Nie. ANSI E1.31 nie definiuje transportu RDM. RDM przez sieć IP jest objęte osobnym standardem, RDMnet (ANSI E1.33). RDM jest również przesyłane przez Art-Net jako rozszerzenie dostawcy. DMXDesktop wspiera RDM przez interfejsy USB DMX oraz przez Art-Net. Czy potrzebuję zarządzanego switcha dla sACN? +Nie dla małej instalacji. Na zwykłym, niezarządzanym switchu, ruch multicastowy jest rozsyłany do wszystkich portów i wszystko działa. Zarządzane sieci potrzebują poprawnie skonfigurowanego IGMP snooping, z zapytującym w sieci, w przeciwnym razie ruch sACN może być odrzucany lub rozsyłany wszędzie. Co się stanie, jeśli oprogramowanie oświetleniowe się zawiesi? +Po 2.5 sekundy ciszy odbiornik traktuje to źródło jako odłączone. Wymagane przez standard zachowanie bramy polega na zaprzestaniu przesyłania DMX512 w tym momencie, więc instalacja gaśnie. Utrzymanie ostatniego wyglądu to opcjonalny dodatkowy tryb, który wiele węzłów oferuje, więc ustaw go celowo, jeśli tego chcesz. ## Używanie sACN w DMXDesktop DMXDesktop natywnie obsługuje sACN na Mac i Windows, z priorytetem na uniwersum, multicast lub niestandardowy adres multicastowy oraz widok statusu na żywo dla każdego uniwersum. Przewodnik konfiguracji przeprowadza przez ekran konfiguracji. [Przewodnik konfiguracji sACN](/pl/knowledgebase/sacn) [Zobacz przetestowane węzły sACN →](/pl/knowledgebase/supported-hardware) ## Źródła Każda figura techniczna na tej stronie została odczytana z opublikowanego standardu, a nie z drugorzędnych podsumowań. - [ANSI E1.31-2025, Technologia Rozrywkowa, Protokół strumieniowy o niskiej wadze do transportu DMX512 przy użyciu ACN](https://tsp.esta.org/tsp/documents/published_docs.php?utm_source=dmxdesktop.com) , Program Technicznych Standardów ESTA. Port, adresowanie, uniwersa, priorytet, flagi opcji, czasy oczekiwania i zachowanie bramy są odczytywane z tej wersji - [ANSI E1.11-2024, USITT DMX512-A](https://tsp.esta.org/tsp/documents/published_docs.php?utm_source=dmxdesktop.com) , źródło maksymalnej częstotliwości odświeżania 44 aktualizacji na sekundę dla pełnego pakietu - [Rejestr nazw usług IANA i numerów portów protokołów transportowych](https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?utm_source=dmxdesktop.com) , rejestracja portu 5568 jako sdt