Cuando iFIX comunica a través de IGS podemos definir cada uno de los tags en IGS (direccionamiento estático) o bien definir únicamente la conexión contra el dispositivo de campo (sin tags) para que sea directamente en la PDB de iFIX donde definamos cada tag (direccionamiento dinámico)

  • El direccionamiento estático
    Tiene la ventaja de que los tags serán publicados por IGS en cualquiera de sus modalidades (OPC-DA, UA, Modbus, MQTT, etc) al estar definidos a ese nivel.

  • El direcciomamiento dinámico
    Tiene la ventaja de que los tags se definen una única vez, en iFIX.
    Si éste es el único sistema que ha de leerlos, las ventajas son claras en cuando a simplificación de la configuración

Esta misma situación puede ocurrir en cualquier otro sistema que vaya a comunicar a través de IGS (como por ejemplo Cimplicity).


A continuación se presenta un caso de ejemplo donde pueden verse estos 2 tipos de direccionamiento y cómo se implementan

Esquema general (Caso comunicación Modbus)

Fuente de datos: Simulador "Modsim"

Tenemos en la IP 192.168.1.110 un simulador modbus escuchando

Pasarela IGS

En la máquina donde tenemos IGS e iFIX instalado (IP 192.168.1.112), configuramos un tag estático apuntando al Modsim. Para ello, seguimos los pasos siguientes

Canal “Channel2”

Configuración estándar, a través del adaptador de red que corresponda.
Nota: En este nivel de Channel, el puerto al que se hace referencia no es el de comunicación con el esclavo (ModSim) sino por el que escuchará IGS en el propio esclavo Modbus que incluye por defecto (y que no se utiliza en este ejemplo)

Device “test2”

Configuración estándar, apuntando a la dirección modbus donde reside el Modsim (192.168.1.110.1)
y el puerto 502

Nota:
Ponemos ".1" al final de la dirección Modbus que corresponde al Modsim, porque en esa misma máquina hay ya otro esclavo Modbus en la posicion "0". En condiciones normales pondríamos un ".0"


Tag OPC estático “test”

El tag apunta a la posición 40001 del Modsim, con refresco cada medio segundo (500ms).
Imponemos que el formato sea "word" (16 bits)


Comprobación rápida

Desde un cliente OPC-DA verificamos que leemos el tag estático definido en IGS

Cliente final: iFIX

En la SCU de iFix, damos de alta el driver IGS. Luego arrancamos y vamos a la PDB. 


Creamos un tag de tipo "AI" contra el driver IGS. Hacemos un “browse” para buscar la información en IGS

Al hacer “browse” vemos channel, device y tag estático creado en IGS:


Probamos primero a añadir el tag estático, y comprobamos como se lee en la PDB.
Nótese como en esta ocasión el "I/O Addr" del tag corresponde a una dirección OPC ("Channel2.test2.test")


A continuación añadimos un segundo tag dinámico (una posición de memoria no definida explícitamente en el IGS, pero que sabemos existe también en el ModSim)


Nótese que en esta ocasión el "I/O Addr" es cualquier dirección modbus dentro del rango que tenga el dispositivo referido (En este caso "Channel2.test2.4001") sin que ésta haya sido definida como variable OPC en IGS.



La importancia del formato de la información!!!

En ocasiones puede haber problemas debido a estar utilizando diferentes formatos en diferentes extremos de la conexión modbus. En el caso de ejemplo, el simulador ModSim está utilizando registros con un formato de tipo WORD:


Por consiguiente, para que IGS interprete lo mismo, debe utilizar el mismo tipo de formato.


El siguiente ejemplo ilustra el uso de formatos diferentes a nivel de IGS. Obsérvese como únicamente el registro definido como "Word" ve la misma inforrmación que vemos en el ModSim (en este caso "11"), mientras que el registro definido como "Double" hace una interpretación distinta, a pesar de estar apuntando a la misma dirección.


Si estamos trabajando con tags dinámicos, es decir, definiendo el tag en iFIX y no en IGS, entonces es en este nivel donde hemos de definir el formato de la información, para evitar tener este tipo de problemas

En el ejemplo, el tag dinámico "TAG2" utiliza el formato por defecto de iFIX y no es capaz de resolver correctamente la misma dirección de ModSim de los ejemplos anteriores. Por el contrario, "TAG3" tiene definido explícitamente el formato y consigue interpretarlo correctamente.


Los formatos (datatypes) que iFIX acepta serían los siguientes:

Channel1.Device1.400001@Float
Channel1.Device1.400001@Short
Channel1.Device1.400001@BCD
Channel1.Device1.400001@DWord
Channel1.Device1.400001@Long
Channel1.Device1.400001@LBCD
Channel1.Device1.400001@Double


Para más información sobre formatos

A nivel de IGS


A nivel de iFix (PDB blocks)