Objetivo
El objetivo es aprender a utilizar la herramienta Trace de TIA Portal para investigar comportamientos anómalos en un sistema industrial.
El ejemplo parte de una situación muy común en planta: una máquina se para, no deja una alarma clara y, cuando llegamos a mirar, todo parece estar otra vez bien.
Es en esta situación, donde podemos aplicar un diagnóstico con Trace, para analizar las causas de fallo que no se han podido ver a simple vista en el programa.
Vamos a ello.
Dolor real
Este tipo de avería suele venir acompañado de frases que todos hemos escuchado alguna vez:
- “La máquina falla, pero cuando llego ya está todo bien”.
- “No sé si el problema está en la secuencia o en la señal física”.
- “La máquina de estados cambia demasiado rápido y no veo nada online”.
Ahí es donde Trace resulta especialmente útil: permite dejar al PLC vigilando las señales importantes y reconstruir después qué ocurrió realmente.
Qué es Trace en TIA Portal
Trace es una función de diagnóstico que permite registrar variables del PLC durante la ejecución y representarlas en un cronograma.
Puede trabajar con señales analógicas, binarias, variables de DB, marcas, entradas, salidas y periferia, dependiendo del dispositivo. Básicamente, es una herramienta para registrar señales del PLC con contexto temporal y analizarlas después en forma de curvas.
Siemens tiene un documento oficial con la información completa del editor de Trace: manual de funciones de Trace Editor.
Caso de uso
Situación inicial
Tenemos una máquina funcionando con normalidad.
De repente nos llaman porque se ha parado y no ha dejado alarmas. En este ejemplo lo simulamos con un fallo aleatorio en el PLC.
Nos comentan que han reseteado varias veces, que la máquina vuelve a funcionar, pero que tiempo después el fallo aparece otra vez.
Cuando no aparece la causa
En este punto podemos empezar a mirar el PLC, revisar qué condiciones paran la máquina, seguir referencias cruzadas, abrir tablas de observación y tirar de las herramientas habituales.
Sin embargo, pasa el tiempo y no damos con el fallo. Decidimos entonces usar Trace vigilando todas las señales que influyen en el Permiso General de la máquina, normalmente formado por una cadena de condiciones OK. Basta con que una de ellas caiga para que el permiso desaparezca y la máquina se detenga.
Las alarmas de esos permisos aparentemente están bien configuradas y deberían darnos la pista.
Entonces, ¿qué pasa? ¿Cómo seguimos?
Configuración del Trace
Vamos a la herramienta Trace de TIA Portal, en un PLC Siemens S7-1500 para ver qué está provocando la parada que no logramos identificar en el programa.
Señales a registrar
Añadimos todas las señales que sabemos que pueden producir paradas. La idea no es mirar una sola variable, sino preparar un registro de señales PLC que capture el contexto completo alrededor del permiso general.
Muestreo
Definimos cuántas muestras queremos registrar y si el muestreo será por tiempo o por ciclos de scan.
Disparador y pretrigger
El disparador es una parte clave. Definimos cuándo queremos que se inicie el registro y con qué señal. También configuramos un pretrigger en TIA Portal, es decir, un tiempo anterior a la señal de disparo para tener más contexto.
Cargar configuración en el PLC
Una vez preparado el Trace, cargamos la configuración en el PLC para que pueda ejecutarse dentro del controlador.
Curvas y activación del registro
También podemos ajustar la configuración de las curvas: colores, grupos y otros detalles visuales que ayudan a interpretar la captura.
Activamos el proceso de Recording. Desde ese momento el Trace queda armado dentro del PLC, esperando la condición de disparo. Si hemos configurado pretrigger, conservará también el contexto anterior al evento para poder analizar qué ocurrió justo antes.
En este momento el PLC tiene todo preparado. Podemos salir de TIA Portal y volver cuando se repita el fallo, siempre que no se reinicie ni se apague la CPU antes de recuperar la medición.
Análisis de la grabación
Localización de la señal fantasma
Al cabo de un tiempo sabemos que el fallo se ha dado. Entramos al Trace de nuevo, sin sobrescribirlo, y en el diagrama de tiempo vemos dos cosas importantes:
- Se ha dado la condición que inicia la grabación con DB_Demo_Maquina.Trace_Trigger_Parada.
- La grabación en este momento ya ha terminado.
El Trace nos muestra que la señal “fantasma” que estaba quitando el permiso general es DB_Demo_IO.Puerta_Cerrada.
Guardar la medición
Una vez completado el registro, podemos añadirlo a Measurements o medidas. Así queda guardado para un análisis posterior.
Por qué no saltaba la alarma
Ahora ya sabemos que la señal que provoca la parada es DB_Demo_IO.Puerta_Cerrada. La pregunta lógica es: si había alarma, ¿por qué no salta?
Gracias a la información del Trace sabemos que la caída dura muy pocos milisegundos y conocemos la señal exacta. Con el análisis forense ya encaminado, revisamos en detalle esa alarma.
La sorpresa es que el tiempo configurado para los permisos es el valor por defecto del FB. En este caso son 5 segundos.
Lógicamente, con una caída tan corta de la señal no da tiempo a que salte la alarma. La condición que hace parar la máquina no es la alarma, sino la señal física directamente.
Solución y resultado
Las acciones son claras:
- Alinear la lógica de permiso con la lógica de diagnóstico, de forma que toda condición capaz de parar la máquina genere también una alarma o evento visible.
- Ajustar el tiempo de detección de la alarma para que sea coherente con la dinámica real de la señal. En este caso didáctico, se baja a 0 milisegundos para detectar la caída instantáneamente.
Cuando vuelva a ocurrir, ya tendremos una alarma visible en el HMI. Ahora que el problema está claro, podemos avisar a mantenimiento para que revise el sensor, el cableado o la causa física asociada.
Claves prácticas
- Trace permite capturar lo que no vemos online: especialmente cuando la señal cambia muy rápido.
- El pretrigger da contexto: no solo vemos el disparo, también qué pasó justo antes.
- Guardar la medición evita perder la prueba: una vez capturado el fallo, conviene conservarlo para analizarlo con calma.
- Una alarma no siempre explica la parada: si el tiempo de alarma es demasiado alto, la condición puede cortar el permiso sin llegar a mostrarse.
- El objetivo final no es solo encontrar la señal: es dejar un diagnóstico que permita a mantenimiento actuar sobre sensor, cableado o elemento físico.
Artículos relacionados