Explicación general
Diagnosticar el estado de las comunicaciones es sencillo. De hecho, iFix ya evalúa el estado de comunicación de cada tag de forma individualizada, y genera alarmas del tipo "COMM" que salen por el visor de alarmas.
Sin embargo, en ocasiones interesa crear un tag específico en la PDB para representar el estado de un enlace de comunicación con campo. Esto permite representarlo en una pantalla, alarmarlo, historizarlo, etc.
En este artículo vamos a ver un ejemplo de cómo implementar ésto en iFIX aprovechando algunos tipos de tags específicos de iFIX , que nos acortarán bastante el camino.
Base técnica de la solución
Se parte de la base de un tag que esté apuntando al PLC en cuestión. Cualquier tipo de tag debería funcionar.
En el ejemplo, tenemos un tag "ITEM1", del tipo AI, que está leyendo del driver OPC-DA
Este tag AI tiene una serie de atributos, descritos en este enlace.
Normalmente en las pantallas utilizamos el "F_CV" para representar su "Current Value" pero en realidad tenemos varios atributos que hacen referencia a su estado de alarma y el tipo de alarma que esté sufriendo.
En el ejemplo, tenemos un tag "ITEM1", del tipo AI, que está leyendo del driver OPC-DA
Este tag AI tiene una serie de atributos, descritos en este enlace.Normalmente en las pantallas utilizamos el "F_CV" para representar su "Current Value" pero en realidad tenemos varios atributos que hacen referencia a su estado de alarma y el tipo de alarma que esté sufriendo.
Elaboramos una pequeña pantalla para ver ésto mejor. En la imagen de abajo se puede ver la representación del valor de "ITEM1" a través de su atributo "F_CV" (izquierda de todo) seguido de otros atributos que hacen referencia a su estado de alarma.
Si ahora se provoca un corte de comunicación (p.ej.parando el servidor OPC) vemos que se genera una alarma de COMM. Se trata de una alarma automática del sistema. No se ha definido explícitamente ninguna alarma en "ITEM1".
En la pantalla de ejemplo se puede ver cómo también se informa del problema en los atributos que se ha representado en el ejemplo (A_CUALM, A_CHALM, A_LAALM, A_PRI y A_SCAN)
Si ahora se provoca un corte de comunicación (p.ej.parando el servidor OPC) vemos que se genera una alarma de COMM. Se trata de una alarma automática del sistema. No se ha definido explícitamente ninguna alarma en "ITEM1".En la pantalla de ejemplo se puede ver cómo también se informa del problema en los atributos que se ha representado en el ejemplo (A_CUALM, A_CHALM, A_LAALM, A_PRI y A_SCAN)
Desarrollo de la solución
Teniendo en cuenta todo lo anterior, lo que se va a hacer es entrar en la PDB 2 nuevos tags:
- Un primer tag "EV_ALM_COMM01", del tipo "EV - Event Action"
Éste va a leer el valor de "ITEM01" (en concreto su estado de alarmabilidad) y en función de éste, escribir un 0 o un 1 en el siguiente tag - Un segundo tag "DIA", del tipo "DA - Digital Alarm"
Que es donde el tag "EV_ALM_COMM01" va a volcar este 1 (si tenemos problema de comunicaciones) o ese 0 (si estamos comunicando bien)
La definición de "EV_ALM_COMM01" (tag tipo "EV") sería:
La definición de "DIA" (tag tipo "DA") sería:
 Se puede ver como es un tag que apunta a las memorias internas del simulador (no comunica con PLC) |  Se ha definido que "CLOSE" sea el estado de alarma (es decir, cuando el valor sea "1".También se ha vinculado esta alarma a todas las ALARM_AREAS y se le ha dado una prioridad de "LOW" |
 Es muy importante habilitar el "output" en este tag, para que así le puedan escribir desde fuera.En concreto en este caso le escribirá desde fuera el tag anterior "EV_ALM_COMM01" | |
Referencias
C Parameter on SAC Suppress COMM Alarms for Alarm Summary