Planificación de capacidad de CompactLogix L35E EtherNet/IP

El CompactLogix 1769-L35E sigue siendo común en máquinas que han superado la vida útil de su plan de red original. Los problemas de expansión suelen comenzar cuando una lista de dispositivos se trata como un conteo de conexiones. La capacidad de EtherNet/IP depende del tipo de tráfico que genera cada dispositivo, de la frecuencia con la que intercambia datos y de los recursos del controlador que la aplicación ya utiliza. Por ello, una revisión segura comienza con el proyecto en funcionamiento y los diagnósticos, no con una regla genérica de dispositivos por puerto.

La planificación de conexiones debe tener en cuenta el tráfico configurado, las tasas de actualización y los riesgos del ciclo de vida, en lugar del número de conectores Ethernet.

Comience con el límite documentado del controlador

El Manual del usuario de los controladores 1769 CompactLogix de Rockwell Automation documenta que el L35E admite 100 conexiones CIP. Ese es un límite de recursos, no un permiso para conectar 100 dispositivos. Un solo dispositivo puede requerir más de una conexión, mientras que algunas comunicaciones pueden compartir una conexión optimizada. La revisión del firmware, la configuración de los módulos, las etiquetas producidas y consumidas, los mensajes almacenados en caché y los clientes HMI o de supervisión también afectan al total final.

El controlador también es un producto descatalogado. Rockwell indica que el 1769-L35E está descatalogado desde el 20 de diciembre de 2020. Esto no vuelve inutilizable un sistema que funciona, pero cambia la decisión de ingeniería: un problema de capacidad debe evaluarse junto con la disponibilidad de repuestos, el soporte de firmware, la exposición a riesgos de ciberseguridad y el costo de una falla imprevista.

Elabore un inventario de conexiones a partir del proyecto

Abra el proyecto sin conexión que corresponda al controlador en funcionamiento y enumere cada adaptador de E/S configurado, variador, etiqueta producida o consumida, ruta de mensajes, servidor de datos HMI, historiador, puerta de enlace y conexión de programación. Registre si cada intercambio corresponde a E/S cíclicas, datos producidos, un mensaje explícito o una consulta periódica de un cliente. No asigne una cantidad fija de conexiones basándose únicamente en el nombre del fabricante. La configuración real es la referencia principal.

En el caso de las E/S distribuidas, compruebe si el formato de comunicación seleccionado crea conexiones directas con los módulos o una conexión optimizada para el rack. En las instrucciones MSG, identifique cuáles están almacenadas en caché y si varios mensajes pueden estar activos al mismo tiempo. En los sistemas de supervisión, cuente las rutas de comunicación independientes y revise su estrategia de consulta. Una hoja de cálculo debe vincular cada conexión supuesta con un objeto del proyecto o una configuración de cliente probada.

Separe el conteo de conexiones de la carga de paquetes

Un controlador puede mantenerse por debajo de su límite de conexiones y aun así ofrecer un rendimiento de red deficiente. Los intervalos de paquetes solicitados, la frecuencia de los mensajes, el tamaño de los paquetes, el comportamiento multicast, la configuración de los switches y las ráfagas de varios clientes influyen en la carga de paquetes. Los RPI muy rápidos deben justificarse por el proceso mecánico y la respuesta de control requeridos; hacer que todos los dispositivos sean más rápidos no mejora la máquina.

Establezca una línea base mientras la máquina produce normalmente. Registre el uso de conexiones, los contadores de errores de Ethernet, los mensajes perdidos o agotados por tiempo de espera, el estado de las E/S, la capacidad de respuesta de la HMI y el comportamiento del ciclo del controlador. Repita la captura durante el arranque, las descargas de recetas, las ráfagas de alarmas, el acceso de mantenimiento y otros picos creíbles. Los promedios pueden ocultar el breve intervalo que provoca una falla intermitente.

La conmutación administrable, una topología documentada y mediciones repetibles permiten diagnosticar las fallas intermitentes de capacidad.

No utilice un 1769-AENTR como segundo puerto del L35E

Un 1769-AENTR es un adaptador EtherNet/IP para un banco remoto de E/S Compact controlado a través de la red. No es una interfaz Ethernet de expansión que aumente el grupo de comunicaciones del controlador L35E, ni puede conectarse como un segundo puerto del controlador para desviar el tráfico de HMI o de mensajes de la interfaz integrada. Diseñar basándose en esa suposición crea una topología que no puede realizar la función prevista.

Si las E/S remotas son adecuadas, un adaptador puede consolidar las E/S físicas en otra ubicación, pero la conexión de E/S resultante aún termina en el controlador. Si la aplicación requiere más capacidad de comunicaciones, una segunda red independiente, funciones de seguridad modernas o un soporte de ciclo de vida más prolongado, la solución puede ser migrar a una familia de controladores más nueva en lugar de añadir otro adaptador.

Reduzca la carga evitable sin ocultar el problema

La optimización debe conservar los requisitos del proceso. Elimine las rutas abandonadas y los clientes sin uso. Consolide las conexiones de E/S cuando la plataforma y los tipos de módulos lo permitan. Almacene en caché únicamente las conexiones MSG que necesiten una ejecución repetida rápida y secuencie los mensajes no críticos para que no se abran todos a la vez. Aumente un RPI o un intervalo de consulta solo después de confirmar que el tiempo de detección, los enclavamientos, las alarmas y la calidad del control siguen siendo aceptables.

Utilice switches industriales administrables y documente la configuración de VLAN, multicast e IGMP cuando corresponda. Un switch puede controlar las inundaciones innecesarias y mejorar la visibilidad, pero no puede crear recursos de conexión para el controlador. Del mismo modo, añadir un switch no administrable cambia el número de puertos, no la capacidad del controlador.

Diagnostique metódicamente una posible falla de capacidad

Primero confirme el proyecto en funcionamiento, el número de catálogo del controlador, la revisión del firmware y la topología de red. Después compare las conexiones configuradas con los diagnósticos en vivo. Busque módulos de E/S que alternen entre funcionamiento y falla, instrucciones MSG que agoten el tiempo de espera bajo carga máxima o valores de HMI que queden obsoletos mientras la lógica del controlador continúa ejecutándose.

Cambie una sola variable a la vez. Desconecte un cliente no esencial aprobado, suspenda un servicio de consulta no crítico o secuencie temporalmente los mensajes durante una ventana de mantenimiento controlada. Si el síntoma cambia, mida la carga antes y después en lugar de declarar que el problema está resuelto tras una sola hora tranquila. Nunca prolongue los tiempos de espera ni suprima las alarmas de comunicación únicamente para ocultar la congestión.

Ponga en servicio las ampliaciones con pruebas de falla

Antes de añadir un dispositivo, defina el tipo de conexión, el requisito de actualización, el responsable y la respuesta ante fallas. Pruebe la producción normal y la peor demanda simultánea creíble. Interrumpa el nuevo dispositivo, restablézcalo, reinicie su alimentación de red y confirme que el controlador, la HMI y las alarmas distinguen los datos incorrectos u obsoletos de un estado válido del proceso. Verifique que la recuperación no reinicie inesperadamente el equipo.

Conserve el inventario, las capturas de diagnóstico, la configuración de los switches y los resultados de aceptación junto con la copia de seguridad del sistema de control. Para consultar opciones de hardware actuales, revise los sistemas PLC y PAC; para switches administrables y componentes de red, utilice la colección de comunicación y redes. La conclusión editorial es sencilla: una ampliación del L35E solo es justificable cuando su carga máxima medida, su comportamiento ante fallas y su plan de ciclo de vida están documentados.