Cómo optimizar el tiempo de barrido y solucionar las fallas de exceso del temporizador de vigilancia de IC695CPU310

Comprender la causa raíz de la falla por exceso del temporizador de vigilancia del RX3i

Una falla de "Watchdog Timer Exceeded" en el PACSystems RX3i IC695CPU310 de GE Fanuc no significa automáticamente que a la CPU le falte capacidad de procesamiento. Nunca debe tratar este error simplemente aumentando la configuración del temporizador de vigilancia del software. La causa principal es un aumento inesperado en el tiempo de ejecución de un solo barrido del programa del PLC. Las condiciones anómalas en los bucles, las llamadas excesivas a funciones recursivas o las operaciones intensivas de memoria suelen provocar estos retrasos de ejecución.

Según las directrices de referencia de las CPU de GE Fanuc, el temporizador de vigilancia del software detecta retrasos anómalos en la finalización del barrido. El rango configurable del temporizador de vigilancia del software abarca de 10 ms a 2550 ms, ajustable en incrementos de 10 ms. Los ingenieros de campo siempre deben localizar el cuello de botella del programa que aumenta el tiempo de barrido en el peor caso, en lugar de ocultar fallas lógicas subyacentes con tiempos de espera prolongados.

Diferenciar entre fallas del temporizador de vigilancia del software y del hardware

Los ingenieros deben identificar el mecanismo exacto, de hardware o software, que provoca la falla antes de modificar el código.

• Fallas del temporizador de vigilancia del software: Se producen cuando un solo barrido de ejecución supera el umbral programado del temporizador de vigilancia. Entre los desencadenantes habituales se incluyen bucles FOR o WHILE masivos, bloques de funciones recursivas, operaciones de matrices sin limitación, procesamiento intensivo de cadenas, comunicaciones Ethernet concentradas o escrituras directas en memoria no volátil.
• Fallas del temporizador de vigilancia del hardware: Representan la activación de un mecanismo interno de seguridad de la CPU. A diferencia de los errores de software, las fallas del temporizador de vigilancia del hardware suelen requerir un ciclo completo de apagado y encendido físico para borrarse en plataformas de CPU antiguas como la IC695CPU310.

Cuando se produce un apagado inesperado, acceda a la tabla de fallas de PAC Machine Edition (PME). Examine la descripción de la falla, el código de falla, la marca de tiempo y el recuento de ocurrencias. Proceda a optimizar la lógica solo si el registro de diagnóstico indica explícitamente la expiración del temporizador de vigilancia del software.

Analizar la dinámica del barrido: barrido promedio frente al barrido máximo en el peor caso

Muchos ingenieros de automatización se centran únicamente en el tiempo promedio de exploración del programa, lo que crea un punto ciego peligroso. Un sistema con un tiempo de barrido promedio de 18 ms puede aumentar fácilmente hasta 240 ms durante determinados disparadores condicionales. Si el límite del temporizador de vigilancia está establecido en 200 ms, el PLC activará inmediatamente una falla de parada.

La lógica condicional intensiva suele causar estos apagados aleatorios. Operaciones como los cálculos diarios de informes por lotes, el archivado de datos históricos o las copias masivas de memoria se ejecutan durante un solo ciclo de exploración, aumentando el tiempo máximo de ejecución.

Métodos prácticos para reducir el tiempo de exploración en el controlador IC695CPU310

Optimizar los ciclos de exploración mantiene los bucles de control receptivos en instalaciones de envasado de alta velocidad, tratamiento de agua y fabricación continua. Aplique estas técnicas de ingeniería para reducir el tiempo máximo de barrido:

• ⚙️ Implementar segmentación temporal para bucles grandes: Nunca ejecute bucles FOR o WHILE masivos en un solo ciclo de barrido. Divida el procesamiento de matrices en bloques más pequeños distribuidos entre varios barridos consecutivos mediante índices de máquinas de estados.
• ⚙️ Auditar las llamadas recursivas y los bloques de funciones: Compruebe el árbol de llamadas de bloques de PAC Machine Edition. Elimine las llamadas recursivas indirectas en las que la función A activa la función B y esta, accidentalmente, vuelve a llamar a la función A bajo determinadas ramas lógicas.
• ⚙️ Cambiar de un manejo continuo de datos a uno controlado por eventos: Evite copiar o escalar miles de registros analógicos en cada exploración. Ejecute las fórmulas matemáticas intensivas y la clasificación de matrices solo cuando se activen indicadores de cambio de datos.
• ⚙️ Distribuir las tareas de comunicación Ethernet y serie: Distribuya las comunicaciones activas, como Modbus, SRTP o EGD, entre varios ciclos mediante una estrategia de consulta secuencial, en lugar de consultar todos los nodos externos a la vez.
• ⚙️ Limitar las escrituras en la memoria flash no volátil: Las llamadas lógicas directas que escriben datos operativos en la memoria no volátil consumen un tiempo considerable de CPU. Active las escrituras en la memoria flash periódicamente o al completar un lote, en lugar de hacerlo en cada barrido lógico.

Flujo de trabajo paso a paso para la resolución de problemas en campo

Siga esta secuencia metódica de ingeniería para eliminar de forma segura los picos del tiempo de exploración:

