Control de iluminación
DMX, Art-Net y sACN para eventos: diseño, direccionamiento y redundancia
Una red de iluminación no está lista solo porque respondan todos los focos. Está lista cuando los universos están documentados, el tráfico llega únicamente a los receptores previstos, el comportamiento del backup es conocido y el show supera una prueba de fallo controlada.
1. Entender qué resuelve cada capa
DMX512 transporta valores de control mediante un enlace serie físico, con hasta 512 slots de datos por universo. Art-Net y sACN llevan el control de iluminación sobre una red IP, permitiendo que la mesa alcance nodos, gateways o luminarias de red a través de numerosos universos. Ethernet no elimina DMX: cambia dónde se realiza la conversión y cómo se gestiona la ruta.
| Capa | Qué transporta | Ventaja | Riesgo que controlar |
|---|---|---|---|
| DMX512 | Un universo serie sobre cable dedicado | Sencillo, directo y fácil de aislar | Distancia, derivaciones, terminación y fallos físicos |
| Art-Net | DMX y gestión sobre UDP/IP | Compatibilidad amplia, descubrimiento y ruteo flexible | Numeración, alcance del broadcast e implementaciones distintas |
| sACN · ANSI E1.31 | Flujos DMX sobre ACN y UDP/IP | Universos, prioridades y multicast normalizados | Multicast, prioridad de fuentes y comportamiento del receptor |
2. Crear un único plan de universos y direcciones
Mantén una tabla que relacione universos de mesa, universos de protocolo, direcciones IP, puertos de nodo y destinos DMX físicos. Los sistemas Art-Net pueden mostrar los universos en formatos diferentes o comenzar en cero, mientras otros equipos enseñan un único número decimal. No des por hecho que dos pantallas hablan del mismo universo hasta comprobar el mapeo.
- Asignar nombre y función a cada universo: escenario izquierdo, suelo, servidores de medios o iluminación de sala.
- Registrar universo de mesa, universo de red, IP del nodo, puerto de salida y dirección DMX inicial.
- Usar un método de direccionamiento controlado: IP estáticas documentadas o DHCP con reservas.
- Evitar cambios de offset, máscara o protocolo durante el ensayo sin actualizar el plan.
3. Elegir unicast, multicast o broadcast de forma consciente
Unicast envía datos a receptores concretos. Multicast permite que cada receptor se suscriba a los universos que necesita, pero exige que los switches gestionen correctamente ese tráfico. Broadcast alcanza todo el segmento local y puede funcionar en un sistema pequeño y validado, pero no debe convertirse en la respuesta por defecto al crecer la red. Sigue la documentación de mesa, nodos y luminarias porque las capacidades varían.
Utiliza switches gestionables y valida IGMP snooping y el papel de querier en toda la topología. Una red sin gestionar o mal configurada puede inundar puertos que no solicitaron el tráfico multicast o impedir que los receptores se unan a los grupos correctos.
4. Separar el control de riesgos evitables
Una red dedicada al control de iluminación suele ser más fácil de probar y recuperar que una LAN general compartida. Si el control debe convivir con vídeo, audio, internet o tráfico de oficina, define VLAN, uplinks, política multicast y dominios de fallo antes del montaje. El Wi‑Fi resulta útil para control remoto y diagnóstico, pero no debe convertirse sin querer en la única ruta crítica de datos del show.
- Desactivar protocolos y universos que no se utilizan para reducir tráfico y ambigüedad.
- Guardar configuraciones de switches, mesa y nodos después de la prueba aceptada.
- Etiquetar rutas principal y backup en ambos extremos, incluidos puertos de switch y nodo.
- Mantener una ruta de recuperación documentada, como DMX local o un nodo de repuesto configurado, para la salida crítica.
5. Definir prioridad de fuentes y comportamiento del backup
sACN admite prioridad de fuentes y las mesas o receptores también pueden combinar fuentes según su configuración. No conectes dos controladores activos dando por hecho que el secundario asumirá el control correctamente. Decide qué fuente gobierna cada universo, documenta su prioridad o modo de merge y prueba qué sucede cuando la principal deja de emitir, pierde el enlace o se reinicia.
6. Prueba de aceptación para producción
Ejecuta el estado completo del show, efectos, luminarias con pixel mapping y todos los universos activos durante al menos 20 o 30 minutos. Monitoriza puertos de switch, errores de paquetes, carga de mesa o servidores y estado de los nodos. Después provoca únicamente los fallos incluidos en el plan de recuperación, con autorización y mientras alguien observa la salida en escenario.
- Desconectar el enlace principal previsto y medir el tiempo de recuperación.
- Reiniciar un nodo o gateway y confirmar que recupera sus universos sin cambiar direcciones.
- Verificar que iluminación de sala, trabajo y sistemas relacionados con seguridad mantienen la ruta acordada.
- Exportar la configuración aceptada y anotar fecha, firmware, responsable y método de vuelta atrás.