Alarms and Diagnostics in Siemens TIA Portal – Pro Guide

Hoy vamos a ver cómo gestionar las alarmas en TIA Portal de una forma profesional. Y ya que estamos, vamos a meternos también en el diagnóstico del sistema, porque una cosa sin la otra se queda coja.

Digo de forma profesional, porque veo que hay muchos programadores que no conocen la forma de gestionar correctamente el tema de las alarmas. Esto les lleva a hacer cosas rocambolescas como declarar bits en un DB para lanzar las alarmas y luego copiar ese DB a otro DB para pasarlo a words que luego usan en el HMI. Una locura.

Y esto pasa solo por no saber cómo hacerlo correctamente. O al menos, de una forma muchísimo más profesional y infinitamente menos enrevesada.

La forma que te voy a enseñar es una de las que explico en los cursos de Guorker.com, en el curso de TIA Portal o en el curso extensísimo de WinCC Flexible 2008. Que sí, que es del 2008, pero todo es aplicable en TIA Portal con pequeñas diferencias.

Además, en TIA Portal tienes más herramientas, pero digamos que haber mamado WinCC Flexible 2008 hace que no cometas errores claros como los que veo en muchas aplicaciones a la hora de tratar alarmas y diagnósticos.

How to handle alarms and diagnostics in TIA Portal?

La respuesta corta: separas bien el concepto de alarma de proceso (la que enlazas tú a mano con un array de bits o words) del concepto de diagnóstico del sistema (el que TIA Portal ya trae integrado y que muchos ni tocan). Ambos conviven en el mismo proyecto y ambos acaban, si quieres, en el mismo HMI.

La idea de lo que te voy a contar es poder enlazar de forma coherente, sencilla y mantenible las alarmas en el lado del PLC y del HMI. Nada de bits sueltos aquí y allá que luego nadie sabe de dónde salen cuando llega un compañero nuevo al mantenimiento.

Cómo configurar alarmas y diagnósticos en TIA Portal paso a paso

Vamos al lío. Este es el procedimiento que sigo yo, y que enseño en los cursos, para que las alarmas del PLC lleguen limpias al HMI sin trucos raros:

1. Declara un DB (puede ser optimizado o no, según lo que necesites) con un array de bool del tamaño que vayas a necesitar. Da igual que sean 16 alarmas o 1024, el mecanismo es el mismo.
2. En el programa, activas cada bit del array cuando se cumple la condición de fallo correspondiente (falta de aire, motor en térmico, guarda abierta, lo que sea).
3. En el HMI, en vez de generar una alarma discreta por cada bit y tener que mantener cien objetos sueltos, usas alarmas indexadas apuntando al array. Así, con una sola definición de alarma en el HMI, cubres las 1024 si hace falta.
4. El texto de cada alarma lo parametrizas con el índice, para que en el HMI se vea el texto correcto según qué bit del array se ha activado.

Puede que lo hagas así, o de una forma similar, pero si lo estás haciendo word a word, comparando bit a bit contra un DB intermedio, se te va a abrir un mundo nuevo con este método. Ya verás.

TIA Portal Program_Alarm function: ejemplo de código

Cuando necesitas algo más que un simple bit, por ejemplo, alarmas de usuario con valores asociados (una temperatura, un contador, un texto variable), TIA Portal trae la instrucción Program_Alarm (y su hermana Program_Alarm_8 con hasta 8 valores asociados). Es la forma nativa de generar diagnósticos de programa sin montar tú el cableado de bits a mano.

Un ejemplo típico en SCL, dentro de un bloque de función que controla, por ejemplo, una estación de un transportador:

FUNCTION_BLOCK \"FB_Alarma_Estacion\"
VAR
  Program_Alarm_Instance : Program_Alarm;
END_VAR

VAR_INPUT
  Fallo_Motor : Bool;
  Temperatura_Motor : Real;
END_VAR