1. Identificar el origen de la falla: Compruebe la tabla de fallas de PME para confirmar una activación del temporizador de vigilancia del software.
2. Capturar las métricas de referencia: Registre el barrido promedio de la CPU, el barrido máximo en el peor caso y la configuración actual del tiempo de espera del temporizador de vigilancia.
3. Rastrear los cuellos de botella del código: Busque bucles sin limitación, transferencias continuas de matrices, comunicaciones concentradas y escrituras en la memoria flash.
4. Reestructurar la lógica: Aplique máquinas de estados, algoritmos de segmentación temporal y bloques lógicos controlados por eventos para distribuir la carga de procesamiento.
5. Reevaluar el rendimiento: Supervise los tiempos máximos de exploración durante varios turnos operativos con la carga máxima de producción.
6. Ajustar el margen del temporizador de vigilancia: Establezca el límite final del temporizador de vigilancia del software ligeramente por encima del tiempo de barrido en el peor caso recién establecido para mantener un margen de seguridad fiable.

Escenario de aplicación: optimización del sistema transportador de una línea de embotellado

En una planta de embotellado de bebidas de alta velocidad controlada por un IC695CPU310, la línea de producción experimentaba fallas intermitentes de parada del PLC cada pocos días durante los cambios de turno.

La causa raíz: Durante las transiciones de turno, una subrutina activa de lógica de escalera ejecutaba un bucle sin limitación que clasificaba, actualizaba y copiaba 4.000 registros de seguimiento de productos en una matriz de archivado dentro de una sola exploración. Esto elevaba el tiempo máximo de barrido de los 22 ms habituales a 265 ms, superando el umbral de 200 ms del temporizador de vigilancia del software.

La solución: Nuestro equipo de ingeniería reestructuró el algoritmo de clasificación en una máquina de estados con segmentación temporal que procesaba 200 registros por ciclo de exploración durante 20 barridos consecutivos. Esta modificación redujo el tiempo máximo de barrido de 265 ms a 38 ms, eliminando por completo el problema de activación del temporizador de vigilancia sin modificar los componentes de hardware.

Preguntas frecuentes (FAQ)

P1: Nuestra CPU310 activa regularmente fallas de exceso del temporizador de vigilancia. ¿Significa esto que la velocidad de procesamiento de nuestra CPU es demasiado lenta y debe reemplazarse?
Respuesta: No necesariamente. Reemplazar la CPU debería ser la última opción. La mayoría de los errores del temporizador de vigilancia se deben a una lógica de programa mal estructurada, operaciones de bucle sin limitación o ráfagas repentinas de comunicación. Puede eliminar los picos de barrido reestructurando los cálculos intensivos en máquinas de estados con segmentación temporal distribuidas entre varios ciclos lógicos. Considere una actualización de hardware solo si el tiempo de barrido promedio de referencia sigue cerca de la capacidad de la CPU después de reestructurar el código.

P2: ¿Podemos establecer de forma segura el temporizador de vigilancia del software en su valor máximo de 2550 ms para evitar las activaciones?
Respuesta: Aunque el menú de configuración de la CPU permite físicamente hasta 2550 ms, hacerlo es una mala práctica de ingeniería. Extender tanto el límite oculta errores lógicos críticos, como bucles infinitos o llamadas recursivas bloqueadas. En la automatización de procesos críticos, una CPU detenida que tarde 2,5 segundos en activarse puede causar graves riesgos operativos y de seguridad. Mantenga el límite del temporizador de vigilancia ligeramente por encima del tiempo de barrido real en el peor caso, con un margen de seguridad razonable.

P3: Según la experiencia en campo, ¿cuál es la mejor manera de rastrear qué bloque específico provoca un pico en el tiempo de exploración?
Respuesta: Utilice las herramientas de diagnóstico de PAC Machine Edition junto con temporizadores de ejecución personalizados. Inserte lecturas de marcas de tiempo del sistema antes y después de los bloques de funciones sospechosos para registrar las duraciones máximas de ejecución en registros de seguimiento. Compare estas lecturas con los registros de estado de la máquina para descubrir qué eventos de producción, como cambios de lote, generación de informes o consultas de la HMI, desencadenan la carga máxima de exploración.

Perspectivas del autor y opinión experta

"Durante nuestros años brindando asistencia para equipos de automatización industrial en Ubest Automation Limited, a menudo vemos que los equipos de campo intentan resolver las fallas del temporizador de vigilancia del PLC aumentando arbitrariamente la configuración del temporizador o comprando hardware nuevo. En plataformas como PACSystems RX3i, los picos del tiempo de exploración casi siempre se deben a una gestión ineficiente de los datos o a comunicaciones sin limitación. Adoptar un enfoque disciplinado que priorice el software ahorra un tiempo de inactividad considerable y prolonga la vida útil del hardware de control existente."
— Equipo de ingeniería de Ubest Automation Limited

¿Busca hardware GE Fanuc fiable y asistencia experta?

Tanto si está solucionando problemas en sistemas antiguos como si busca piezas de repuesto para la automatización de fábricas, Ubest Automation Limited proporciona componentes PLC originales y probados, módulos DCS y soluciones de control industrial.

Explore componentes originales de GE Fanuc y PACSystems en Ubest Automation Limited.