Captura de tráfico EtherNet/IP de un Allen-Bradley 842E

Un portátil conectado al mismo switch gestionado que un encoder Allen-Bradley 842E no verá automáticamente el tráfico cíclico del encoder. Normalmente, un switch reenvía las tramas unicast únicamente hacia el puerto de destino. Por ello, el analizador puede mostrar casi nada mientras el controlador informa de un tiempo de espera de E/S.

Una captura útil comienza con una hipótesis de fallo comprobable y un punto de captura capaz de observar las tramas relevantes.

Defina la pregunta antes de recopilar paquetes

Describa el síntoma en términos medibles. Algunos ejemplos son un tiempo de espera de conexión durante una transición concreta de la máquina, un valor del encoder que deja de cambiar, reconexiones repetidas o datos de posición que llegan más tarde de lo que espera el controlador. Registre el código de fallo del controlador, la hora, los indicadores del encoder y el estado del puerto del switch.

Decida qué evidencia respaldaría o refutaría cada hipótesis. Si la pregunta es si las tramas salen del encoder, refleje el puerto conectado al encoder. Si se trata de saber si llegan al enlace ascendente del controlador, observe ese enlace. Capturar únicamente un lado de un switch intermedio no siempre permite localizar la pérdida.

El hardware de los encoders puede consultarse en la colección de sensores, mientras que los switches gestionados y los adaptadores de red están agrupados en Comunicación y redes.

Comprenda la ruta de red del 842E

Rockwell Automation documenta el 842E como una familia de encoders absolutos EtherNet/IP con dos puertos Ethernet para topologías lineales y Device Level Ring compatibles. El catálogo exacto y la configuración del proyecto determinan la conexión de datos, el conjunto de ensamblaje, el intervalo de paquetes solicitado y el comportamiento de diagnóstico.

Documente ambos puertos físicos, la configuración IP, la conexión del controlador, la topología, el firmware y si Device Level Ring está activo. En una topología lineal, un cable o dispositivo posterior puede afectar al tráfico que atraviesa el encoder. En un anillo, un evento de topología aporta evidencia adicional que debe correlacionarse con el fallo de conexión.

No dé por hecho que el puerto más cercano al controlador es siempre el único punto de captura útil. Dibuje la ruta real, incluidos los puertos del switch, los enlaces ascendentes, el supervisor del anillo, los convertidores de medios y cualquier ruta redundante.

Seleccione un método de captura no intrusivo

Una sesión de duplicación de puertos en un switch gestionado suele ser el método menos disruptivo. Configure como origen el puerto del encoder, el puerto del controlador o el enlace ascendente que requiera la hipótesis. Establezca como destino el puerto conectado al analizador y confirme si el switch duplica el tráfico entrante, saliente o ambos.

Otra opción es una sonda de red pasiva diseñada para este fin, cuando la arquitectura y el procedimiento de interrupción lo permitan. No inserte un switch no gestionado ni un concentrador de oficina convencional en una ruta de control en funcionamiento. Ese cambio puede alterar la topología, la calidad de servicio, el tratamiento del tráfico multicast, la negociación del enlace y el momento del fallo.

Utilice una interfaz de analizador dedicada. Desactive los protocolos y servicios innecesarios cuando el procedimiento operativo lo permita. El analizador debe observar, no anunciar dispositivos, solicitar direcciones ni convertirse en otro participante de la red de control.

Verifique que la duplicación refleje la realidad

Genere o identifique una trama conocida y confirme que aparece en el analizador. Compruebe que ambas direcciones sean visibles cuando sea necesario. Una sesión de duplicación puede omitir errores de la capa física, descartar paquetes cuando el puerto de destino está sobrecargado o copiar únicamente una dirección.

Compare la velocidad del puerto de origen con la capacidad del destino de duplicación. Duplicar ambas direcciones de un enlace ascendente gigabit ocupado hacia un puerto de un gigabit puede superar el ancho de banda del destino. Restrinja el origen o la ventana de captura en lugar de suponer que cada intervalo ocurrió en la red de control.

Registre el modelo del switch, el firmware, la configuración de duplicación, el puerto de origen, el puerto de destino, el comportamiento de las VLAN y la configuración de la interfaz de captura. Sin ese registro, otro ingeniero no podrá reproducir la medición.

Separe las clases de tráfico EtherNet/IP

EtherNet/IP utiliza mensajería explícita para la gestión de conexiones, la configuración y los diagnósticos, mientras que las E/S cíclicas suelen utilizar transporte UDP. Los intercambios de descubrimiento no demuestran que una conexión de E/S establecida funcione correctamente. Conserve la configuración y el cierre de la conexión alrededor del fallo, no solo los paquetes cíclicos.

