Cómo corregir timeouts de conexión EtherNet/IP
Una conexión de E/S EtherNet/IP que hace timeout - ya sea que se niegue a establecerse del todo o que corra bien y luego caiga - saca de escaneo un rack de E/S remota o un variador y normalmente pone en falla la lógica del programa que depende de él. Las dos formas de falla tienen listas de causas distintas: una conexión que nunca abre es un desajuste de configuración, mientras que una que abre y luego muere es un problema de temporización o de red. Esta guía separa las dos y recorre los ajustes de RPI, los desajustes de tamaño de conexión y los problemas de entrega de multidifusión que clásicamente matan la E/S un rato después de que todo se veía bien.
Corregir timeouts de conexion EtherNet/IP en una línea: Un timeout de conexión EtherNet/IP en una conexión cíclica de E/S significa que los paquetes esperados dejaron de llegar dentro de la ventana permitida, que se deriva del intervalo de paquete solicitado (RPI) multiplicado por un multiplicador de timeout de conexión. Si la conexión nunca se establece, sospeche de la configuración: tamaños de conexión que no coinciden con los ensambles reales del dispositivo, un slot o instancia de ensamble equivocado, u otro controlador que ya sostiene una conexión de propietario exclusivo. Si se establece y luego cae, sospeche de la temporización y el transporte: un RPI demasiado agresivo para el dispositivo o la red, congestión, direcciones IP duplicadas, o datos de E/S multidifundidos inundados o podados por switches sin IGMP snooping adecuado y un consultante.
Primeras revisiones: nunca conecta frente a conecta y luego muere
Divida el síntoma primero, porque las listas de causas apenas se traslapan. Una conexión que falla de inmediato al establecerse - la petición forward open es rechazada - es una conversación sobre configuración entre el controlador y el dispositivo, y el código de error devuelto con el rechazo identifica el desacuerdo: tamaños de conexión equivocados, un ensamble desconocido o un conflicto de propiedad. Nada sobre cableado o switches está implicado todavía, porque tanto la petición como el rechazo atravesaron la red con éxito.
Una conexión que se establece, intercambia E/S por segundos o minutos, y luego hace timeout es lo opuesto: la configuración fue aceptable, y algo en el flujo continuo de paquetes falló. El retraso antes de la falla es en sí diagnóstico. Caídas inmediatas bajo carga apuntan a un RPI que el dispositivo o la red no pueden sostener; caídas tras un retraso consistente de un minuto o dos son la firma del tráfico de multidifusión cortado cuando expiran las membresías de grupo del switch, que se cubre abajo; caídas aleatorias se correlacionan con congestión, desajustes de dúplex, o una IP duplicada que responde de forma intermitente.
Rechazos de forward open: tamaños, instancias y propiedad
Los desajustes de tamaño de conexión son la falla de establecimiento más común. El originador declara los tamaños de los datos de entrada y salida que espera intercambiar, y el destino los compara contra los tamaños reales de sus ensambles; cualquier desacuerdo rechaza la conexión. Los desajustes vienen de configurar el dispositivo de memoria en vez de desde su archivo EDS, de revisiones de firmware que cambiaron los diseños de ensamble, o de configuraciones de módulo opcionales que alteran los tamaños de datos. La solución es configurar desde el EDS correcto para el firmware instalado y dejar que la herramienta derive los tamaños en vez de escribirlos.
Los conflictos de propiedad son lo siguiente. Los datos de salida cíclicos tienen un dueño: un segundo controlador que intenta una conexión de propietario exclusivo a una E/S ya poseída es rechazado. Esto surge durante migraciones y experimentos de redundancia, cuando un controlador viejo sigue en línea y sostiene la conexión que todos olvidaron. Los tipos de conexión de solo escucha y solo entrada existen precisamente para que controladores adicionales puedan recibir datos sin disputar la propiedad, y usarlos para el segundo lector es la solución de diseño y no un truco.
RPI, multidifusión y la red que se come la E/S
El intervalo de paquete solicitado fija la tasa de intercambio cíclico, y la conexión se declara muerta cuando los paquetes dejan de llegar durante la ventana de timeout derivada del RPI y el multiplicador de timeout. Un RPI mucho más rápido de lo que la aplicación necesita multiplica el tráfico sin beneficio y da a un dispositivo ocupado o a un enlace congestionado más oportunidades de perder la ventana. Bajar el RPI en conexiones no críticas y reservar tasas rápidas para los lazos que las necesitan es higiene básica, y subir el multiplicador de timeout es una acomodación legítima para trayectorias con jitter conocido, como saltos inalámbricos: cambia velocidad de detección por estabilidad.
La entrega por multidifusión merece su propio párrafo porque su modo de falla es muy reconocible. Los datos de E/S EtherNet/IP del destino al originador pueden enviarse por multidifusión, y los switches gestionan la membresía de multidifusión con IGMP snooping, que solo funciona bien cuando algo en la red actúa como consultante IGMP, refrescando las membresías de grupo. En una red con snooping habilitado pero sin consultante, las membresías expiran en silencio, el switch deja de reenviar el grupo, y la conexión de E/S muere un minuto o más después de arrancar, cada vez, como reloj. Las curas son correr un consultante, normalmente en un switch administrado o un enrutador, o configurar las conexiones como unidifusión, que los dispositivos modernos soportan y que evita IGMP por completo. Los switches no administrados que inundan toda la multidifusión mantienen redes pequeñas funcionando por accidente hasta que el tráfico crece, por lo cual el problema aparece tan a menudo tras una expansión.
Cuándo escalar
Escale con el código de error de forward open para fallas de establecimiento, o con una captura de paquetes que abarque un ciclo de conectar a caer para fallas en marcha: un puerto de switch espejeado y cualquier herramienta de captura la proveen. La captura muestra si el dispositivo dejó de enviar, si la red dejó de entregar, o si el originador dejó de escuchar, lo cual divide con limpieza la responsabilidad entre el fabricante del dispositivo, el equipo de red y control. Las direcciones IP duplicadas vale la pena descartarlas de forma explícita en esta etapa, porque sus síntomas intermitentes imitan varias otras causas y una captura las expone de inmediato.
Las redes crónicamente marginales merecen monitoreo en vez de apagar incendios repetido. Los conteos de caída de conexión, el estado del dispositivo y las tendencias de salud de red hechas visibles en una capa SCADA - una plataforma como Merobix que lee los diagnósticos del controlador y los dispositivos - convierten una reputación vaga de inestabilidad en evidencia con marca de tiempo que se correlaciona con cambios de switch, crecimiento de tráfico o dispositivos específicos, que es lo que finalmente logra corregir los problemas de red en la causa.
Preguntas frecuentes
¿Por qué mi conexión de E/S EtherNet/IP cae cerca de un minuto después de arrancar?
Ese retraso es la firma clásica de la expiración de la membresía de grupo de multidifusión. Con IGMP snooping habilitado pero sin consultante en la red, los switches aprenden el grupo cuando arranca la conexión, luego lo dejan envejecer porque nada refresca la membresía, y la multidifusión de E/S deja de reenviarse. La solución es habilitar un consultante IGMP en un switch administrado o un enrutador, o reconfigurar las conexiones de E/S como unidifusión para que el manejo de multidifusión deje de importar.
¿Qué tiene que ver el RPI con los timeouts de conexión?
El intervalo de paquete solicitado es la tasa de intercambio cíclico, y la ventana de timeout que declara muerta la conexión se deriva del RPI y un multiplicador de timeout. Un RPI muy rápido carga más al dispositivo y a la red y deja menos holgura para el jitter, así que las pérdidas se acumulan en timeouts. Fijar el RPI a lo que la aplicación realmente necesita, y subir el multiplicador en trayectorias con jitter conocido, estabiliza las conexiones sin esconder fallas reales.
¿Por qué se rechaza un segundo controlador al conectar a la misma E/S?
Las salidas cíclicas tienen exactamente un dueño. Una petición de conexión de propietario exclusivo a una E/S que otro controlador ya posee es rechazada por diseño, porque dos escritores a las mismas salidas serían peligrosos. Un segundo controlador que solo necesita ver los datos debe usar una conexión de solo entrada o de solo escucha, que recibe los mismos datos de entrada sin disputar la propiedad de las salidas.
Fuentes y lecturas
Referencias primarias de los organismos de normas y reguladores que definen este tema:
- EtherNet/IP - ODVA
Servicios de automatización
¿Necesita convertir esta información en un sistema que funcione?
Merobix integra SCADA, programa PLC Allen-Bradley y Siemens, y diseña y fabrica tableros de control industrial.
Las solicitudes de reunión se revisan antes de confirmarse.