BEGIN

  // Llamada a la instrucción Program_Alarm
  #Program_Alarm_Instance(SIG_ID := 1,
                          SIG := #Fallo_Motor,
                          MSG_EVENTS := TRUE,
                          EN_ID := 1);

END_FUNCTION_BLOCK

Con SIG defines la condición que dispara la alarma (el flanco del fallo), y con SIG_ID el identificador único de esa alarma dentro del proyecto. Si necesitas asociar valores como la temperatura del motor en el momento del disparo, usas Program_Alarm_8, que admite hasta ocho parámetros asociados (ASSOC_VALUES) que luego puedes mostrar en el texto de la alarma en el HMI.

La ventaja de usar Program_Alarm frente al método del array a pelo es que el propio sistema de diagnóstico de TIA Portal se entera de estas alarmas y las integra en la vista de diagnósticos del PLC, no solo en el HMI. Eso te da doble visibilidad: la del operario en planta y la tuya cuando te conectas en remoto para ver qué ha pasado.

System Diagnostics en TIA Portal

Aquí es donde mucha gente se pierde. TIA Portal trae un sistema de diagnóstico integrado que va más allá de las alarmas que tú programas a mano. Este diagnóstico recoge:

• Errores de hardware (módulos en fallo, caída de un nodo PROFINET, fusible fundido en una tarjeta de salidas).
• Errores de programa (por ejemplo, un acceso a un puntero nulo o una división por cero si tienes activados los bloques de organización de error correspondientes).
• Las alarmas de usuario que generas tú con Program_Alarm, que se integran en la misma vista.

Para verlo, en el árbol del proyecto tienes la carpeta de Diagnósticos online y offline del PLC. Ahí ves el estado general del sistema, y si entras en el detalle de cada módulo, el histórico de eventos con fecha y hora. Esto te ahorra horas cuando llegas a una máquina que lleva fallando toda la noche y el turno de noche no te ha dejado ni una nota.

Lo interesante es que puedes volcar este mismo diagnóstico del sistema en el HMI, usando el objeto de vista de alarmas del sistema que trae WinCC. Así el operario ve en la misma pantalla tanto tus alarmas de proceso como los fallos de hardware del PLC, sin tener que conectarse con el portátil cada vez que salta un piloto rojo.

Manage HMI alarms in TIA Portal efficiently

Para que la gestión de alarmas en el HMI sea de verdad eficiente, y no un cajón de sastre, ten en cuenta estos puntos que suelo remarcar en los cursos:

• Agrupa por clases de alarma: error, advertencia, información. No metas todo en el mismo saco o el operario dejará de hacer caso a las alarmas, que es lo peor que puede pasar.
• Usa alarmas indexadas siempre que puedas, como hemos visto arriba con el array. Menos objetos que mantener, menos probabilidad de despiste al añadir una alarma nueva.
• Da contexto en el texto: no pongas solo \"Fallo motor\", pon \"Fallo motor cinta 3, térmico disparado\". El operario te lo agradecerá y tú también, cuando te llame a las tres de la mañana y te lo lea por teléfono.
• Revisa el histórico periódicamente. Una alarma que salta 200 veces al día no es una alarma, es un síntoma de que algo en el proceso no funciona bien y nadie lo ha mirado.

Si además quieres ver cómo se hace esto mismo pero directamente en WinCC, sin pasar por TIA Portal, tengo un post específico sobre cómo crear alarmas en WinCC que complementa justo lo que hemos visto aquí.

Vídeo explicativo

Te dejo con el vídeo donde lo explico todo sobre la marcha, con el proyecto abierto en TIA Portal:

Qué te ha parecido

Espero que te haya servido de verdad esta guía sobre alarmas y diagnósticos en TIA Portal, y que a partir de ahora dejes atrás los DB intermedios y los bits sueltos que nadie entiende.

Si quieres profundizar más en el tema, con proyectos reales y ejercicios paso a paso, todo esto lo puedes aprender en Guorker.com en todas sus vertientes o adquiriendo el curso de TIA Portal aquí en el blog.

Espero tus comentarios.