Comience con las direcciones IP conocidas del encoder y del controlador. Después, identifique la conexión relevante en lugar de etiquetar cada trama UDP como datos del encoder. Los puertos comunes de EtherNet/IP pueden ayudar a acotar la traza, pero los extremos, la temporización y el contexto de la conexión proporcionan evidencia más sólida.

Conserve la evidencia de ARP, topología y gestión del switch alrededor del evento. Un conflicto de direcciones o una transición del enlace puede aparecer fuera del flujo de E/S filtrado. Guarde la captura sin filtrar y utilice filtros de visualización para el análisis, de modo que el contexto no se descarte permanentemente.

Analice la temporización y los intervalos del RPI

El intervalo de paquetes solicitado define la cadencia de actualización esperada para la conexión de E/S configurada. Mida el tiempo entre llegadas durante un periodo saludable y alrededor del fallo. Busque intervalos ausentes, ráfagas posteriores a una pausa, comportamiento de secuencias duplicadas y un cierre o reapertura de la conexión.

No considere automáticamente que cada paquete posterior al RPI nominal indique un fallo del controlador. Compare el intervalo observado con el comportamiento del tiempo de espera de la conexión configurado en el controlador. Unas variaciones de pocos microsegundos y una interrupción de varios intervalos tienen significados diferentes.

Represente en un gráfico la hora de llegada de los paquetes junto con el bit de fallo del controlador, el estado de la tarea, el evento de la máquina y los registros del switch. Si el flujo de paquetes se detiene antes de que aparezca un evento de enlace inactivo, debe prestar atención al dispositivo de origen o a la ruta ascendente. Si la duplicación sigue detectando tramas del encoder mientras el controlador agota el tiempo de espera, investigue el resto de la ruta y el procesamiento del controlador.

Utilice la evidencia del switch junto con la traza

Lea los contadores de los puertos antes y después de la prueba. Los errores CRC o de comprobación de tramas, las transiciones del enlace, los paquetes descartados, los cambios de velocidad y los eventos del anillo pueden explicar un intervalo sin paquetes. Un analizador conectado por encima del enlace defectuoso quizá nunca reciba las tramas dañadas porque el switch las descarta.

Compruebe el estado de los cables y conectores, las prácticas de apantallamiento y puesta a tierra, el radio de curvatura, la contaminación y la sujeción mecánica. Cambie un solo componente de forma controlada únicamente después de conservar la línea base. Sustituir varios cables y configuraciones del switch a la vez impide identificar la causa.

Confirme la velocidad y el dúplex negociados conforme a la configuración compatible del dispositivo. Evite forzar ajustes sin consultar los manuales del encoder y del switch. Una discrepancia puede generar errores que parezcan depender de la carga.

Proteja la captura y la red

Limite la duración de la captura o utilice un búfer circular para evitar que se llene el disco del analizador. Marque la hora local y la hora de la planta con exactitud. Las trazas de paquetes pueden revelar direcciones, nombres de dispositivos, configuración y comportamiento del proceso, por lo que deben almacenarse con los controles de acceso adecuados.

Elimine la configuración de duplicación después de las pruebas y verifique que el puerto de destino vuelva a su estado previsto. Una duplicación abandonada puede exponer el tráfico de control a un dispositivo no autorizado o consumir recursos del switch.

Nunca realice cambios de configuración basándose únicamente en una traza de paquetes. Correlacione la evidencia con los diagnósticos del controlador, los indicadores del encoder, los contadores del switch y un evento de máquina reproducible. La captura registra el tráfico; no certifica la posición mecánica ni demuestra que el encoder sea preciso.

Convierta las observaciones en una conclusión del fallo

Las tramas se detienen en ambos puntos de captura

Investigue la alimentación del encoder, su estado interno, la conexión del programa ascendente o el enlace común anterior al primer punto de captura. Compruebe si el dispositivo se reinicia o si la conexión se inhibe deliberadamente.

Las tramas aparecen en el encoder, pero no en el enlace ascendente

Concéntrese en la ruta del switch intermedio, la VLAN, el evento del anillo, los errores del puerto, la congestión o el cableado. Repita la prueba con contadores sincronizados antes de cambiar el encoder.

Las tramas llegan a la ruta del controlador, pero el PLC agota el tiempo de espera

Revise la conexión configurada, el RPI, el tiempo de espera, la carga de las tareas del controlador, las direcciones duplicadas y si los paquetes capturados pertenecen a la conexión esperada.

La captura de paquetes resulta valiosa cuando se controlan la ubicación de captura, la temporización y el contexto de red. El objetivo no es obtener un archivo grande de Wireshark, sino un conjunto reducido de evidencias que muestre dónde cambió el intercambio cíclico y qué evento físico o de configuración cambió junto con él.