--- title: "¿Qué es sACN? ANSI E1.31 explicado | DMXDesktop" description: "sACN explicado: cómo ANSI E1.31 lleva DMX por Ethernet, cómo funcionan el multicast y la prioridad, y qué pasa cuando se cortan los datos." canonical: https://www.dmxdesktop.com/es/guides/what-is-sacn lang: es source: /es/guides/what-is-sacn --- # ¿Qué es sACN? Explicación de ANSI E1.31 **sACN es la abreviatura habitual de ANSI E1.31, el estándar abierto que transporta datos de iluminación DMX512 a través de una red Ethernet ordinaria.** Un cable de red reemplaza muchos cables DMX, y una sola computadora puede controlar cientos de universos en un edificio. Es publicado por ESTA, es gratuito para implementar y casi todos los productos de iluminación modernos lo soportan. Esta guía explica cómo funciona realmente sACN: cómo dirige los universos, cómo decide qué consola gana cuando dos están enviando y qué sucede cuando los datos se detienen. Cada figura aquí se toma de la revisión actual del estándar, ANSI E1.31-2025. Última actualización 2026-09-16 ## En resumen - •sACN envía universos DMX512 a través de UDP en el puerto **5568**, normalmente por multicast, por lo que un emisor alcanza a muchos receptores sin necesidad de ser configurado para cada uno. - •Los números de universo van de **1 a 63999**, y el número de universo se mapea directamente a la dirección multicast **239.255..**. - •Cada fuente tiene una **prioridad de 0 a 200, por defecto 100**. La prioridad más alta gana, que es cómo las consolas de respaldo y el control remoto toman el control de manera limpia. - •Si los datos se detienen durante **2.5 segundos**, el receptor trata el universo como desconectado. El comportamiento requerido por el estándar es **detener la salida**, no mantener la última apariencia. - •sACN no transporta RDM ni configuración de dispositivos. Ese es el territorio de Art-Net, o RDMnet (ANSI E1.33). ## [Qué es realmente sACN](#que-es-realmente-sacn) sACN significa un estándar con un nombre mucho más largo: *ANSI E1.31-2025, Tecnología de Entretenimiento, Protocolo de transmisión ligero para el transporte de DMX512 utilizando ACN*. ACN se refiere a la Arquitectura para Redes de Control, ANSI E1.17, de la cual E1.31 toma prestado su formato de paquete. Una pequeña curiosidad que vale la pena conocer, porque confunde a las personas que escriben sobre ello: **la abreviatura "sACN" nunca aparece en el estándar mismo.** ESTA la utiliza informalmente en sus propios boletines ("también conocido como sACN"), y todos en la industria lo dicen, pero no lo encontrarás, ni la expansión "Streaming ACN", escrita en el documento publicado. Si quieres ser preciso, llámalo ANSI E1.31 y nota que sACN es la abreviatura común. El estándar es publicado por [el Programa de Normas Técnicas de ESTA](https://tsp.esta.org/tsp/documents/published_docs.php?utm_source=dmxdesktop.com), el mismo organismo detrás de DMX512 (E1.11) y RDM (E1.20). Es un Estándar Nacional Americano abierto: cualquiera puede descargarlo y cualquiera puede implementarlo sin una tarifa de licencia. Esa apertura es la principal razón por la que sACN se ha difundido tan rápidamente a través de consolas, nodos, servidores multimedia y software. Lo que hace es estrecho y deliberado. Toma los 512 espacios de un universo DMX, los envuelve en un paquete UDP con algunos campos adicionales y los transmite a través de una red IP. No configura dispositivos, no descubre fixtures ni transporta RDM. Mueve niveles de iluminación, rápidamente, a muchos lugares a la vez. ## [Cómo viaja sACN: multicast y puerto 5568](#como-viaja-sacn-multicast-y-puerto-5568) sACN funciona sobre UDP en **el puerto 5568**. Ese puerto está debidamente registrado con IANA, bajo el nombre de servicio `sdt` (Transporte de Datos de Sesión), que es una pequeña pero real señal de la madurez del estándar. La parte inteligente es la direccionamiento. sACN normalmente utiliza **multicast**, y el número de universo se construye directamente en la dirección multicast: - Los primeros dos bytes son siempre **239.255**. - El tercer byte es el **byte alto** del número de universo. - El cuarto byte es el **byte bajo**. Así que el universo 1 es 239.255.0.1, el universo 2 es 239.255.0.2, y el universo 300 es 239.255.1.44. También hay una forma IPv6, en el rango FF18::83:00:00:00 en adelante, construida de la misma manera a partir de los últimos dos bytes. Debido a que la dirección se deriva del universo, un receptor no necesita ser informado de dónde provienen los datos. Simplemente se une al grupo multicast para los universos que le interesan, y la red entrega solo esos. Esa es la razón por la que un gran equipo puede funcionar con un solo cable sin que cada nodo sea configurado individualmente. Una sutileza de la que el estándar es explícito: **el universo se identifica por el número dentro del paquete, no por la dirección en la que llegó**. Un receptor nunca debe asumir que los dos coinciden. El unicast también está permitido, y un receptor debe aceptar sACN enviado directamente a su propia dirección IP. La trampa se establece claramente en el estándar: sACN no define ninguna forma de descubrir esas direcciones, por lo que con unicast debes configurar las IP de destino manualmente. Eso está bien para dos nodos y es doloroso para veinte. Software de iluminación universo 1, prioridad 100 ↓→ Conmutador Ethernet snooping IGMP ↓→ Grupo multicast 239.255.0.1, UDP 5568 ↓→ Nodo sACN convierte a DMX512 ↓→ Fijaciones Cadena de XLR5 El nodo es el único lugar donde la señal se convierte en DMX512. Todo a su izquierda es tráfico de red ordinario. ## [Universos: cuántos y qué números están prohibidos](#universos-cuantos-y-que-numeros-estan-prohibidos) El estándar permite números de universo desde **1 hasta 63999**. El universo 0 está reservado y no debe ser utilizado, al igual que todo lo que va de 64000 a 65535, con una excepción: **el universo 64214** está reservado para el descubrimiento de universos. Otras dos reglas suelen confundir a la gente: - Las 256 direcciones multicast IPv4 superiores, de 239.255.255.0 a 239.255.255.255, están reservadas por IANA para otro propósito, por lo que los dispositivos E1.31 no deben transmitir en ellas. Si esos universos se utilizan, deben ser enviados por unicast. - Los números sACN comienzan en 1, al igual que DMXDesktop, por lo que el número que configures es el número que se envía. Art-Net es el que se sale de la norma, porque comienza en 0. El descubrimiento en sACN es limitado y vale la pena entenderlo antes de buscar una función que no existe. Las fuentes anuncian qué universos están transmitiendo enviando una lista en el universo 64214 cada 10 segundos. Eso permite que una herramienta de monitoreo muestre qué hay en la red sin unirse a cada grupo multicast. Pero no hay **descubrimiento de dispositivos** en sACN: nada te dice qué nodos existen, cómo se llaman o cómo configurarlos. Si quieres eso, necesitas Art-Net o RDMnet. ## [Prioridad: cómo sACN decide qué fuente gana](#prioridad-como-sacn-decide-que-fuente-gana) Esta es la función que hace que sACN sea atractivo para cualquier cosa que tenga que seguir funcionando. Cada paquete de datos sACN lleva un valor de **prioridad** de **0 a 200**. Una fuente que no admite prioridad variable debe enviar **100**, que es por qué 100 es el valor predeterminado en casi todas partes. La regla es simple: para un universo dado, un receptor que toma datos de varias fuentes trata la **prioridad más alta** como los datos definitivos. Los números más altos ganan. Así que una consola de respaldo que envía con prioridad 90 permanece en silencio debajo de una consola principal en 100, y toma el control en el instante en que la consola principal se detiene. Sin conmutación, sin parcheo, sin intervención del operador. La prioridad se aplica **por universo**, no por canal. La prioridad por ranura es un mecanismo separado que E1.31 menciona pero no define. Lo que sucede cuando dos fuentes empatan en la prioridad más alta es donde las implementaciones difieren, y el estándar es honesto al respecto. Define dos comportamientos, *fusión* (combinando los datos, comúnmente la más alta tiene prioridad por ranura) y *arbitraje* (eligiendo una fuente), y requiere que cada dispositivo documente cuál utiliza, cuántas fuentes puede manejar y qué hace cuando se excede ese límite. No impone un algoritmo. Da una fuerte advertencia, y es una buena regla para el diseño de rig también: se desaconseja "muy fuertemente" a los diseñadores utilizar algoritmos que produzcan resultados diferentes del mismo conjunto de fuentes en diferentes ocasiones, como aceptar la primera fuente que aparece. El resultado depende entonces del orden en que se encendieron las cosas, que es lo último que deseas en un día de espectáculo. En DMXDesktop, la prioridad se establece por universo, de 1 a 200, con un valor predeterminado de 100. ## [Qué sucede cuando los datos se detienen](#que-sucede-cuando-los-datos-se-detienen) sACN funciona sobre UDP, que el estándar afirma claramente que no ofrece reconocimiento ni garantía de que los paquetes lleguen. Así que la pregunta interesante no es si los paquetes se pierden, sino qué hace un receptor ante el silencio. Tres reglas rigen esto: - **Tiempo de espera por pérdida de datos: 2.5 segundos.** Si un receptor no escucha nada de una fuente en un universo durante 2.5 segundos, esa fuente y universo se consideran desconectados. En la revisión de 2025, esto cuenta **solo paquetes de datos**, por lo que una fuente que sigue enviando paquetes de sincronización o descubrimiento, pero sin datos, también se agotará. - **Keep-alive: cada 800 a 1000 milisegundos.** Una fuente que no tiene nada nuevo que decir no tiene que seguir bombardeando la red. Envía tres paquetes idénticos, luego vuelve a un solo paquete keep-alive aproximadamente una vez por segundo, lo que es suficiente para mantenerse dentro de la ventana de 2.5 segundos. - **Apagado limpio: la bandera Stream_Terminated.** En lugar de simplemente quedarse en silencio y dejar que los receptores esperen el tiempo de espera, una fuente que ha terminado establece una bandera en tres paquetes finales. Los receptores tratan eso como una desconexión inmediata e intencionada en lugar de un fallo. **Aquí está la parte que casi todos se equivocan.** Pregunta a un grupo de personas de iluminación qué debería hacer un nodo cuando los datos se detienen, y la mayoría dirá que mantiene la última vista. El estándar dice lo contrario: una puerta de enlace debe proporcionar un modo donde, al perder datos de todas las fuentes de un universo, **deje de transmitir DMX512 de inmediato**. Mantener la última vista se permite como un modo adicional, no como el requerido. Si tu equipo se apaga cuando una laptop entra en modo de suspensión, ese es un comportamiento conforme, no un fallo, y la solución es configurar el nodo, no culpar al software. ## [Sincronización, datos de vista previa y las banderas de opción](#sincronizacion-datos-de-vista-previa-y-las-banderas-de-opcion) Cada paquete sACN lleva un pequeño campo de opciones con tres banderas definidas, y explican varios comportamientos que puedes haber visto sin saber por qué. - **Preview_Data.** Los datos marcados con esta bandera son para visualizadores y vistas previas de servidores multimedia y no deben activar la salida en vivo. Es cómo un diseñador puede ejecutar un flujo de previsualización en la misma red sin iluminar la sala. - **Stream_Terminated.** El apagado limpio descrito anteriormente. - **Force_Synchronization.** Controla lo que hace un receptor sincronizado si se pierde la sincronización: congelarse hasta que vuelva, o seguir actualizándose con nuevos paquetes. La sincronización de universos existe para casos donde varios universos deben cambiar en el mismo instante, como paneles LED, servidores multimedia y atenuadores rápidos, donde unos pocos milisegundos de desincronización son visibles. La fuente decide: coloca una dirección de sincronización en sus paquetes de datos, y los receptores mantienen esos datos hasta que llega el paquete de sincronización correspondiente. Dos notas prácticas. El soporte para sincronización es **opcional para los receptores**, mientras que los paquetes de datos y descubrimiento no lo son, así que no puedes asumir que un nodo lo implementa. Y DMXDesktop no utiliza actualmente paquetes de sincronización: transmite paquetes de datos normalmente, que es lo que la abrumadora mayoría de los equipos utilizan. ## [Lo que necesita tu red](#lo-que-necesita-tu-red) sACN es poco exigente, pero el multicast tiene algunos requisitos que explican silenciosamente la mayoría de las historias de "funciona en mi escritorio pero no en el lugar". - **Soporte IGMP.** El estándar requiere que los receptores soporten IGMP versión 2 en IPv4 (o MLD versión 1 en IPv6). Así es como un dispositivo le dice a la red qué grupos multicast desea. En un pequeño switch no gestionado, todo se inunda a cada puerto y simplemente funciona. En una red gestionada más grande, deseas que **IGMP snooping** esté configurado correctamente, con un consultor presente, o el tráfico será inundado en todas partes o se descartará por completo. - **Con cable, no inalámbrico.** El multicast sobre WiFi se entrega a bajas tasas de datos y es fácilmente interrumpido. Úsalo para una tableta de control remoto, no para un camino de datos de iluminación. - **Reglas de firewall.** El puerto UDP 5568 entrante debe estar abierto en cualquier máquina que reciba sACN, y en Windows la interfaz tiene que ser la que crees que es. Las laptops con varios adaptadores, incluidos los virtuales de software VPN, frecuentemente envían desde la interfaz incorrecta. - **Tasa de fotogramas.** El estándar dice que las fuentes no deben exceder la tasa de refresco máxima de DMX512, que E1.11 establece en **44 actualizaciones por segundo** para un paquete completo de 513 ranuras, a menos que el usuario habilite deliberadamente tasas más altas en un universo sin puerta de enlace DMX. DMXDesktop emite a 40 Hz por defecto y puede configurarse entre 10 y 44 Hz. ## [sACN, Art-Net y RDM: lo que sACN no hace](#sacn-art-net-y-rdm-lo-que-sacn-no-hace) Dos preguntas surgen constantemente, y ambas tienen respuestas claras. **¿sACN transporta RDM?** No. E1.31 no define ningún mecanismo para RDM en absoluto, por lo que ningún producto puede ofrecer RDM sobre sACN, independientemente de cómo se comercialice. RDM sobre una red es un estándar diferente, **RDMnet (ANSI E1.33)**. RDM sobre Art-Net también existe, pero esa es una extensión propia de Artistic Licence en lugar de un estándar de ESTA. En DMXDesktop, RDM funciona a través de interfaces USB y sobre Art-Net. **¿Es sACN mejor que Art-Net?** Resuelven problemas superpuestos de manera diferente. sACN tiene prioridad, direccionamiento multicast y un estándar formal detrás de él. Art-Net tiene descubrimiento de dispositivos, configuración de nodos y RDM. Muchos equipos utilizan ambos a la vez, que es exactamente lo que Art-Net 4 anticipa. Hay una comparación completa lado a lado en la [guía Art-Net vs sACN](/es/guides/art-net-vs-sacn). ## [Problemas comunes de sACN](#problemas-comunes-de-sacn) Casi cada fallo de sACN es uno de estos. | Síntoma | Causa más probable | Qué verificar | | --- | --- | --- | | Nada llega a los dispositivos | Desajuste de universo | El número de universo del nodo debe coincidir con el universo que estás enviando, recordando que sACN cuenta desde 1 | | Funciona en una máquina, no en otra | Interfaz de red incorrecta | Selecciona el adaptador en la red de iluminación explícitamente y desactiva los adaptadores virtuales del software VPN | | Funciona en la mesa, falla en el lugar | IGMP snooping sin un consultor | Prueba con un switch no gestionado, luego arregla la red gestionada en lugar de trabajar alrededor de ella | | La salida se congela, luego todo se oscurece | Se alcanzó el tiempo de espera por pérdida de datos | Comportamiento esperado después de 2.5 segundos de silencio. Verifica la máquina que envía y establece deliberadamente el modo de pérdida de datos del nodo | | Dos consolas, salida parpadeante | Prioridad igual de ambas fuentes | Dale a la copia de seguridad una prioridad más baja. Prioridades iguales dejan el resultado a las reglas de fusión del receptor | | Intermitente, solo inalámbrico | Multicast sobre WiFi | Mueve la ruta de iluminación a Ethernet por cable | | El receptor no ve nada, la red muestra tráfico | El firewall bloquea UDP 5568 | Permitir UDP 5568 entrante en la máquina receptora | ## Preguntas frecuentes ¿Qué significa sACN? +sACN es la abreviatura común para ANSI E1.31, el estándar de ESTA titulado "Protocolo de transmisión ligero para el transporte de DMX512 utilizando ACN". ACN significa Arquitectura para Redes de Control. La abreviatura en sí no aparece en el estándar, y la expansión "Streaming ACN", aunque ampliamente utilizada, no está escrita en ningún documento de ESTA. ¿Qué puerto utiliza sACN? +Puerto UDP 5568, registrado con IANA bajo el nombre de servicio sdt. Los datos normalmente se envían a una dirección multicast de la forma 239.255.., así que el universo 1 es 239.255.0.1. ¿Cuántos universos puede transportar sACN? +El estándar permite números de universo del 1 al 63999. El universo 0 y del 64000 al 65535 están reservados, excepto el universo 64214, que se utiliza para el descubrimiento de universos. En la práctica, tu límite es la red y el software, no el protocolo. ¿sACN soporta RDM? +No. ANSI E1.31 no define ningún transporte RDM. RDM sobre una red IP está cubierto por un estándar separado, RDMnet (ANSI E1.33). RDM también se transporta sobre Art-Net como una extensión de proveedor. DMXDesktop soporta RDM sobre interfaces DMX USB y sobre Art-Net. ¿Necesito un switch gestionado para sACN? +No para un equipo pequeño. En un switch no gestionado simple, el tráfico multicast se inunda a todos los puertos y todo funciona. Las redes gestionadas necesitan IGMP snooping configurado correctamente, con un consultor en la red, de lo contrario, el tráfico sACN puede ser descartado o inundado en todas partes. ¿Qué pasa si el software de iluminación falla? +Después de 2.5 segundos de silencio, el receptor trata esa fuente como desconectada. El comportamiento requerido del gateway por el estándar es dejar de transmitir DMX512 en ese momento, por lo que el equipo se oscurece. Mantener la última apariencia es un modo extra opcional que muchos nodos ofrecen, así que configúralo deliberadamente si eso es lo que deseas. ## Usando sACN en DMXDesktop DMXDesktop emite sACN de forma nativa en Mac y Windows, con prioridad por universo, multicast o una dirección multicast personalizada, y una vista de estado en vivo para cada universo. La guía de configuración te guía a través de la pantalla de configuración. [guía de configuración de sACN](/es/knowledgebase/sacn) [Ver nodos sACN probados →](/es/knowledgebase/supported-hardware) ## Fuentes Cada figura técnica en esta página fue leída del estándar publicado, no de resúmenes secundarios. - [ANSI E1.31-2025, Tecnología de Entretenimiento, Protocolo de transmisión ligero para el transporte de DMX512 utilizando ACN](https://tsp.esta.org/tsp/documents/published_docs.php?utm_source=dmxdesktop.com) , Programa de Normas Técnicas de ESTA. Puerto, direccionamiento, universos, prioridad, banderas de opción, tiempos de espera y comportamiento del gateway se leen de esta revisión - [ANSI E1.11-2024, USITT DMX512-A](https://tsp.esta.org/tsp/documents/published_docs.php?utm_source=dmxdesktop.com) , fuente de la tasa de refresco máxima de 44 actualizaciones por segundo para un paquete completo - [Registro de Nombres de Servicio de IANA y Números de Puerto de Protocolo de Transporte](https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?utm_source=dmxdesktop.com) , registro del puerto 5568 como sdt