Andean SPU

Colombia PU

Práctica Local de Programación de Sistemas de Control BPCS

 Tabla de contenido
Página
1. INTRODUCCION ................................................................................................................................................ 1
2. OBJETIVOS ......................................................................................................................................................... 1
3. ALCANCE ............................................................................................................................................................ 1
3.1. Normas y estándares aplicables ............................................................................................................ 1
3.2. Glosario de términos ............................................................................................................................. 1
4. GUIA DE ASIGNACION DE NOMBRES ............................................................................................................ 3
4.1. CONSIDERACIONES GENERALES ................................................................................................. 3
4.2. GUIAS GENERALES DE IDENTIFICACION FUNCIONAL ........................................................... 4
4.3. CONVENCION DE ASIGNACION DE NOMBRES .......................................................................... 7
4.4. Uniformidad en la asignación de nombres – P&IDs, bases de datos de Controladores, bases de
datos HMI ........................................................................................................................................................... 7
5. GUIA DE PROGRAMACION DE PLC ............................................................................................................... 8
5.1. CRITERIOS GENERALES DE MANEJO DE SALIDAS DE CONTROL ........................................ 9
5.2. CREACION DE TAGS – ALCANCE LOCAL (O ALCANCE DE PROGRAMA) vs ALCANCE
DE CONTROLADOR ...................................................................................................................................... 10
5.3. TAREA PRINCIPAL .......................................................................................................................... 12
5.4. CONFIGURACION DE PROGRAMAS............................................................................................ 13
5.5. PROGRAMA PRINCIPAL (MainProgram) ....................................................................................... 13
5.6. LOGICA DE ENTRADAS ANALOGICAS (Rutina X_AreaZ_AI - Instrucción AOI_AIN)............ 14
5.7. LOGICA DE MOTORES CONVENCIONALES NO REVERSIBLES (Rutina X_AreaZ_Motor
- Instrucción AOI_FVNR) ................................................................................................................................ 18
5.8. LOGICA DE VALVULAS DISCRETAS (Rutina X_AreaZ_Valve - Instrucción AOI_Valve) ........ 20
5.9. LOGICA DE ENTRADAS DISCRETAS (Rutina X_AreaZ_Switch - Instrucción AOI_Switch) ..... 24
5.10. LOGICA DE CONTROLADORES (Rutina X_AreaZ_PID - Instrucción PID) ................................ 25
5.10.1 ORGANIZACIÓN EN LA RUTINA FBD ..................................................................................................... 25
5.10.2 GENERALIDADES ...................................................................................................................................... 26
5.10.3 LAZO CONVENCIONAL DE CONTROL.................................................................................................... 26
5.10.4 MANEJO DE ENCLAVAMIENTOS ............................................................................................................ 34
5.10.5 LAZOS EN PARALELO ............................................................................................................................... 35
5.10.6 LAZOS EN CASCADA ................................................................................................................................. 38
5.11. LOGICA DE TOTALIZADORES ..................................................................................................... 42
5.12. FUNCIONES VARIAS ...................................................................................................................... 43
5.12.1 LOGICA DE FECHA Y HORA .................................................................................................................... 44
5.13. CRITERIOS DE PROGRAMACION DE REDES DE COMUNICACIONES ................................. 45
5.13.1 RED ETHERNET ......................................................................................................................................... 45
5.13.2 RED CONTROLNET ................................................................................................................................... 48
5.13.3 RED MODBUS ............................................................................................................................................ 54
5.14. LOGICA DE DIAGNOSTICOS ......................................................................................................... 64
5.14.1 TIPOS DE DATOS DEFINIDOS POR EL USUARIO (UDTs) .................................................................... 65
5.14.2 RUTINA DiagMain ...................................................................................................................................... 68
5.14.3 RUTINA R00_PowerSupply ......................................................................................................................... 69
5.14.4 RUTINA R01_ProcessMem ......................................................................................................................... 70
5.14.5 RUTINA R02_RedundancyState .................................................................................................................. 75
5.14.6 RUTINA R03_ProcessorInd......................................................................................................................... 75
5.14.7 RUTINA R04_LOCAL.................................................................................................................................. 76
5.14.8 RUTINA RXX_CNETYY ............................................................................................................................... 78
5.14.9 RUTINA RXX_CNETYY_NZZ ...................................................................................................................... 82
5.14.10 RUTINA RXX_CheckRemProc ................................................................................................................ 86
5.15. RECOMENDACIONES SOBRE LA DOCUMENTACION DEL PROYECTO DE PLC................ 92
5.16. MANEJO DE FALLAS DEL PLC ..................................................................................................... 97
6 GUIA DE PROGRAMACION HMI ................................................................................................................. 101
6.1 COMPONENTES GENERALES DEL SISTEMA DE SUPERVISION ......................................... 101
 6.2 SISTEMA DE COMUNICACIONES - ARQUITECTURA ............................................................ 102
6.3 ESTRUCTURA DE BASE DE DATOS DE TAGS HMI - GENERALIDADES ............................ 105
6.4 PRIORIZACION DE FRECUENCIAS DE ADQUISICION DE DATOS ...................................... 107
6.4.1 Sistemas Wonderware con PLCs Allen Bradley: ............................................................................................. 107
6.4.2 Sistema Factory Talk View SE con PLCs Allen Bradley: ................................................................................ 114
6.5 CONFIGURACION DE APLICACIÓN HMI TIPICA EN FT VIEW SE ....................................... 118
6.5.1 Seguridad ......................................................................................................................................................... 118
6.5.2 Sistema de alarmas .......................................................................................................................................... 128
6.5.3 Implementación del sistema de tendencias ...................................................................................................... 131
6.5.4 Resolución típica de la aplicación ................................................................................................................... 135
6.5.5 Color de fondo de las pantallas ....................................................................................................................... 135
6.5.6 Distribución de los elementos en pantalla ....................................................................................................... 135
6.5.7 Organización de la base de datos de tags ....................................................................................................... 141
6.5.8 Generalidades sobre objetos de Factory Talk View para dispositivos ............................................................ 143
6.5.9 Transmisores ................................................................................................................................................... 143
6.5.10 Válvulas ..................................................................................................................................................... 152
6.5.11 Motor ......................................................................................................................................................... 157
6.5.12 Switch......................................................................................................................................................... 157
6.5.13 PID............................................................................................................................................................. 157
6.6 IMPLEMENTACION HMI DEL SISTEMA DE DIAGNOSTICOS:.............................................. 158
6.6.1 Base de datos de tags ....................................................................................................................................... 158
6.6.2 Presentación de Pantallas ............................................................................................................................... 159
6.6.3 Registro histórico de datos .............................................................................................................................. 164
7 ANEXOS .......................................................................................................................................................... 165
7.1 Explicación Filtro Digital en Tarjetas de Entrada analógica ............................................................. 165
7.2 Implementación de la instrucción de entrada analógica AOI_AIN ................................................... 165
7.3 Implementación de la instrucción de control de motores AOI_FVNR ............................................. 171
7.4 Implementación de la instrucción de control de válvulas discretas AOI_Valve ............................... 173
7.5 Ejemplo de uso de Lazos en modo Oversampling ............................................................................ 178
8 NOTAS ............................................................................................................................................................. 179

Copyright  2007, BP. All rights reserved. The information contained in this document is
subject to the terms and conditions of the agreement or contract under which the document
was supplied to the recipient’s organization. None of the information contained in this
document shall be disclosed outside the recipient’s own organization without the prior
written permission of BP, unless the terms of such agreement or contract expressly allow.
1. INTRODUCCION
El sistema de Control de una Facilidad de Producción está compuesto de diversos elementos
(transmisores, elementos finales de control, Controladores Lógicos Programables y el sistema de
supervisión (HMI), los cuales son programados y configurados de acuerdo a los requerimientos
específicos de cada una de las áreas de la planta y del proceso. Para el caso de los Controladores esta
programación se realiza muchas veces siguiendo lineamientos internos de los contratistas de
automatización (o del propio programador en muchos casos), lo que ocasiona falta de uniformidad en
estos programas.

Esta situación se constituye en un riesgo para la operación de los sistemas debido a las siguientes
consideraciones:
• Mayor tiempo de respuesta para la resolución de urgencias en planta: Al no existir una
estandarización del código, los encargados de mantenimiento deben invertir más tiempo
comprendiendo los programas implementados, ocasionando demoras en la atención de estas
situaciones.
• Mayor tiempo en la implementación de los proyectos de Control: Al no existir una guía de
implementación, los contratistas deben invertir más tiempo diseñando la solución de control, y
ajustando su lógica a las condiciones específicas de la planta.
• Posible omisión de requerimientos: Al no existir una estandarización se pueden omitir
requerimientos importantes de operación (por ejemplo, no cumplir con los requerimientos de
los Sistemas Instrumentados de Seguridad para alcanzar los niveles de integridad requeridos).

2. OBJETIVOS
Esta Práctica Local de Programación tiene como objetivo proveer una guía para el diseño,
programación de la aplicación, instalación y mantenimiento de los sistemas de Control BPCS, con el fin
de estandarizar los criterios de diseño y las prácticas de instalación y de mantenimiento de estos
sistemas.

3. ALCANCE
Esta especificación abarca los sistemas de control BPCS de las Facilidades de BP Colombia y
específicamente para los que se basan en la plataforma de control Controllogix de Rockwell
Automation.

3.1.Normas y estándares aplicables

International Society of Automation – ISA
Norma ISA-5.1

3.2.Glosario de términos
• Controllogix – Proyecto: Cuando se habla de una aplicación Controllogix, el proyecto es el
archivo que contiene toda la información que se descarga al PLC: Tareas, Programas, Rutinas,
tags y lógica. (Nota: No se debe confundir Proyecto con Programa. En familias anteriores de
PLC, el archivo de configuración era conocido como “el programa”, sin embargo, en

Fecha de Impresión: mayo 31/2011

Página 1 de 183
 Controllogix la connotación “Programa” tiene un significado diferente – Ver más abajo la
definición de Programa en Controllogix).
• Controllogix – Tarea: Es el nivel más alto en la jerarquía de estructuración de la lógica en el PLC.
Pueden ser periódicas o continua (solo puede existir una Tarea contínua). Un procesador
Controllogix soporta hasta 32 Tareas. Las Tareas contienen a los Programas.
• Controllogix – Programa: Es el segundo nivel de jerarquía de estructuración de la lógica en el
PLC. Cada Programa tiene un espacio de memoria para tags (llamados Tags de Programa) y
pueden contener una o más rutinas.
• Controllogix – Rutina: Son los espacios en los cuales se escribe la lógica que debe ser ejecutada
por el PLC. Para el caso de esta guía pueden ser rutinas de Ladder o rutinas FBD.
• Alarma: La alarma notifica de situaciones anormales de operación de forma que el operador
pueda tomar acciones correctivas y prevenir consecuencias no deseadas. El sistema de control
debe estar diseñado para comunicar efectivamente alarmas individuales durante operación
normal, o la comunicación apropiada de muchas alarmas durante una falla mayor en la planta.
• Controlador: Puede referirse a un PLC, o a un lazo de control. Se refiere a un dispositivo (o
entidad lógica) que monitorea y afecta las condiciones de un sistema dinámico.
• Válvula de Control: Son válvulas usadas para el control de variables físicas como flujo, presión,
temperatura o nivel por medio de la apertura o cierre (parcial o total) en respuesta a señales
recibas desde controladores.
• Controlador en lazo abierto: Es un tipo de controlador que computa su salida hacia el proceso
usando únicamente su estado actual y el modelo del sistema que tiene programado (es decir,
no posee una entrada que le indique el estado actual del proceso, y por lo tanto, no puede
confirmar si el proceso ha alcanzado el estado deseado).
• Controlador en lazo cerrado: Es un tipo de controlador que posee realimentación desde el
proceso, de forma que computa su salida teniendo en cuenta tanto su estado y el modelo del
mismo, como el valor de realimentación leído. De esta forma el controlador puede ajustar su
salida para que la variable medida en el proceso alcance el valor deseado o punto de consigna).
• Variable de Proceso (PV): Es la variable del proceso que se quiere mantener bajo control. La
variable de proceso se ve afectada por las condiciones propias del proceso, pero puede ser
afectada por medio de la manipulación de un elemento de control (por ejemplo, una válvula).
• Punto de consigna (Setpoint o SP): Es el valor deseado de la PV, normalmente establecido por
el operador del proceso. El controlador en lazo cerrado toma este valor y lo resta del valor
actual de la PV, para determinar el nivel de la salida que debe usar para comandar la variable de
control.
• PLC: Abreviatura de Programmable Logic Controler (Controlador Lógico Programable). Es un
dispositivo basado en microprocesadores que es usado para el control de procesos industriales,
por medio de la manipulación de actuadores de acuerdo a una lógica programada en el
dispositivo, para responder a cambios monitoreados por medio de sensores. Está diseñado para
manejar una gran cantidad de señales de entrada y de salida, tanto digitales como análogas.
Muchos fabricantes de PLC han comenzando a usar el término PAC (Process Automation
Controller) para referirse a las unidades de más alto nivel en sus líneas de PLCs.
• Sensor: Es un dispositivo que responde a un estímulo físico (como calor, presión, luz, etc) y
genera una salida proporcional. La mayoría de las veces se encuentran trabajando en conjunto
con transmisores, aunque existen sensores que normalmente no tienen transmisor asociado
(como sensores de temperatura RTD o termocuplas).
• Transmisor: Es el dispositivo que convierte la señal entregada por el sensor (por ejemplo, la
depleción de un diafragma en un sensor de presión) y la convierte en una señal eléctrica de unas

Página 2 de 183
 determinadas características, para comunicarla hacia un sistema de control. Normalmente el
término transmisor se usa para designar al conjunto compuesto por el transmisor y la
electrónica de comunicaciones.
• Interruptor (Switch): Dispositivo discreto que indica la presencia (o ausencia) de una variable
física en un estado (o valor) determinado. Por ejemplo, un switch de nivel puede indicar una
condición de alto o bajo nivel, un switch de presión puede indicar una condición de presión por
fuera de su rango normal, etc.
• BPCS: Basic Process Control System, es el sistema responsable por la operación normal de la
planta y por lo tanto se constituye en la primera capa de protección contra situaciones
inseguras. Normalmente si el BPCS falla en mantener el control, se generan alarmas que le
notifican al operador que debe intervenir para restablecer el control dentro de los límites
establecidos. Si el operador no puede normalizar el proceso, existen otras capas de protección
como válvulas de seguridad, diseño del proceso para ser seguro y Sistemas Instrumentados de
Seguridad (SIS) para colocar el proceso en un estado seguro y mitigar los riesgos.
• SIL: Safety Integrity Level, se define como la reducción relativa de riesgos ofrecida por una
función de seguridad, o como el nivel deseado de reducción de riesgo en un sistema. SIL es una
medida del desempeño requerido para una Función Instrumentada de Seguridad (SIF por sus
siglas en inglés – Safety Instrumented Function). Es una calificación que va desde el número 1
(el menor nivel de confiabilidad) hasta 4 (el mayor nivel).
• SIS: Safety Instrumented System, es una forma de control de proceso cuya función es lograr o
mantener un estado estable del proceso cuando se detectan condiciones inaceptables o
peligrosas en el mismo. Los Sistemas Instrumentados de Seguridad se encuentran separados y
son independientes de los sistemas de control de procesos (BPCS), pero están conformados de
manera similar, incluyendo sensores, lógica de control, actuadores y sistemas de soporte.
• SIF: Safety Instrumented Functions, son las funciones específicas implementadas en un SIS, y
son implementadas como parte de una estrategia general de reducción de riesgos, la cual tiene
como objetivo reducir la probabilidad de ocurrencia de riesgos identificados que pueden
desembocar a un accidente catastrófico.
• HMI: Human Machine Interface – Corresponde a la interfaz gráfica que permite la iteración
entre el operador y el proceso (por intermedio del sistema de control).
• Tag: Etiqueta o nombre por el cual se define a un dispositivo de campo. A nivel de
programación del PLC Controllogix, un tag también es el nombre que se usa para referirse a un
área de memoria del controlador (bit, registro o arreglo de registros) usado en el programa del
PLC.

4. GUIA DE ASIGNACION DE NOMBRES

En esta sección se encuentra la definición de nombres para los dispositivos de campo. Esta asignación
debe seguirse tanto en la documentación de proceso (Diseño estrategia de control, Lógicas narrativas
de control, diagramas P&ID, diagramas de lazo), instalaciones eléctricas (identificación de cables en
tableros, planos de construcción) y ser usada para la identificación de estos elementos en los programas
de control correspondientes (programas de PLC, HMI, bases de datos). Esta guía se basa en el estándar
ISA-5.1.

4.1. CONSIDERACIONES GENERALES

Cada instrumento o función que deba ser identificada debe estar designada por un código
alfanumérico (o tag name) de la forma como se muestra en la Tabla 1. Esta tabla muestra que la

Fecha de Impresión: mayo 31/2011

Página 3 de 183
identificación está conformada por dos partes, la primera (TIC) corresponde al tipo de función o
instrumento, mientras que la segunda parte (103) es el código asignado; éste puede ser el código de
área o del sistema al cual pertenece.

Tabla 1 Identificación de tags – ISA-5.1

Identificación típica de tags
TIC 103 Identificación del Instrumento – tag name
T 103 Identificación de lazo
103 Número de lazo
TIC Identificación Funcional (Controlador Indicador de
Temp)
T Primera Letra
IC Letras sucesivas

4.2. GUIAS GENERALES DE IDENTIFICACION FUNCIONAL

• La identificación funcional de un instrumento (o su equivalente funcional) consiste en un
conjunto de letras indicadas en la Tabla 2, e incluye una primera letra (designando la
variable medida) y una o más letras subsecuentes (identificando las funciones realizadas).
• La identificación funcional (como su nombre lo indica) se realiza de acuerdo a la función
realizada por el instrumento, y no por su construcción física. Por ejemplo, un transmisor de
presión diferencial usado para medir flujo se debe identificar como FT (no como PT, o PDT).
• Los instrumentos de control final se nombran de acuerdo a la variable o medición inicial y
no de acuerdo a la variable manipulada. Por ejemplo, una válvula de control que varía el
flujo de acuerdo a los niveles a controlar se nombra LV y no FV.
• Las letras sucesivas de la identificación funcional designa una o más funciones pasivas y/o
funciones de salida. Es permitido usar letras modificadoras cuando sea requerido. Por
ejemplo, un dispositivo nombrado TDAL contiene dos modificadores: La letra D modifica la
variable T (temperatura) en una nueva variable (temperatura diferencial). La letra L
funciona como una restricción para la función A (alarma), significando Alarma por valor
bajo.

Página 4 de 183
Tabla 2 Letras para identificación de dispositivos

Fecha de Impresión: mayo 31/2011

Página 5 de 183
Tabla 3 Combinación típica de letras

Página 6 de 183
4.3. CONVENCION DE ASIGNACION DE NOMBRES
Para la asignación de nombres de dispositivos (transmisores, switches, elementos finales de
control, etc), se debe seguir la siguiente estructura para la asignación del nombre del tag:

TypeDeviceID

Type corresponde al tipo de dispositivo, de acuerdo a la información presentada en las

Tablas 2 y 3.
DeviceID es el número de identificación de dispositivo, en el cual se encuentra incluido el
código de área asignado por Proyectos.

A continuación se presentan algunos ejemplos de asignación de nombres:

• FT8153C:
o FT: Transmisor de flujo.
o 8153C: Identificación del dispositivo (Flujo en la bomba de circulación).

• LY7701A:
o LY: Válvula controladora de Nivel.
o 7701A: Identificación del dispositivo.

• PT8905:
o PT: Transmisor de Presión.
o 8905: Identificación del dispositivo.

4.4. Uniformidad en la asignación de nombres – P&IDs, bases de

datos de Controladores, bases de datos HMI
Los nombres de los elementos de campo (generalmente asignados durante la elaboración
de los P&IDs) deben guardar correspondencia entre los diferentes componentes del
sistema de control.
 Figura 1 Ejemplo de P&ID

Se debe mantener correspondencia entre los nombres usados en los P&IDs, con los
nombres usados en la programación de los PLCs y los tags creados en el sistema HMI.

P&ID PLC HMI

LT10606 LT10606 LT10606
LAHH10606 LT10606.HHAlarm LT10606\HHAlarm
LALL10606 LT10606.LLAlarm LT10606\HHAlarm
LIC10610 LIC10610 LIC10610
LIC10610.SP LIC10610\SP
LIC10610.OperManualReq LIC10610\OperManualReq
OperManualReq

En la tabla anterior, existen elementos en el P&

P&ID
ID que son señales derivadas de un
transmisor (por ejemplo, LAHH10606) que en la programación del PLC existen como
componentes del transmisor ((LT10606.HHAlarm).
LT10606.HHAlarm). Lo importante en este punto es que
exista correspondencia entre los nombres usados en los P&IDs con los nombres usados
en el sistema de Control (tanto HMI como PLC).

5. GUIA DE PROGRAMACION DE PLC

La plataforma de control a nivel de PLC usada en las facilidades es Controllogix de Allen Bradley. En
esta sección se presentan los lineamientos que deben se serr seguidos para la implementación de la
lógica del PLC, incluyendo los típicos de programación usados para los diversos dispositivos de la
planta.

Página 8 de 183
5.1. CRITERIOS GENERALES DE MANEJO DE SALIDAS DE
CONTROL
En los Controladores Lógicos Programables, es posible definir un estado seguro para los
puntos de las tarjetas de salida (el estado que cada punto va a asumir en caso de falla del
controlador, cuando el controlador se pase a modo Program o ante pérdida de
comunicaciones, en el caso de los chasis remotos).

Para el caso de los sistemas que se describen en este documento, la siguiente configuración
debe ser usada:
• Salidas digitales: Las salidas digitales se deben configurar para que se des- des
energicen (asuman un valor de ‘0’) cuando el controlador se vaya a falla,
fall cambie a
modo Program o haya pérdida de comunicaciones. En los sistemas Controllogix
esto se configura en la ventana de propiedades de la tarjeta:

Estado en modo
Program

Estado durante
Falla del PLC

Estado ante pérdida de

comunicaciones

Figura 2 Ventana de configuración tarjeta digital

Esta configuración tiene sentido si en la programación se hace uso de instrucciones

OTE (el equivalente a una bobina en lógica de contactos – OutpuT Energize)
Energize para
afectar estas salidas.
lidas. Se debe evitar hacer uso de instrucciones OTL (instrucciones
para enganchar una salida – OutpuT Latch) debido a que son instrucciones con
memoria, lo que significa que en caso de un evento las salidas se van a ir a cero
(gracias a la configuración de la tarjeta), pero una vez que se normalice el PLC (que
se limpie la falla y se retorne a modo RUN) esas sal
salidas
idas pueden volverse a energizar,
provocando una condición insegura en la planta.
• Salidas análogas: Las salidas análogas se deben configurar para mantener el último
estado en caso de falla, salvo en casos específicos en los cuales sea requerido que
asuman un valor distinto. Esto es posible configurarlo en la ventana de propiedades
de las tarjetas de salida análoga de Controllogix.
5.2. CREACION DE TAGS – ALCANCE LOCAL (O ALCANCE DE
PROGRAMA) vs ALCANCE DE CONTROLADOR
Los tags que usa el sistema Controllogix pueden existir en dos alcances (scopes) diferentes:
• Tags de Controlador (Controller Scope): Son los tags que son visibles a todas las
rutinas del Controlador. Se acceden de manera directa desde fuentes externas de
datos (como el HMI).
• Tags de Programa (Program Scope): Son los tags que son visibles únicamente a las
rutinas que pertenecen al programa en donde están definidos. Se acceden por
medio del nombre del programa que los contiene desde fuentes externas (como el
HMI), usando la sintaxis Program:NombrePrograma.NombreTag.

Los tags de Programa sirven para implementar encapsulamiento de datos y facilita la

reutilización de código en un mismo archivo de PLC (para el caso de aplicaciones en las que
un mismo PLC controla diversas máquinas del mismo tipo – cada máquina configurada en
un programa diferente, debido a que sus tags son visibles únicamente a las rutinas
pertenecientes a ese programa. Por lo tanto, se puede duplicar un programa entero sin
riesgo que existan conflictos entre programas (cada programa usa sus tags locales). Esto
reduce enormemente la labor de programación y el tiempo de búsqueda en caso de un
problema, pues la resolución o búsqueda se reduciría al programa y no a toda la tarea.

Sin embargo, en las aplicaciones de Facilidades se controlan procesos, cuya programación

no se beneficia al hacer uso de tags de programa.

Por lo tanto se definen las siguientes reglas:

• Todo tag que esté relacionado con un elemento de campo (transmisor, válvula,
motor, etc), debe ser creado a nivel de Controlador (Controller Scoped).
• Todo tag que deba ser monitoreado por el operador (a través del HMI) debe ser
declarado a nivel de Controlador. Esto incluye:
o Tags de indicaciones de condiciones especiales.
o Alarmas.
o Puntos de consigna del operador (setpoints)

• En los tags de Programa se pueden dejar aquellos tags que tienen una función
intermedia (es decir, que son necesarios para que la lógica funcione, pero que no se
necesita que el operador los vea en una pantalla, por ejemplo). Algunos de estos
tags son:
o Tags usados en instrucciones ONS (bit de almacenamiento).
o Tags de configuración de instrucciones misceláneas (como los que crean las
instrucciones FBD).
En este último caso (los tags creados automáticamente por las instrucciones FBD),
se debe diferenciar claramente cuales tags se pueden dejar como tags de
Programa, y cuales se deben crear como tags de Controlador. Por ejemplo, los tags
usados por instrucciones de suma o comparaciones lógicas generalmente deben
quedar como tags de Programa (pues son cálculos intermedios cuyo resultado no

Página 10 de 183
 son de interés directo del operador)
operador).. Los tags usados por instrucciones como PIDE o
por totalizadores son creados por RSLogix5000 como tags de Programa, y en este
caso deben ser cambiados a tags de Controlador (pues el funcionamiento
funcionamie del PID o
los valores del totalizador son de interés del operador). Esta situación se ejemplifica
en la Figura 4.

Controller tags

Program tags
Figura 3 Ejemplo de tags de Controlador y de Programa en Ladder

Controller tags
Program tags
Program tags

Figura 4 Ejemplo de tags de Controlador y de Programa en FBD

Como se verá más adelante, la mayor parte de la lógica desarrollada en este documento
hace uso de tipos de datos de usuario (UDT – User Defined Type), la mayoría de ellos
definidos en instrucciones ADD
ADD-ON.
ON. Esto ofrece una estructura mucho más organizada de
la base de datos de tags en eell PLC, debido a que agrupa en un solo nombre a todos los
componentes relacionados con una función específica.

Por ejemplo, la lógica de un motor que no hace uso de UDT/ADD

UDT/ADD-ON,
ON, podría tener el
siguiente conjunto de tags:

Nombre Tipo Descripción

M00_HSR_7706B BOOL Selector de arranque del motor
M00_HSS_7706B BOOL Selector de parada del motor
M00_PRM_HE7706B BOOL Permisivo para arranque
 M00_XSR_7706B BOOL Salida para arrancar el motor
M00_XSS_7706B BOOL Salida para parar el motor

El mismo motor, haciendo uso de un UDT haría uso de un único tag: M7706B, el cual tendría
dentro de si los tags requeridos:

Figura 5 Agrupamiento de datos en un UDT

5.3.TAREA PRINCIPAL
La tarea principal debe ser creada de tipo periódica (no se hace uso de tarea Continua),
usando una prioridad de 15 (la menor prioridad posible, para permitir que otras tareas
puedan interrumpirla). El periodo de ejecución debe ser configurado de acuerdo a las
necesidades específicas de la aplicación, pero se propone un periodo de 100 ms como
tiempo típico para este parámetro. Se debe tener cuidado con el ciclo de scan de la tarea,
pues no puede superar este tiempo. El número de tareas creadas en la aplicación debe ser
mantenida al mínimo posible, idealmente la única tarea debe ser la tarea principal definida
anteriormente.

Página 12 de 183
 Figura 6 Configuración Tarea Principal

5.4. CONFIGURACION DE PROGRAMAS

El siguiente nivel de jerarquía en la estructura del proyecto de Controllogix es el Programa.
Para los programas de Control de la Facilidad se debe hacer uso de dos programas:
• MainProgram: Es el programa principal creado por defecto por RSLogix5000, en el
cual se crearán las rutinas de Control de los dispositivos de planta.
• Diagnostics: Es el programa que contiene las rutinas del sistema de diagnóstico de
fallas del sistema de Control.

Solamente se debe hacer uso de estos dos programas, debido a que incluir más de ellos
incrementa el ciclo de scan del PLC. En la Figura 6 se muestra la Tarea Principal, y debajo de
ella, los dos programas mencionados.

5.5. PROGRAMA PRINCIPAL (MainProgram)

A continuación se detallan las rutinas típicas que deben conformar este programa.
 Tarea Principal
(Tipo Periódica)

Programa Principal

Rutina de entradas analógicas Rutina Principal

(Instrucciones AOI_AIN) (Saltos hacia otras rutinas)

Rutinas de control específicas Rutina de enclavamientos

Rutina de motores
(Instrucciones AOI_FVNR)
Rutina de entradas discretas
(switch – instr AOI_Switch) Rutina de lazos de control

Rutina de Totalizadores Rutina de válvulas

(Instrucciones AOI_Valve)

Rutina de funciones misceláneas Programa de Diagnósticos

(fecha/hora, etc).

Figura 7 Estructura del Proyecto

5.6. LOGICA DE ENTRADAS ANALOGICAS (Rutina X_AreaZ_AI -

Instrucción AOI_AIN)
La instrucción AOI_AIN se usa para asociar la señal leída por un canal de entrada analógica con
un tag de transmisor, y ofrece las siguientes características:
• La escalización del canal se configura directamente en la tarjeta, y la instrucción lee
estos valores para calcular los niveles de OverRange y UnderRange.
• La instrucción lee el valor de canal en falla directamente de la tarjeta. Esta señal, en
conjunto con la verificación de OverRange y UnderRange se usa para generar el bit de
falla de canal.
• La instrucción puede, opcionalmente, extraer la raíz cuadrada del valor leído y
escalizarlo (para el manejo de placas de orificio, por ejemplo, para convertir una señal
de presión diferencial en flujo).
• Se ofrecen cuatro niveles de alarma (HH, H, L y LL), cada alarma puede ser habilitada
individualmente. Los valores de niveles de alarma se encuentran como parámetros de
la instrucción.
• El uso de una instrucción ADD-ON permite encapsular todos los tags de la instrucción
en una sola estructura. Esto ofrece una base de datos de tags más organizada y
estandarizada.

Configuración del canal de la tarjeta

Los valores de escalización de las entradas analógicas se ingresan directamente en el cuadro de
configuración de la tarjeta, en la pestaña Configuration:

Página 14 de 183
 Figura 8 Cuadro de Configuración Tarjeta Analógica

En este cuadro los valores que debe configurar son:

• Input Range: Se debe seleccionar el tipo de entrada usada (normalmente se usa entrada
en corriente, de 0 a 20 ma).
• Sensor Offset: Se usa para ingresar un offset (en unidades de ingeniería) en el valor
escalizado calculado por la tarjeta. Normalmente debe ser cero.
• Notch Filter: Es un filtro utilizado para atenuar la frecuencia seleccionada y sus
armónicos en la entrada, y se usa para filtrar el ruido de la línea. Use un valor de 60Hz
(valor de frecuencia usada en los sistemas AC).
• Digital Filter: Es un filtro digital que se usa para “suavizar” señales que presentan
mucho ruido. Ver el numeral 7.1. Valor por defecto es 0.
• RTS: Real Time Sample, es decir, la frecuencia a la cual se escanea el canal análogo.
Valor por defecto es 100 ms.
• Scaling: Es aquí en donde se ingresan los valores de escalización de la señal:
o High/Low Signal: Ingrese los valores máximos y mínimos en unidades de la
variable de entrada (en la figura se muestra una señal de 44-20
20 ma).
o High/Low Engineering: Ingrese los valores máximos y m mínimos
ínimos en unidades de
ingeniería (en la figura se muestra una escalizac
escalización de 0 a 100).

Configuración de la instrucción
La lógica de los transmisores debe ser creada en la rutina AI que corresponde al área en la que
se encuentra el procesador. La instrucción se inserta como un solo bloque, como se muestra en
la siguiente figura.
 Figura 9 Instrucción Analog Input

En la figura se muestra una instrucción AOI_Ain creada para el transmisor FT8153C, la cual
encapsula toda la lógica y tags necesarios para procesar la entrada analógica.

La instrucción posee los siguientes parámetros:

Parámetro Tipo Comentarios
Entradas
Nombre de la entrada analógica. Con este nombre se crea un
AOI_AIN Estructura
UDT que contiene los miembros usados por la entrada.
Es la dirección de I/O correspondiente al canal de la entrada
InputAdd Real
analógica.
Es la dirección de I/O correspondiente a la falla de la entrada
FaultAdd Bool
analógica.
Es la dirección de I/O correspondiente al valor máximo de
EuMax Real
ingeniería configurado en la escalización del canal.
Es la dirección de I/O correspondiente al valor mínimo de
EuMin Real
ingeniería configurado en la escalización del canal.
Salidas
Value Real Es el valor escalizado de la entrada analógica.
HHAlarm Son las indicaciones de alarma por Alto-Alto (HH), Alto (H),
HAlarm Bajo (L) y Bajo-Bajo (LL). En condiciones normales (sin
Bool
LAlarm alarma) tienen un valor de cero, y se colocan en ‘1’ para
LLAlarm indicar una alarma.
Indicación que el canal se encuentra en falla. En condiciones
Faulted Bool
normales es cero, un valor de ‘1’ indica una falla de canal.
Salida de disparo de la instrucción, normalmente tiene un
TripHH Bool valor de ‘1’. Si la alarma por HH está habilitada y está activa,
y si no está habilitado el bypass (BypassEn) entonces esta

Página 16 de 183
 Parámetro Tipo Comentarios
salida asume el valor ‘0’ (disparo).
Salida de disparo de la instrucción, normalmente tiene un
valor de ‘1’. Si la alarma por LL está habilitada y está activa, y
TripLL Bool
si no está habilitado el bypass (BypassEn) entonces esta
salida asume el valor ‘0’ (disparo).
Define el tipo de Disparo que se produce ante Falla del Canal:
FaultTripType Bool 0 = Genera Trip LL
1 = Genera Trip HH

Por ejemplo, para referenciar el valor escalizado del transmisor en la Figura 9, se utilizaría el tag
FT8153C.Value. El tag FT8153C.Faulted indica el estado de falla del canal.

Existen otros parámetros que no se muestran en la instrucción, pero que se usan para
configurar algunas características de la misma:
Parámetro Tipo Comentarios
HHAlmEn Son los tags usados para habilitar/deshabilitar las alarmas. Un
HAlmEn valor de ‘1’ sirve para habilitar la alarma respectiva.
Bool
LAlmEn
LLAlmEn
HHAlmLimit Son los límites para generar las alarmas por HH, H, L y LL.
HAlmLimit
Real
LAlmLimit
LLAlmLimit
AlmDeadband En la banda muerta para el manejo de alarmas, ver ejemplo
Real
en la Figura 10.
BypassEn Habilitar Bypass:
Bool 0 = Deshabilitado
1 = Habilitado
 Figura 10 Ejemplo de disparo/normalización de alarmas

Estos parámetros son accesibles a través de la estructura de la instrucción, y pueden ser

referenciados en el HMI o en el ladder. Esto permite que el programa pueda interactuar con la
instrucción, como por ejemplo, habilitar alarmas bajo circunstancias esp
específicas
ecíficas (por ejemplo,
habilitar las alarmas por bajo y bajo
bajo-bajo
bajo flujo solo si la bomba está encendida, como se
muestra en la Figura 9).

El detalle de la implementación
ión de la instrucción se encuentra en la sección 7.2.

5.7.LOGICA DE MOTORES CONVENCIONALES NO REVERSIBLES (Rutina

X_AreaZ_Motor - Instrucción AOI_FVNR)
Para el control de motores convencionales no reversibles (Full Voltage Non Reversing) se tiene
la instrucción AOI_FVNR, y presenta las siguientes características:
• Esta instrucción permite el arranque/parada del motor por medio de selectores en
campo, y permite
mite que el operador pueda parar el motor desde el HMI (el arranque
desde HMI no está permitido).
• La instrucción posee dos salidas para controlar el motor (contacto XSR – contacto de
arranque, y contacto XSS – contacto de parada). La instrucción arranca el motor
cerrando ambos contactos (energizando las salidas).
• Se reciben dos señales de campo (HSR – Selector de arranque del motor, y HSS –
Selector de parada del motor).
• Se recibe una entrada de falla general del motor (entrada “Fail” de la instrucción) la cual
en condiciones normales debe estar des
des-energizada.
energizada. Cuando se recibe la falla (Fail = 1)
la instrucción ordena la parada del motor.

Página 18 de 183
 • La instrucción genera dos indicaciones de falla durante el arranque: FailToStart y
FailToStop. Estas fallas se generan cuando:
o FailToStart: La instrucción comanda el motor a arrancar, y la entrada del
contacto auxiliar no se energiza por 15 segundos.
o FailToStop: La instrucción comanda el motor a parar, y la entrada del contacto
auxiliar se mantiene energizada por 15 segundos.
En ambos casos el tiempo de espera (15 segundos) es configurable.

La instrucción se inserta como un solo bloque, como se muestra en la siguiente figura.

Figura 11 Instrucción para motores no reversibles

En la figura se muestra una instrucción AOI_FVNR creada para el motor P77015.

Parámetros de la instrucción:
Parámetro Tipo Comentarios
Entradas
Es el nombre del motor. Con este nombre se crea un UDT que
AOI_FVNR Estructura
contiene todos los miembros usados por la instrucción.
Es la dirección de I/O correspondiente a la entrada del selector
HSR Bool de arranque del motor. Normalmente debe estar en ‘0’, un
valor de ‘1’ es un requerimiento de arrancar el motor.
Es la dirección de I/O correspondiente a la entrada del selector
de parada del motor. Normalmente debe estar en ‘1’ para
HSS Bool
permitir que el motor arranque. Un valor de ‘0’ ordena parar el
motor.
Es la dirección de I/O correspondiente a la entrada de falla
Fail Bool general del motor. Señal que se genera en campo que indica
que existe una falla en el motor cuando asume el valor ‘1’.
 Es la dirección de I/O correspondiente a la entrada del
Aux Bool contacto auxiliar del arrancador. Un valor de ‘0’ significa que
el arrancador está abierto (motor parado).
Es el tag del PLC que usa el HMI para borrar las indicaciones
HMI_Reset Bool de falla del área. En el caso del motor, las fallas que limpia son
FailToStart y FailToStop.
Salidas
Contacto de arranque del motor, cuando asume el valor ‘1’
XSR Bool
energiza el motor (cuando XSS = 1).
Contacto de parada del motor. Normalmente debe estar en ‘1’
XSS Bool
para permitir el arranque, cuando es ‘0’ des-energiza el motor.
Indicación de falla por confirmación durante el arranque.
Asume el valor ‘1’ cuando se arranca el motor, y pasan
FailToStart Bool
“StartTMR.PRE” milisegundos sin que se energice la entrada
Aux.
Indicación de falla por confirmación durante la parada. Asume
FailToStop Bool el valor ‘1’ cuando se para el motor, y pasan “StopTMR.PRE”
milisegundos sin que se des-energice la entrada Aux.

Existe un parámetro que no se muestra en la instrucción, pero que puede ser usado desde la
lógica o el HMI:
Parámetro Tipo Comentarios
HMI_Stop Bool Comando de parada del motor desde el HMI

Adicionalmente la instrucción tiene un par de Local Tags con los temporizadores para generar
las fallas FailToStart y FailToStop. Se crean como Local Tags para evitar que fuentes externas
modifiquen estos valores (es decir, es necesario abrir el programa con RSLogix5000 para
modificarlos).
Local Tag Tipo Comentarios
Temporizado para generar la falla FailToStart. El tiempo por
StartTMR TIMER
defecto es de 15 segundos (StartTMR.PRE = 15000).
Temporizado para generar la falla FailToStop. El tiempo por
StartTMR TIMER
defecto es de 15 segundos (StopTMR.PRE = 15000).

El detalle de la implementación de la instrucción se encuentra en la sección 7.3.

5.8. LOGICA DE VALVULAS DISCRETAS (Rutina X_AreaZ_Valve -

Instrucción AOI_Valve)
La instrucción AOI_Valve se utiliza para el control de las válvulas discretas (On/Off), y posee las
siguientes características:

Página 20 de 183
• Presenta una separación entre el estado lógico de la válvula (abierto/cerrado) y el
estado eléctrico de la salida. De esta manera no importa si la válvula es N.C. o N.O., la
variable de estado lógico siempre tiene el mismo significado (1 = Abierta).
• Tiene entradas para recibir el estado de un Limit Switch de apertura, y otro de cierre.
Sin embargo, la instrucción también puede ser usada para válvulas que no poseen uno
(o ambos) Limit Switch(s).
• Genera alarmas por Falla durante la apertura (FTO) y Falla durante el cierre (FTC),
cuando no se recibe la señal del Limit Switch correspondient
correspondientee en un lapso programable
de tiempo.
• Hace uso de comandos pasivos (es decir, existe un comando para abrir y otro para
cerrar), lo cual permite que la válvula conserve su estado actual durante las transiciones
de modo de operación. La instrucción se encarga de limpiar los comandos una vez son
recibidos (de esta manera el HMI o el programa del PLC solo se deben preocupar por
colocar el comando deseado en ‘1’).
• Posee los siguientes estados de operación:
o Control por programa: El estado de la válvula es controla
controlado
do por la lógica del
PLC, usando un comando de apertura y otro de cierre (ProgOpen, ProgClose).
Los comandos enviado por el HMI son descartados.
o Control por Operador (HMI): El estado de la válvula es controlado por un
comando de apertura y otro de cierre q que
ue vienen del HMI (HMIOpen,
HMIClose).
• Posee una entrada de Interlock, y tiene un parámetro para definir la acción que el
Interlock debe ejecutar (abrir o cerrar). Cuando el Interlock se vuelve activo, la válvula
asume el valor definido en el parámetro, si sin
n importar el estado de operación de la
válvula.
• Posee un estado de Bypass, para que la válvula opere según los comandos recibidos por
el HMI. En este modo no tienen efecto los Interlocks ni los comandos desde el
programa.

Figura 12 Instrucción para válvulas (ejemplo de válvula con confirmaciones)

En la Figura 12 se muestra la instrucción AOI_Valve controlando la válvula M04_FY8301D. En el
renglón siguiente se muestra que existe un enclavamiento (interlock) que actúa sobre la válvula
cuando se presenta una alarma por LL en el transmisor M02_FT8153C.

Se recomienda que los enclavamientos para las válvulas discretas se configuren a renglón
seguido de la instrucción AOI_Valve, como se muestra en la figura anterior. La rutina
X_AreaZ_Interlock se presenta principalmente para ingresar los enclavamientos relacionados a
lazos de control (ver instrucciones PID en 5.10).

Válvulas sin confirmación de apertura y/o cierre

Para el caso de las válvulas que no poseen Limit Switchs de apertura y/o cierre, la instrucción
posee dos parámetros (NoZSC y NoZSO) que pueden ser usados en las entradas ZSC y ZSO.
Esta característica se implementó para permitir que la misma instrucción pueda manejar
válvulas con o sin confirmaciones.

Figura 13 Uso de la instrucción con válvula sin confirmaciones

Parámetros de la instrucción:
Parámetro Tipo Comentarios
Entradas
Es el nombre de la válvula discreta. Con este nombre se crea
AOI_Valve Estructura un UDT que contiene todos los miembros usados por la
instrucción.
Dirección del Limit Switch de cierre. Si no existe este Limit
ZSC Bool
Switch, usar el elemento NoZSC de la estructura.
Dirección del Limit Switch de apertura. Si no existe este Limit
ZSO Bool
Switch, usar el elemento NoZSO de la estructura.
Es el tag del PLC que usa el HMI para borrar las indicaciones
HMI_Reset Bool de falla del área. En el caso del motor, las fallas que limpia son
FailToStart y FailToStop.
Salidas
OUT Bool Dirección de la salida que controla la válvula.
SV Bool Es la representación del estado lógico de la válvula. 1 = Válvula

Página 22 de 183
 Parámetro Tipo Comentarios
abierta, ‘0’ = Válvula cerrada.
Fail-to-Open, es la salida que indica que la válvula fue abierta,
FTO Bool
pero no se recibió confirmación del Switch de apertura.
Fail-to-Close, es la salida que indica que la válvula fue cerrada,
FTC Bool
pero no se recibió confirmación del Switch de cierre.

Existen otros parámetros que no se muestran en la instrucción, pero que se usan para
configurar algunas características de la misma:
Parámetro Tipo Comentarios
Es el comando para activar el estado de Interlock de la válvula.
Cuando esta entrada es ‘1’, la válvula asume el estado definido
Intlck_Req Bool
en “Intlck_State”. Los comandos de apertura y cierre por
Programa y por HMI son descartados en este estado.
Es el estado que debe asumir la válvula cuando entra en
Intlck_State Bool Interlock: ‘0’ = el interlock cierra la válvula; ‘1’ = el interlock
abre la válvula.
Es el modo de operación de la válvula:
Mode Bool ‘0’ = El programa tiene el control de la válvula
‘1’ = El operador (HMI) tiene el control de la válvula
Habilita el modo Bypass cuando es ‘1’. En el modo Bypass los
BypassEn Bool Interlocks no tienen efecto, y el control de la válvula se realiza
exclusivamente por el HMI.
HMIOpen Bool Es el comando desde el HMI para abrir la válvula.
HMIClose Bool Es el comando desde el HMI para cerrar la válvula.
ProgOpen Bool Es el comando desde el programa del PLC para abrir la válvula.
Es el comando desde el programa del PLC para cerrar la
ProgClose Bool
válvula.
Es una salida de la instrucción que se usa para simular el Limit
Switch de cierre en aquellas válvulas que no tienen dicho
NoZSC Bool
switch. En esos casos, la entrada ZSC se alimenta con esta
salida (ver Figura 13).
Es una salida de la instrucción que se usa para simular el Limit
Switch de apertura en aquellas válvulas que no tienen dicho
NoZSO Bool
switch. En esos casos, la entrada ZSC se alimenta con esta
salida (ver Figura 13).

Adicionalmente la instrucción tiene un par de Local Tags con los temporizadores para generar
las fallas FTO y FTC, y la variable para definir el tipo de válvula (N.C. o N.O.) Se crean como
Local Tags para evitar que fuentes externas modifiquen estos valores (es decir, es necesario
abrir el programa con RSLogix5000 para modificarlos).

Local Tag Tipo Comentarios

FTC_TMR TIMER Temporizado para generar la falla FailToStart. El tiempo por
 Local Tag Tipo Comentarios
defecto es de 10 segundos (FTC_TMR.PRE = 10000).
Temporizado para generar la falla FailToStop. El tiempo por
FTO_TMR TIMER
defecto es de 10 segundos (FTC_TMR.PRE = 10000).
Definición del tipo de válvula:
Type Bool ‘0’ = Válvula Normalmente Cerrada (Energiza para abrir)
‘1’ = Válvula Normalmente Abierta (Energiza para cerrar)

El detalle de la implementación de la instrucción se encuentra en la sección 7.4.

5.9. LOGICA DE ENTRADAS DISCRETAS (Rutina X_AreaZ_Switch -

Instrucción AOI_Switch
AOI_Switch)
La instrucción AOI_Switch se utiliza para leer el estado de una entrada discreta (switch), y
posee las siguientes
es características:
• Los switchs son normalmente cerrados, lo que significa que en condiciones normales el
switch se encuentra en cerrados (Input = ‘1’).
• Posee una salida que representa el estado del switch (es una copia del valor de la
entrada). Esto se usaa para separar la dirección de I/O que correspode al switch con su
significado lógico (de esta forma, es posible cambiar la entrada usada por el switch solo
en la instrucción, y no tener que buscar por todo el programa haciendo reemplazos).
• Posee una salidaa de disparo (Trip) y una entrada para hacer bypass del trip (BypassEn).
De esta manera se pueden inhabilitar los disparos del switch colocando BypassEn en ‘1’.

Figura 14 Instrucción para Switchs

Parámetros de la instrucción:
Parámetro Tipo Comentarios
Entradas
Es el nombre del Switch.. Con este nombre se crea un UDT que
AOI_Switch Estructura
contiene todos los miembros usados por la instrucción.
Es la dirección de I/O correspondiente a la entrada del Switch.
Switch
Input Bool
En condiciones normales debe estar en ‘1’.

Página 24 de 183
 Este parámetro no se muestra en la instrucción, pero se usa
BypassEn Bool para habilitar/deshabilitar el disparo del switch. Ver abajo la
salida Trip.
Salidas
ZS Bool Estado del switch. Es una copia del valor en Input.
Es el disparo del switch:
Si BypassEn = ‘1’, entonces Trip = ‘1’ sin importar el estado de
Trip Bool
la entrada (Input).
Si BypassEn = ‘0’, entonces Trip = Input.

5.10. LOGICA DE CONTROLADORES (Rutina X_AreaZ_PID -

Instrucción PID)
Para la lógica de los lazos de control se usa la instrucción PIDE suministrada por
RSLogix5000. La selección de esta instrucción se fundamenta en las mejoras que Rockwell
ha realizado en esta instrucción respecto a la instrucción PID convencional, principalmente
en la forma como está implementado el algoritmo.

La instrucción PID convencional usa la forma posicional del algoritmo PID, mientras que la
instrucción PIDE utiliza la forma de velocidad del algoritmo. Este cambio tiene ventajas
sobre todo en el comportamiento de la salida del lazo cuando se realiza un cambio en las
ganancias del lazo:
• En la instrucción PID convencional, realizar un cambio en las ganancias mientras el
lazo está operando produce un sobresalto en la salida del lazo.
• En la nueva instrucción PIDE es posible realizar cambios en las ganancias mientras
el lazo está operando sin que se produzcan sobresaltos en la salida.

Esta característica hace que la instrucción PIDE sea especialmente útil para controladores
con ganancias adaptivas, controladores en rango dividido, controladores en paralelo y lazos
en cascada.

En esta sección se explica la forma como esta instrucción debe ser usada.

5.10.1 ORGANIZACIÓN EN LA RUTINA FBD

Una rutina FBD (Function Block Diagram) puede estar conformada por una o más hojas de
código (lo que es equivalente a los renglones en una instrucción Ladder). Cada hoja puede
contener una o más instrucciones.

El tamaño por defecto de una hoja de código FBD es tipo carta (Letter – 8.5 x 11 in) el cual
es apropiado para configurar una o dos instrucciones por hoja.
5.10.2 GENERALIDADES
Estados de Operación
La instrucción puede trabajar en dos diferentes estados:
• Control por programa: Desde el programa del PLC es posible cambiar el modo
de operación del lazo, así como los valores de setpoint y de salida del lazo.
• Control por Operador: El operador puede cambiar el modo de operación del
lazo, así como los valores de setpoint y salida del lazo
Modos de Operación
Los siguientes modos de operación están definidos:
• Auto: En este modo el lazo regulará automáticamente su salida para mantener
el PV al valor de Setpoint deseado.
• Manual: El lazo mantiene su salida al valor ingresado por el operador (cuando
trabaja en Control por Operador) o en el valor determinado por la lógica del
PLC (cuando se trabaja Co
Control por programa).
• Override: Este modo se usa para colocar el lazo en un valor determinado
cuando se dispara un enclavamiento (Interlock).
• Cascada: En este modo el lazo trabaja de la misma manera que en modo Auto,
pero el setpoint viene de una fuente ext
externa.

5.10.3 LAZO CONVENCIONAL DE CONTROL

En esta sección se explicar la implementación de un lazo de control convencional
usando la instrucción PIDE.

Creación de la rutina
Para la implementación de la lógica se usa una rutina de tipo Function Block Diagram

Figura 15 Rutina Function Block Diagram

Página 26 de 183
 En la barra de instrucciones busque la pestaña correspondiente a “Process”, e inserte
una instrucción PIDE. Al hacerlo, se inserta una instrucción como la mostrada en la
Figura 15.

En la parte superior de la instrucción se encuentra el nombre del tag asociado a ella

(por defecto al insertar la instrucción crea el tag PIDE_xx de alcance Local, donde xx es
un número consecutivo). Cambie este tag por uno con el nombre del lazo (por ejemplo,
FIC8153C) y cree el tag en los Controller Tags.

Por defecto, la instrucción muestra algunos parámetros y oculta otros. Para el caso de
esta primera implementación se deben marcar como visibles solo ciertos parámetros,
para hacerlo abra la ventana de configuración del lazo y ubique la pestaña
“Parameters”, y utilice la caja de selección de la columna “Vis” para volver
visible/invisible cada parámetro.

Abrir Propiedades

Figura 16 Configuración de la instrucción PIDE

Los parámetros que se deben marcar como visibles son:

• PV • PVFault • PVEUMax
• PVEUMin • CVFault • CVEU
• SP • E • Auto
• Manual • ProgOper • Override

En la siguiente figura se muestra la instrucción instanciada con las direcciones que le

corresponden.
 Figura 17 Instrucción PIDE instanciada

La figura muestra la instrucción conectada con los parámetros de operación básicos, a

continuación se describen cada ununo de estos parámetros:
• PV: Process Variable, corresponde al valor escalizado en unidades de ingeniería
leído del transmisor. Corresponde al elemento .Value de la estructura AOI_AIN
usada por el transmisor.

En modo Auto, la instrucción manipula su salida (CVEU) para lograr que el PV

se acerque al punto de consigna (SP).

• PVFault: Es la indicación de falla en el PV. Corresponde al elemento .Faulted de

la estructura AOI_AIN usada por el transmisor.

Cuando existe una falla en el transmisor, no es deseable qu

que
e el algoritmo PID
continúe ejecutándose (porque estaría realizando el cálculo del CV con base en
un PV erróneo). Por lo tanto, cuando la instrucción detecta que la entrada
PVFault se encuentra en ‘1’ se coloca en modo Manual.

• CVFault: En la indicación de falla en el canal análogo de salida (la salida que

manipula el elemento de control final). Corresponde al elemento .ChxFault de
la estructura que RSLogix5000 crea para los canales de salida análogos (donde
x es el canal correspondiente).

Cuando existe un
unaa falla en la salida análoga, no es deseable que el algoritmo
PID continúe ejecutándose (porque los cambios que haga en el CV en realidad
no van a producir un cambio en el elemento de control, y por lo tanto no van a
haber cambios en el PV. Esto produce ununaa saturación del CV en el tiempo).

Por lo tanto, cuando la instrucción detecta que la entrada CVFault se encuentra

en ‘1’ se coloca en modo Manual.

Página 28 de 183
• PVEUMax, PVEUMin: Son los valores máximos y mínimos que puede asumir el
PV. Corresponde a los elementos .EUMax y .EUMin de la estructura AOI_AIN
usada por el transmisor.

• CVEU: Es la salida de control de la instrucción escalizada en las unidades de

ingeniería del elemento de control, normalmente de 0% a 100%. Las unidades
de ingeniería de la salida se configuran en los parámetros CVEUMax y
CVEUMin de la instrucción, los cuales también se encuentran en la pestaña
EUs/Limits en las propiedades de la instrucción.

Es importante resaltar en este punto que el elemento final de control (por

ejemplo, válvula de control) debe ser controlado con la salida CVEU del lazo
(y no con la salida CV). Esto se hace con el propósito de mantener separados
el significado lógico de la instrucción, y la implementación eléctrica:
o La salida CV del lazo corresponde al significado lógico del mismo, en
donde un CV = 0 significa que el elemento de control no está actuado (por
ejemplo, que la válvula se encuentra completamente cerrada) y un CV =
100 significa que el elemento de control está totalmente actuado (válvula
completamente abierta).
o El elemento final de control se manipula por medio de la salida CVEU, y se
usan los parámetros CVEUMax y CVEUMin para escalizar esta salida. Por
ejemplo, para el caso de una válvula de control electro-pneumática de tipo
aire-para-cerrar, se usa CVEUMax = 0, y CVEUMin = 100 (una salida al
100% hace que la válvula cierre).
o Debido a lo anterior, la configuración de las tarjetas análogas de salida se
debe realizar usando lógica positiva, es decir, para el caso de una señal de
0 a 100% que se controla con corriente de 4 a 20 mA, un valor de 0%
corresponde a una corriente de 4 mA, y un valor de 100% corresponde a 20
mA.

• SP: Es la salida que indica el valor actual de Setpoint del lazo.

• E: Es la salida que indica el valor actual del Error del lazo (diferencia entre PV y
SP).
• ProgOper: Es la salida que indica el estado actual de operación de la instrucción
(0 = Control por Operador; 1 = Control por Programa).
• Auto: Es la salida que indica que el lazo se encuentra en modo Auto.
• Manual: Es la salida que indica que el lazo se encuentra en modo Manual.
• Override: Es la salida que indica que el lazo se encuentra en modo Override
(modo usado para manejar los enclavamientos del lazo).
Configuración de la instrucción

Figura 18 Propiedades instrucción PIDE - General

A continuación se detallan los parámetros de configuración:

• Mode: Utilice la configuración por defecto (Periodic). Recuerde que la Tarea
Principal fue configurada como periódica, de forma que configurar este
parámetro con este valor es correcto. Las otras opciones que existen para este
parámetro son:
o Oversampling: Este modo ofrece control manual sobre la ejecución de
la instrucción. Para usar este modo, configure la rata de actualización
en el parámetro OversampleDT y ejecute la inst
instrucción
rucción habilitando el
parámetro EnableIn. Para un caso de ejemplo para el uso de este
modo, refiérase a la sección 7.5.
o Real Time Sampling: Este modo trabaja en conjunto con la tarjeta de
entradas análogas para ejecutar la instrucción cada vez que la tarjeta
provea una nueva muestra (la tarjeta provee muestras a la frecuencia
RTS configurada en ella). Para usar este modo, cablee el parámetro
RollingTimeStamp del m módulo
ódulo análogo hacia el parámetro
RTSTimeStamp de la instrucción, y también cablee el parámetro
RealTimeSample del módulo análogo hacia el parámetro RTSTime de
la instrucción.
• Control Action: Seleccione entre acción directa (E=SP
(E=SP-PV)
PV) o acción inversa
(E=PV-SP).
SP). Para determinar el tipo de acción:
o Si PV tiende a aumentar cuando se realizan cambios positivos en el CV
(por ejemplo, al abrir una válvula aumenta el flujo registrado por un
transmisor instalado en la misma tubería de la válvula), entonces la
acción es directa.
o Si PV tiende a disminuir cuando se realizan cambios positivos en el CV
(por ejemplo, una temperatura que baja al abrir una válvula de
refrigeración en un intercambiador), entonces la acción es inversa.

Página 30 de 183
 o Para el análisis de la acción de control no es necesario tener en cuenta
la operación del elemento final de control, siempre y cuando se use la
salida CVEU del lazo para comandar dicho elemento de control.
• Calculate Using:
o Proportional term: Seleccione si el término proporcional se aplica
sobre el cambio en el error (E) o el cambio en el PV.
o Derivative term: Seleccione si el término derivativo se aplica sobre el
cambio en el error (E) o el cambio en el PV.
Se sugiere usar el término proporcional aplicado al cambio en el error, y el
término derivativo aplicado al cambio en el PV. De esta manera se eliminan
picos en la salida del controlador ocasionados por el término derivativo
cuando se realizan cambios en el setpoint. Esto es importante en lazos en
los cuales se presentan frecuentes cambios de setpoint, pues la variabilidad
del proceso se puede afectar.
• Derivative Smoothing: Esta opción adiciona un filtro pasa bajos de primer
orden al término derivativo de la ecuación PID. Se usa para minimizar los
efectos de un PV con ruido. Normalmente este parámetro debe estar
deshabilitado.
• PV Tracking: Habilite esta opción para que el SP siga al valor del PV cuando el
lazo se encuentra en modo Manual. Utilice esta opción para que el lazo no
experimente saltos al pasarlo de modo Manual a Auto (debido a un setpoint
diferente al PV actual).
• Manual Mode After Initialization: Esta opción no se usa en esta guía.
• Equation Type: El tipo de ecuación que debe ser utilizado es Dependent
(Ecuación de términos dependientes).
• CV Zero-Crossing Deadband: Esta opción no se usa en esta guía.

Escalización del CV
(salida CVEU)

Limites del SP

Figura 19 Propiedades instrucción PIDE - EUs/Limits

En la pestaña EUs/Limits se ingresa los valores de escalización de la salida del lazo,

normalmente se usa los valores de 0% y 100%. Los valores de escalización del PV en
esta pestaña se encuentran en gris debido a que se configuraron como parámetros
visibles, y su valor se está copiando desde los parámetros de configuración del
transmisor de entrada (entradas PVEUMax y PVEUMin en la Figura 17).

Es importante cuadrar en esta pestaña los límites del SP de forma que sean
consistentes con los límites del PV (normalmente se cuadra los límites del SP para que
sean iguales a los del PV, sin embargo, esto no se hace de manera automática, para
permitir cuadrar unos valores de límite de SP cuando sea necesario modificarlos).

Cambio en el estado de operación del lazo

Para cambiar el estado de operación del lazo se utilizan los siguientes tags:

Tag Descripción
ProgProgReq Comando para pasar el lazo al estado de control por programa,
emitido desde la lógica del PLC.
ProgOperReq Comando para pasar el lazo al estado de control por operador,
emitido desde la lógica del PLC.
OperProgReq Comando para pasar el lazo al estado de control por programa,
emitido desde el HMI.
OperOperReq Comando para pasar el lazo al estado de control por operador,
emitido desde el HMI.

Como regla general, todo parámetro que comience con la palabra “Prog” corresponde
a tags que son de uso dentro del programa del PLC, mientras que aquellos que
empiezan con “Oper” son tags usados por el HMI.

El estado de operación actual se puede monitorear en el tag ProgOper

• ProgOper = 0
Lazo en estado de control por operador.
• ProgOper = 1
Lazo en estado de control por programa.

Bloqueo del estado de operación de un lazo

Existen situaciones en las cuales se desea que un lazo se mantenga en un estado de
operación determinado (que la operación del lazo la gobierne únicamente el operador,
o únicamente el programa). Para ello se puede forzar un valor de ‘1’ en el tag
“ProgXXXReq”, como se muestra en las siguientes figuras (se debe volver visible el
parámetro deseado).

Página 32 de 183
 Para forzar lazo en estado de control por
Operador, usar ProgOperReq

Figura 20 Lazo "bloqueado" en estado de Control por Operador

Para forzar lazo en estado de control por

Programa, usar ProgProgReq

Figura 21 Lazo "bloqueado" en estado de Control por Programa

Criterio de manejo de las salidas análogas

La salida de la instrucción normalmente sirve para controlar una salida análoga (la cual
se encarga de manipular un elemento de control final, como una válvula de control).

Como se ha explicado anteriormente, se debe usar la salida CVEU de la instrucción

PIDE, la cual ya se encuentra escalizada de acuerdo al tipo de elemento de control.
Esto significa que siempre se debe usar la misma relación en la configuración de los
puntos en la tarjeta de salidas análogas: El valor de CVEU = 0 corresponde a 4 mA, y
CVEU = 100 corresponde a 20 mA.

Esta configuración se presenta en la siguiente figura.

 Figura 22 Configuración salida válvula

5.10.4 MANEJO DE ENCLAVAMIENTOS

Los enclavamientos son condiciones que hacen que el lazo de control asuma un valor
determinado sin importar el estado o modo de operación en el cual se encuentran. Por
lo general se usan para tomar acciones que permitan proteger el proceso cuando existe
alguna variable que se encuentra fuera de su rango normal de operación.

Para el manejo de los enclavamientos se usa el modo override que ofrece la instrucción
PIDE:
• El modo Override se ejecuta cuando la entrada ProgOverrideReq asume el
valor de ‘1’, sin importar el estado (control por operador o control por
programa) ni el modo de operación de lazo (auto o manual).
• Cuando el lazo entra en modo Override, la salida asume el valor especificado
en el parámetros CVOverride.
• Mientras la condición de Override se mantiene (entrada ProgOverrideReq en
‘1’) no es posible cambiar el estado/modo del lazo, ni cambiar manualmente la
salida del lazo (a menos que se cambie el valor en CVOverride).
• Una vez que la condición de Override se normaliza (entrada ProgOverrideReq
nuevamente en ‘0’) el lazo se mantiene en su estado de Override (es decir, el
lazo NO retorna a su estado previo al override). Una vez esto suceda, se puede
cambiar el estado/modo del lazo ya sea por lógica en el programa o por
comando del operador.

En la Figura 23 se muestra un ejemplo de enclavamiento, en el cual se ordena cerrar

la válvula proporcional en el evento que se pierda la confirmación de apertura de la
válvula discreta FY8301D.

Página 34 de 183
 Comando de override
(enclavamiento) Valor de Override

Figura 23 Ejemplo de generación de enclavamiento

Se debe crear un tag Booleano con el nombre del lazo y la terminación “_BypassEn”
con el cual sea posible hacer bypass del enclavamiento (y evitar que la acción se
ejecute en caso de cumplirse las condiciones).

5.10.5 LAZOS EN PARALELO

Existen situaciones en las cuales dos o más variables de proceso son controladas
por la misma variable de control. Frecuentemente, el valor de la salida hacia el
actuador en campo necesita ser limitado en esos casos para usar ya sea la mayor o
la menor de las salidas de dos o más controladores PID (uno por cada variable de
proceso).

Por ejemplo, tome el caso en el cual se desea controlar el flujo y la presión por
medio del control de una válvula de control de flujo. Para este caso es necesario
crear una instrucción PIDE que se encargue del control de flujo, y otra instrucción
PIDE para controlar la presión, y usar la menor de las salidas de esos lazos para
controlar el elemento final de control.

Un punto importante de este tipo de implementaciones, es que se debe “alinear” el

lazo que no está controlando con el lazo activo, y permitir un cambio “bumpless”
(sin sobresaltos) cuando se conmute entre los lazos. Con la instrucción PIDE
implementar este tipo de controles es sencillo, ya que el término CVn-1 se encuentra
disponible en la instrucción. La implementación de este esquema se muestra en la
Figura 24.

En esta figura, puede verse que existen dos lazos trabajando en paralelo, y se usa
una instrucción ESEL para seleccionar el menor de los dos lazos. La salida de la
instrucción ESEL es la que alimenta la salida análoga (accionando el elemento de
campo), y se realimenta a los bloques PIDE para que cada uno se mantenga
sincronizado con el otro.
En el caso de la figura, puede inferirse que en ese momento el lazo dominante es el
lazo de flujo, pues su PV (39.67) se encuentra bastante cerca del SP (40), mientras
que en lazo de presión la diferencia es más notoria (PV= 10.35, SP=20). Sin embargo
el lazo de presión no modifica su salida, debido a la realimentación que tiene del
valor actual de la salida. El lazo dominante puede confirmarse observando la salida
“SelectedIn” del bloque ESEL, la cual indica que en este caso la entrada
seleccionada es la entrada In1 (que corresponde a la salida del lazo de flujo).

Lazo de flujo

Selecciona el menor
entre los dos lazos

Lazo de presión

Figura 24 Control de lazos en paralelo

La implementar este esquema, se configura cada lazo por separado, configurando

sus parámetros de la manera explicada en las secciones anteriores. Adicionalmente
se debe configurar cada lazo para volver visible el parámetro CVPrevious, y colocar
en ‘1’ el parámetro CVSetPrevious (para habilitar el uso del término CVn-1 en el
cálculo de la salida):
• CVPrevious: Marcarlo como visible
• CVSetPrevious: Colocarlo en ‘1’.

Página 36 de 183
Luego se inserta una instrucción de selección. Para este ejemplo se usó la
instrucción ESEL, con los siguientes parámetros:
• Parámetros visibles: Dejar visibles únicamente los siguientes parámetros:
o In1
o In2
o Out
o SelectedIn
• InsUsed: Colocarlo en ‘2’, para indicar que van a ser usadas las entradas In1
e In2.
• SelectorMode: Colocarlo en ‘2’, para indicar que la instrucción debe colocar
en su salida el menor valor que encuentre en sus entradas. Los valores
posibles son:
o 0 = Selección manual: La entrada seleccionada se escoje desde el
programa o por comando del operador.
o 1 = High Select, la instrucción selecciona el valor más alto.
o 2 = Low Select, la instrucción selecciona el valor más bajo.
o 3 = Median Select, la instrucción selecciona el valor que se
encuentra en el medio entre las entradas (no es el promedio). Si las
entradas In1, In2 e In3 se encuentran habilitadas con valores de 2, 3
y 10, la opción Median Select hará que la instrucción seleccione 3.
o 4 = Average Select, la instrucción usa el promedio de las entradas
usadas (para el ejemplo anterior, el promedio sería 5.

La instrucción ESEL fue escogida en este ejemplo por facilidad de uso, sin embargo
cualquier otra instrucción o lógica de selección puede ser usada.
 Selector de lazo

Figura 25 Ejemplo de uso de selector convencional

En la Figura 25 se reemplazo la instrucción ESEL por un selector convencional

(SEL), y se crea un tag para seleccionar la entrada deseada
(M02_FY8153C_SELECT). De esta forma es posible programar cualquier otra
condición deseada de forma que modifique el valor de M02_FY8153C_SELECT, y
por ende, la selección del lazo seleccionado como lazo de control.

5.10.6 LAZOS EN CASCADA

Los lazos en cascada son útiles para anticiparse a cambios en la variable de proceso
que se desea controlar por medio de la ejecución de un lazo “interno” relacionado
con una variable que experimenta un cambio más rápido como efecto del cambio
en el elemento de control.

Por ejemplo, se tiene el caso en el cual se desea controlar la temperatura de la torre

de amina por medio de la variación en la apertura de la válvula de control de flujo de
agua caliente. En este caso el lazo maestro es un lazo de temperatura, controlando
un lazo de flujo de agua caliente (lazo esclavo, ya que el flujo reacciona más rápido
a las variaciones en la válvula de control que la temperatura). Un diagrama de este
caso se muestra en la siguiente figura.

Página 38 de 183
 Lazo maestro
(temperatura)

Lazo esclavo
(flujo)

Figura 26 Ejemplo de lazo en cascada

El lazo esclavo (el control de flujo en este ejemplo) puede trabajar en modo
Cascada, con lo cual su setpoint se alimenta de la salida del lazo maestro, o puede
estar en modo Auto/Manual, con lo cual el operador realiza un control de flujo de
agua directamente.

Para la implementación de la cascada se deben tener en cuenta las siguientes

recomendaciones:
• Si el lazo esclavo se saca del modo cascada, el lazo maestro debe dejar de
ejecutarse (debido a que n noo está afectando al proceso), pero debe cuadrar
su salida de forma que se encuentre “sincronizada” con el setpoint actual
del lazo esclavo, de forma que si el esclavo vuelve a modo cascada, el
primario pueda seguir controlando sin sobresaltos.
• Cuando el la lazo
zo esclavo llegue a un límite en su setpoint o un límite en su
salida, se debe notificar al lazo maestro para que no continúe integrando en
la dirección de ese límite. Por ejemplo, si el lazo esclavo ya ha abierto la
válvula al 100%, no tiene sentido que eell lazo maestro siga pidiendo más
agua caliente (incrementando el SP remoto).

Configuración del lazo esclavo

El lazo esclavo se configura como un lazo normal, pero adicionalmente:
• Se debe habilitar la visibilidad del parámetro SPCascade. Por medio de este
parámetro el lazo maestro le estable el setpoint cuando se encuentra en modo
Cascada.
• Se debe habilitar la visibilidad del parámetro InitPrimary. Esta salida se usa
para que el lazo maestro se mantenga sincronizado con el esclavo cuando este
último no se eencuentra en modo Cascada.
 • Se debe habilitar la visibilidad de los parámetros WindupHOut y WindupLOut.
Estas salidas le indican al lazo maestro que el esclavo se encuentra en un límite,
de forma que debe dejar de integrar.
• Se debe habilitar la visibilidad d
de
e la salida CasRat (para tener indicación de este
modo de operación).
• El parámetro AllowCasRat debe estar en ‘1’.

El lazo configurado de acuerdo a estas indicaciones se muestra en la siguiente

figura.

Figura 27 Configuración del lazo esclavo

Configuración del lazo maestro

En el lazo maestro se deben configurar los siguientes parámetros:
• Se debe habilitar la visibilidad de los parámetros CVInitReq y CVInitValue.
Estas entradas se usan para mantener sincronizado el lazo con el esclavo
cuando éste no se encuentra en modo Cascada:
o CVInitReq (maestro) = InitPrimary (esclavo)
o CVInitValue (maestro) = SP (esclavo)
• Se debe habilitar la visibilidad de los parámetros WindupHin y WindupLin.
Estas entradas reciben las señales que indican que el esclavo se encuentra en
un límite de operación:
o WindupHin (maestro) = WindupHOut (esclavo)
o WindupLin (maestro) = WindupLOut (esclavo)
• El rango de las unidades de ingeniería de la salida del maestro (CVEuMax y
CVEuMin) deben coincidir con el rango de las unidades de ingeniería del
Setpoint del esclavo
• La salida del maestro (CVEU) se debe cablear a la entrada de setpoint remoto
(SPCascade) del esclavo.

La cascada completa se muestra en la siguiente figura:

Página 40 de 183
 Figura 28 Lazos en cascada

En este ejemplo, el lazo maestro (control de temperatura) se encuentra en automático,

con una temperatura actual (PV) de 134.4ºC y un Setpoint de 100 ºC, generando una
salida de 13.09 gpm (la salida del lazo – CVEU – se configura para manejar el mismo
rango del lazo secundario, que para este ejemplo es un rango de 0 a 20 gpm). La acción
del lazo se configura como acción directa, de forma que en este caso la salida se
mantiene disminuyendo (mientras PV > SP).

Luego, la salida del lazo maestro alimenta la entrada SPCascade del lazo esclavo (el
cual se encuentra en modo Cascada – CasRat). En este modo, el esclavo modifica su
salida para buscar que su PV (flujo de agua) se acerque al setpoint indicado por el
maestro.

Cuando el lazo esclavo se cambia a un modo diferente a Cascada, la salida InitPrimary

se activa, indicándole al lazo maestro que debe establecer su salida al valor
especificado en CVInitReq (la cual se alimenta del SP del lazo esclavo). Es decir, la
salida del lazo maestro se encuentra sincronizada con el SP del esclavo siempre que
éste se encuentre en un modo diferente a modo Cascada. Esta situación se ilustra en la
siguiente figura:
 Figura 29 Lazos en cascada - esclavo en Auto

5.11. LOGICA DE TOTALIZADORES

Los totalizadores son funciones lógicas cuya función es integrar el valor en el tiempo de una
señal determinada (por lo general una señal de flujo).

Para la implementación del totalizador se hace uso de la instrucción TOT suministrada por
RSLogix5000, la cual se debe configurar en una rutina FBD.

Rutina de
totalizadores

Figura 30 Implementación de Totalizador

Al insertar la instrucción TOT, se crea un tag de Programa con el nombre TOT_XX, el cual
debe ser cambiado por el nombre que corresponde con el totalizador (en este caso,
M01_FQ_8101, y se crea como tag de Controlador de tipo TOTALIZER). Se debe realizar los
siguientes pasos:
• Habilitar la visibilidad de los siguientes parámetros:
o In: Es la entrada para el transmisor ((o
o señal) que se desea totalizar.

Página 42 de 183
 o ProgProgReq: Entrada usada para pasar el totalizador en estado de control
por programa.
o ProgResetReq: Entrada para reinicializar el totalizador.
o Total: Salida que lleva el valor actual totalizado.
o OldTotal: Salida que muestra el valor totalizado antiguo (desde el último
Reset).
o RunStop: Salida que indica el estado del totalizador. Un valor de ‘1’ indica
que el totalizador está corriendo.
• Configurar los siguientes parámetros:
o TimeBase: Ingrese la base de tiempo de la totalización:
 0 = Segundos
 1 = Minutos
 2 = Horas
 3 = Días
Este parámetro debe coincidir con las unidades de tiempo de la variable
totalizada, así por ejemplo, si la entrada está en:
• GPM (galones por minuto): Colocar este parámetro en ‘1’
• SCFH (Standard Cubic Feet per Hour): Colocar en ‘2’
o Gain: Se usa para multiplicar la entrada por el valor ingresado en este
parámetro, como por ejemplo, cuando se desea realizar una conversión de
unidades.
o ResetValue: Este es el valor que asume el totalizador una vez sucede un
reset. Normalmente debe ser cero.
o LowInCutoff: Es el valor mínimo que debe existir en la entrada para que el
totalizador trabaje. Si la entrada se encuentra por debajo de este valor, el
totalizador se detiene. Se usa para evitar la totalización de valores
fantasmas (por ejemplo, cuando se detiene el flujo, el transmisor puede
quedar indicando un valor muy pequeño, el cual, si es totalizado, induce
errores en el valor totalizado en el tiempo).
o ProgStartReq: Coloque este valor en ‘1’ para que el totalizador arranque. Si
necesita controlar el arranque/parada del totalizador de acuerdo a
determinadas condiciones, vuelva visibles los parámetros ProgStartReq y
ProgStopReq y aliméntelos con las señales adecuadas.

En el caso del totalizador de la Figura 30, el valor totalizado se reinicializa todos los días a la
media noche (el tag DateTime_Day_Change fue configurado para colocarse en ‘1’ durante
los últimos dos segundos antes de media noche, ver ejemplo en 5.12.1).

5.12. FUNCIONES VARIAS

En esta sección se especifican algunas funciones que pueden ser usadas en los programas
de control, y que son generales a todo el programa del PLC. Estas funciones se
implementan en lógica escalera, dentro de la rutina a_Misc.
 Rutina de funciones varias

Figura 31 Rutina de funciones varias

5.12.1 LOGICA DE FECHA Y HORA

Existen muchas situaciones en las cuales se necesita realizar alguna acción con base en
la fecha y hora actual del PLC. Para obtener esta información desde la lógica del PLC se
debe realizar la siguiente implementación:

Figura 32 Instru
Instrucción para leer la fecha/hora del PLC

Se usa la instrucción GSV con la clase WallClockTime y el atributo “LocalDateTime” (se

debe seleccionar este atributo y no DateTime. DateTime recupera la hora GMT, la cual
muy probablemente no es la hora local – en Colombia la hora es GMT – 5).

El resultado de la instrucción se guarda en un vector de 7 posiciones de tipo DINT,

usando el nombre DateTime[]. Cada posición de este vector indica un valor específico
de la hora y fecha actual:
• DateTime[0] = Año
• DateTime[1] = Mes
• DateTime[2] = Día
• DateTime[3] = Hora
• DateTime[4] = Minuto

Página 44 de 183
 • DateTime[5] = Segundo
• DateTime[6] = Microsegundo
Por ejemplo, se puede generar una indicación de cambio de día, como se muestra en la
siguiente figura:

Figura 33 Generación de indicación de cambio de día

5.13. CRITERIOS DE PROGRAMACION DE REDES DE

COMUNICACIONES
En esta sección se muestran los criterios de programación de las redes de comunicaciones
más frecuentes que se encuentran en la facilidad.

5.13.1 RED ETHERNET

La red Ethernet se usa principalmente para realizar comunicaciones entre el sistema
HMI (y otros sistemas de información como Historiadores) con los Controladores.
También está aprobado el uso de esta red para el envío de señales no críticas entre
controladores por medio de instrucciones de mensaje.

Otra implementación normalmente usada para red Ethernet, es usarla para

comunicaciones con unidades remotas (RTU) por medio del protocolo Modbus.

Existen implementaciones de sistemas de IO remoto sobre redes Ethernet, pero dicha

implementación no se usa en las facilidades. Para sistemas de IO remoto se usa red
Controlnet.

Hardware
Para el uso de controladores en red Ethernet se cuenta con las siguientes alternativas:

Controllogix
• Usando redundancia de procesador: Módulo 1756-EN2T
• Sin redundancia: Módulo 1756-ENBT
Sistemas SLC-500
• Procesador referencia 1747-L5x (procesadores con puerto Ethernet embebido)

Sistemas PLC5:
• Procesador referencia 1785-L20E, 1785-L40E, 1785-L80E (procesadores con
puerto Ethernet embebido)

Sistemas microLogix:
• Sistema referencia MicroLogix 1100, 1400

Opciones con conversores Serial/Ethernet

Para aquellos sistemas que no poseen puertos Ethernet embebidos (como
controladores SLC 4/xx e inferiores, o MicroLogix 1000, 1200 y 1500) se puede usar
un conversor 1761-NET-ENI.

Direccionamiento
La asignación de direcciones de los elementos en la red de Control es responsabilidad
del ingeniero IEC, el cual maneja el listado maestro de direcciones.

Para facilidades se usan direcciones Clase A, usando normalmente la dirección de tipo

10.0.0.x, con máscara de subred 255.255.255.0

Implementación en Controllogix
Como regla general, en el IO Configuration del proyecto de RSLogix5000 solo deben
existir elementos que estén relacionados con IO. Como se dijo anteriormente, las
tarjetas Ethernet solo se usan para comunicaciones HMI (y en algunos casos para
compartir información no crítica entre Controladores), por lo que la tarjeta Ethernet
NO debe ser incluida en el IO Configuration.

Todo sistema que necesite compartir información con el HMI, debería incluir en su
diseño una tarjeta de comunicaciones Ethernet. Se debe evitar usar otro tipos de redes
(por ejemplo, la Controlnet) para manejar datos de HMI.

Para la implementación de comunicaciones entre PLCs, se usa la instrucción MSG,

usando el tipo de mensaje “CIP Data Table Read” (de forma que el PLC que ejecuta la
instrucción MSG lea la memoria de un PLC remoto).

Página 46 de 183
 Seleccionar esta opción

Nombre de tag (generalmente un

vector) en el PLC remoto

Número de elementos a leer

Nombre del tag local que recibe la

información.

Figura 34 Instruccion MSG para leer la memoria de otro PLC

Debido a que la tarjeta Ethernet no se encuentra adicionada en el IO configuration, es

necesario especificar el path de comunicaciones usando el formato CIP (Puerto,
Dirección), en la cual Puerto puede ser el valor ‘1’ (bajar al backplane) o ‘2’ (salir al
puerto de comunicaciones). Dirección corresponde a la dirección que corresponde (si se
usa ‘1’ para bajar al backplane, entonces Dirección representa el número de slot. Si se
usa ‘2’ para salir al puerto de comunicaciones de una tarjeta Controlnet, entonces
Dirección corresponde a un número de nodo de red).

Por ejemplo, para la figura anterior, el path de comunicaciones se encuentra

configurado como se muestra:
1, 6, 2, 10.0.0.11, 1, 1

Puerto Backplane # de Slot Puerto Backplane # de Slot

Puerto de Comms Dirección IP

Es decir, se está leyendo la memoria de un PLC que se encuentra en el Slot 1, en un

chasis que tiene una tarjeta Ethernet con dirección 10.0.0.11. Para llegar a esta tarjeta
se sale a través del puerto de comunicaciones de una tarjeta Ethernet que se encuentra
en el slot 6.
5.13.2 RED CONTROLNET
La red Controlnet es una red determinística usada principalmente para el manejo de
sistemas de IO, y señales críticas (como enclavamientos) entre diferentes
Controladores.

La red maneja dos tipos de flujo de información: Información determinística (como la

información de los IO remotos sobre Controlnet, y los tags producidos/consumidos) e
información no determinística (por ejemplo, mensajes enviados entre procesadores
usando instrucciones MSG, o lectura de infinformación
ormación desde un HMI o estación de
ingeniería).

Cada elemento en la red se identifica con un número de nodo, el cual corresponde a un

número entre 1 y 99. Los nodos que manejan datos programados (generalmente PLCs)
deben ser configurados en las direccion
direcciones
es más bajas de la red, sin dejar espacios entre
ellos. Los nodos que no manejan datos programados (por ejemplo, paneles de
operador o computadores con interfaz Controlnet) deben configurarse con las
direcciones de nodo más altas en el rango usado.

Por ejemplo,
emplo, si se tiene un sistema conformado por 4 chasis de PLC, dos paneles de
operador sobre Controlnet y una estación de ingeniería, la asignación de nodos deberá
ser:
• Nodos del 1 al 4: Chasis de PLC
• Nodos del 7 al 9: Paneles de operador y Estación de Inge
Ingeniería

En este caso se deja un espacio de reserva (las direcciones 5 y 6) para permitir futuras
expansiones de la red:

Figura 35 Red Controlnet de ejemplo

Un chasis remoto sobre Controlnet en Controllogix aparece como se muestra

muest en la
siguiente figura.

Página 48 de 183
 Figura 36 Chasis remoto Controlnet

Los parámetros que configuran (y limitan) una red Controlnet son:

• NUT: Network Update Time – Es el tiempo de ciclo que se configura en la red
(es decir, un nodo puede transmitir un paquete máximo una vez cada NUT
intervalos). Normalmente tiene un valor de 5 ms.
• RPI: Requested Packet Interval – Es el tiempo de actualización deseado que se
configura en cada elemento de la red. Su configuración depende de los
requerimientos de velocidad de la información transmitida (por ejemplo, un
sistema digital puede tener un rpi rápido de 20 ms, mientras que una tarjeta
transmitiendo señales análogas puede hacerlo a un rpi más lento de 100 ms).
• API: Actual Packet Interval – Es el tiempo de actualización real que tiene cada
elemento en la red, y que el software RSNetworx calcula cuando se está
configurando la red. En el peor de los casos es igual a un múltiplo binario de
NUT que se encuentre por debajo del RPI.

Por ejemplo, si se tiene un NUT de 5 ms y un RPI de 100 ms, el nodo tendrá un

API de máximo 80 ms (80 = 24 x 5, y es menor al RPI de 100 ms).
• Conexiones: Son los enlaces establecidos entre un consumidor de datos (por
ejemplo, un PLC) y un productor de datos (por ejemplo, una tarjeta de
entradas análogas). Cada tipo de dispositivo tiene un número máximo de
conexiones que puede manejar:
o Tarjetas 1756-CNB – Hasta 64 conexiones.
o Tarjetas 1756-CN2 – Hasta 100 conexiones.
o Controladores 1756-L6x – 250 conexiones.
El tema de las conexiones es importante porque representa una de las
limitantes del sistema, y es un recurso que debe optimizarse.
• Conexiones directas: Todas las tarjetas que se encuentren en chasis remoto
que no sean digitales, requieren de una conexión con el PLC.
• Conexiones optimizadas por Rack: Esta es una opción que se usa para
minimizar el número de conexiones requeridas entre un controlador y un chasis
remoto que contiene módulos análogos en su mayoría. En vez de crear una
 conexión directa con cada módulo digital, el controlador establece un par de
conexiones con el chasis completo, y a través de estas conexiones se comunica
con los módulos de IO digitales de dicho chasis.

De acuerdo a lo anterior, se presentan los siguientes criterios de diseño:

• Organice los chasis remotos por tipos de señales. En el caso que se tengan dos
chasis remotos con una distribución uniforme de tarjetas digitales y análogas,
es preferible separar los chasis en un chasis de IO digital y otro de IO análogo.
• En los chasis remotos en los que hay hayaa tarjetas digitales, use la opción Rack
Optimization cuando esté configurando la tarjeta Controlnet remota:

Formato de Comms

Figura 37 Uso de Rack Optmization en chasis remotos

Y en la pestaña Connection, configure el valo

valorr del RPI (para chasis remotos, se
recomienda dejar un valor de 20 ms).

Adicionalmente, al adicionar las tarjetas discretas, se debe seleccionar la

opción Rack Optimization en la ventana de configuración de cada tarjeta:

Página 50 de 183
 Formato de Comms

Figura 38 Rack Optimization en módulo digital remoto

Debido a que se usa la opción Rack Optimization, no se debe configurar ningún

valor para el RPI (se usa el definido en la tarjeta Controlnet).

• Las tarjetas análogas y especiales (en esencia, cualquier otra tarjeta que no es
digital) requiere conexiones directas. Esto significa que no ofrecen la opción
Rack Optimization en la ventana de configuración.

Se presenta las siguiente tabla con los valores recomendados de RPI para cada
tipo de tarjeta típica usada en facilidades:

Tarjeta Comm Format RPI

Controlnet en Chasis Local NA NA
Controlnet en Chasis Remoto Rack Optimization 20
Tarjetas digitales Rack Optimization NA
Tarjetas de entrada análoga Float Data 100
Tarjetas de salida análoga Float Data 25
MVI56-MCM Data - INT 125
MVI56-MCMR Data - INT 125
MVI56-MNET Data - INT 125
MVI56-MNETR Data - INT 125

Configuración de mensajería sobre Controlnet (tags producidos/consumidos)

La información compartida entre procesadores a través de red Controlnet se realiza
por medio de la configuración de mensajes Producidos/Consumidos. El esquema de
implementación se muestra a continuación:
 Figura 39 Tags Producidos/Consumidos entre Gateway y PCS

En el ejemplo anterior, se tienen dos PLCs (Gateway y SGPPCS) que están

intercambiando un vector de DINTs cada uno hacia el otro. Los vectores se nombran
usando el nombre del productor de datos, y se crean en ambos PLCs, de esta manera:

En el PLC Gateway:
• GTWY_PRODUCED_11: Vector de información producida
• SPG_PCS_PRODUCED_1: Vector de información consumida desde SGPPCS

En el PLC SGPPCS:
• GTWY_PRODUCED_11: Vector de información consumida desde Gateway
• SGP_PCS_PRODUCED_1: Vector de información producida

Para poder configurar los tags consumidos, es necesario adicionar el PLC destino en el
IO Configuration del PLC consumidor, por ejemplo, en el PLC Gateway:

PLC SGP_PCS en IO Configuration

del PLC Gateway

Figura 40 Procesador Pro

Productor en IO Configuration

Para producir tags, solo es necesario definir el tag como Producido y especificar
cuantos consumidores van a consumir ese dato. Para consumir tags se debe marcar
como Consumido, y especificar desde cual Productor se va a consumi
consumirr la información.
Adicionalmente se debe definir el parámetro RPI que va a usar esta conexión. Esta
configuración se muestra en la siguiente figura:

Página 52 de 183
 Tag Producido Tag Consumido

Seleccionar Type Seleccionar Type

como Produced como Consumed

Seleccionar PLC
Productor

Seleccionar Num Max Ingrese el nombre del tag

de Consumidores remoto

Ingrese el valor RPI

Figura 41 Tags Producidos / Consumidos

Un punto importante durante la configuración del tag consumido es establecer el

parámetro RPI, debido a que RSLogix5000 coloca un valor por defecto muy pequeño.
Para los tags producidos/consumidos de la facilidad use un RPI de 200 ms.

Configuración en RSNetworx for Controlnet

Los siguientes puntos deben ser tenidos en cuenta al realizar la calendarización de la
red usando RSNetworx for Controlnet:

Propiedades de la red: En el diálogo de configuración de propiedades de la red en

RSNetworx (menú Network
Properties) configure los siguientes valores:
1. Recuerde seleccionar si la red maneja redundancia: Existe un campo llamado
Media Redundancy el cual por defecto se encuentra en “A Only” (usando solo
el canal A). Si se va a manejar una red con redundancia, debe seleccionar la
opción “A/B”.
2. NUT: Por los requerimientos de velocidad de las aplicaciones de las facilidades,
se recomienda configurarlo en 5 ms. Sin embargo, este parámetro puede
requerir ser ajustado en casos especiales, pero nunca reducirlo a menos de 5
ms.
3. Max Scheduled Address: Este parámetro debe ser configurado como el nodo
máximo que hace uso de la banda programada. Se recomienda dejarlo
configurado en el valor exacto de nodos programados de la red (o a lo sumo
una posición por encima). Para el ejemplo de la Figura 35, este parámetro debe
configurarse con el valor de 4.
 4. Max Unscheduled Address: Corresponde al nodo máximo que hace uso de la
banda no programada, se recomienda configurarlo una posición adicional al
nodo
odo máximo. Para el caso de la Figura 35 este parámetro tendría un valor de
10.
5. Configuración del medio físico: La ventana de propiedades de la red poseen
una pestaña llamada Media Configuration, en la cual se adicionan las
cantidades de repetidores y medios (coaxial y fibra) que existen en la red. Esto
se hace con el objeto que RSNetworx tenga en cuenta los retardos inducidos
por estos dispositivos en el cálculo del aalgoritmo
lgoritmo de la red. En la siguiente
figura se muestra esta pestaña con valores configurados para una red que usa 4
repetidores (parejas RPA/RPFM) y con las distancias aproximadas de coaxial y
fibra.

Figura 42 Especificación características del medio

5.13.3 RED MODBUS

Modbus es un protocolo de comunicaciones basado en la arquitectura
maestro/esclavo, diseñado en 1979 por Modicon para su gama de PLCs, y que
actualmente se ha convertido en uno de los estándares de comu
comunicaciones
nicaciones en la
industria. Existen versiones de protocolo Modbus para redes seriales y Ethernet
(modbus TCP).

Existen dos variantes del protocolo: Modbus RTU es una representación binaria
compacta de los datos. Modbus ASCII es una representación “legible
“legible”” del protocolo,
pero menos eficiente.

Cada dispositivo de la red Modbus posee una dirección única, y está en capacidad de
enviar órdenes Modbus, aunque lo habitual es permitirlo sólo a un dispositivo (el
maestro de la red). Cada comando Modbus contiene la dirección del dispositivo
destinatario de la orden, de forma que todos los dispositivos reciben la trama pero solo
el destinatario la ejecuta. Los comandos básicos Modbus permiten controlar un
dispositivo para modificar algunos de sus registros, o bien para solicitar el contenido de

Página 54 de 183
ellos. Cuando un comando especifica una dirección destino de cero, significa que es un
mensaje Broadcast (que debe ser ejecutado por todos los nodos de la red).

El protocolo Modbus maneja los siguientes tipos de datos (registros):

• Discrete Input: Son booleanos de solo lectura (usualmente son datos de puntos
de entrada en un sistema de I/O).
• Coils: Son booleanos de lectura/escritura.
• Input Registers: Son palabras de 16 bits de solo lectura (usualmente son datos
de puntos de entrada en un sistema de I/O).
• Holding Registers: Son palabras de 16 bits de lectura/escritura.

Las direcciones Modbus en los dispositivos se especifican desde la posición 1, pero en

el comando se especifica una dirección offset que inicia en cero. Por lo tanto, para leer
el Holding Register 0101, se debe especificar en el comando Modbus la posición 0100.

Figura 43 Direccionamiento Modbus

Para leer/escribir estas posiciones de memoria, el protocolo suministra diferentes

funciones, las cuales se resumen en la siguiente figura:
 Figura 44 Funciones básicas Modbus

En cada comando se especifica el número de registros consecutivos que se van a

afectar (leer o escribir), de forma que se pueden realizar operaciones en bloque (salvo
los casos de las funciones que actúan exclusivamente sobre un solo registro, como las
funciones 05 y 06). Así, por ejemplo, para leer los Holding Registers desde 0101 hasta
0151, se debe ejecutar un comando 03 hacia la dirección base 0100, especificando que
se lean 50 registros.

Para más información sobre el protocolo Modbus, consulte la guía de aplicación del
protocolo disponible en:
http://www.modbus.org/docs/Modbus_Application_Protocol_V1_1b.pdf

Módulos Prosoft para Controllogix

Para el caso de las facilidades, se usan módulos del fabricante Prosoft, principalmente
las referencias MVI56-MNET y MVI56_MCM, en sus diferentes variantes:
• MVI56E-MCM: Es una interfaz que le permite a los controladores
Controllogix comunicarse con otros dispositivos Modbus por medio de dos
puertos seriales a través de conexiones RS232, RS422 o RS485. Puede
trabajar como maestro o como esclavo en la red.
• MVI56-MCMR: Ofrece la misma funcionalidad que los MVI56E-MCM, pero
posee un bloque de comunicaciones reducido hacia el Controllogix, para
poder ser usado en sistemas de chasis remoto.
• MVI56E-MNET: Es una interfaz que le permite a los controladores
Controllogix comunicarse con otros dispositivos Modbus por medio de un
puerto Ethernet (Modbus TCP). Puede trabajar como maestro o como
esclavo en la red.
• MVI56E-MNETR: Ofrece la misma funcionalidad que los MVI56E-MNET,
pero posee un bloque de comunicaciones reducido hacia el Controllogix,
para poder ser usado en sistemas de chasis remoto.

Página 56 de 183
 Los módulos Prosoft para red Modbus se comportan como un espacio de memoria que
pueden ser escritos y leídos por el PLC. Este espacio de memoria es único (no existe
una memoria de escritura y otra de lectura), pero existen parámetros para definir un
segmento que va a servir como memoria de escritura (para que el PLC escriba en ella),
y otro segmento que trabaje como memoria de lectura (para que el PLC lea desde
estas posiciones).

El módulo posee internamente una lista de comandos, los cuales interactúan con este
espacio de memoria. Normalmente los comandos de escritura (escribir valores hacia
dispositivos en la red Modbus) toman los valores de segmento de memoria que el PLC
usa para escribir, y los comandos de lectura guardan los resultados en el segmento de
memoria que es leído por el PLC.

Por ejemplo, si se configura la tarjeta Prosoft para usar los primeros 600 registros
como segmento de escritura, y los 600 siguientes como segmento de lectura, se
obtiene la relación mostrada en la siguiente figura:

Figura 45 Relación entre PLC, módulo Prosoft y red Modbus

Un punto importante que se debe tener en cuenta es que el módulo diferencia de

manera diferente las direcciones de memoria interna cuando trabaja con comandos
binarios o comandos enteros:
• Comandos Enteros: Para comandos de tipo 3 (Read Holding Register), 4 (Read
Input Register), 6 (Write Single Register), 16 (Write Multiple Registers): La
dirección de memoria interna se referencia usando su dirección entera. Ejemplos
(los IDs son solo para efectos de este ejemplo):

ID Internal Reg Slave Modbus MB Controllogix Add

Address Count Address Funct Address
1 648 8 35 3 0100 ReadData[48]
2 135 1 35 6 1994 WriteData[135]
3 682 6 59 4 0 ReadData[82]
 Para el caso del ID 1, se está haciendo un Read Holding Register del nodo modbus
#35, leyendo 8 registros empezando en 40101 (la dirección 0100 en la
configuración indica la posición offset del registro, esto aplica para todos los
comandos). El resultado de esta lectura se envía al Controllogix en la posición 48
(648 – 600 = 48) del vector de lectura (ReadData[48]).

En el ID 2 se hace un Write Single Register hacia el nodo modbus #35, escribiendo

el valor de memoria 135 (que corresponde al dato enviado por el Controllogix en el
vector de escritura WriteData[135]) hacia el registro 41995.

En el ID 3 se hace un Read Input Register del nodo modbus #59, leyendo 6

registros empezando en 30001. El resultado de la lectura se envía al Controllogix
en ReadData[82].

• Comandos Discretos: Para comandos de tipo 1 (Read Coil), 2 (Read Input), 5 (Write
Single Coil), 15 (Write Multiple Coils): La dirección de memoria interna se
referencia a nivel de bits. Ejemplos (los IDs son solo para efectos de este ejemplo):

ID Internal Reg Slave Modbus MB Controllogix Add

Address Count Address Funct Address
4 435 1 35 5 0008 WriteData[27].3
5 10880 32 59 2 0 ReadData[80]

En el ID 4 se hace un Write Single Coil al nodo modbus #35, escribiendo la posición

de memoria BINARIA 435 (que corresponde a la posición entera de memoria
interna 27, bit 3). Este valor es enviado por el Controllogix a través de
WriteData[27].3

Nota: Conversión de dirección binaria a entera:

Parte entera = Dirección binaria / 16
435 / 16 = 27
Dirección de bit = Dirección binaria MOD 16
435 MOD 16 = 3

En el ID 5 se hace un Read Input del nodo modbus #59, leyendo desde 10001 hasta
10032. El resultado de esta lectura se guarda a partir de la posición binaria 10880
(que corresponde a la posición entera de memoria interna 680). Por lo tanto el
Controllogix recibe este dato en ReadData[80] (680 – 600 = 80).

Lógica de tarjeta Prosoft en Controllogix

Para la implementación de la lógica de la tarjeta se hará uso de la instrucción Add-On
suministrada por el fabricante, la cual puede ser descargada desde la página de
internet www.prosoft-technology.com. Al momento de escribir este documento, el
archivo Add-On se encuentra con el nombre MVI56EMNET_AddOn_Rung_v1_4.L5X, y
se encuentra en la ubicación:
http://www.prosoft-technology.com/content/download/15295/191553/file

Página 58 de 183
El procedimiento es similar para cualquier referencia de tarjeta Prosoft, en este caso se
muestra el desarrollo con el módulo MVI56E-MNET. Se debe consultar el manual
específico a cada tarjeta para ingresar los valores correctos de tamaños de entrada y
salida, en la ventana de configuración del módulo.

Adición del módulo al I/O Configuration

1. Adicionar el módulo MVI56E-MNET al proyecto de RSLogix5000:
En el I/O Configuration se da click derecho y se selecciona la opción “New Module”.
En la ventana que aparece se selecciona la opción “Other
1756-MODULE”
(Módulo genérico 1756.

Figura 46 Selección de módulo genérico 1756

2. Al pulsar OK, se abre la ventana de configuración del módulo. Ingrese los

siguientes valores:
Parámetro Valor
Name Ingrese un nombre para el módulo, por ejemplo,
MNET_1
Description Ingrese una descripción para este módulo
Comm Format Seleccione DATA-INT
Slot Ingrese el número del slot en el cual se encuentra el
módulo
Input Assembly 1
Instance
Input Size 250
Output Assy Instance 2
Output Size 248
Config Assy Instance 4
Config Size 0

Al pulsar OK en esta ventana, se abre la ventana de configuración adicional de la

tarjeta.
3. En la pestaña “Connection” ingrese el valor del parámetro RPI:
• Para módulos en chasis local, utilice un RPI de 10 ms.
• Para módulos en chasis remotos Controlnet, use un RPI de 125 ms.

Pulse OK para guardar los cambios y cerrar la ventana de configuración.

Importación de la instrucción Add

Add-On al proyecto:
1. Cree una rutina por cada tarjeta Prosoft que vaya a adicionar, usando el nombre de
la tarjeta como nombre de rutina (por ejemplo, MNET_1).
2. Abra la rutina, y seleccione con clic
clickk derecho el renglón vacío que se encuentra en
ella. En el menú contextual que se abre seleccione “Import RUNG”.

Figura 47 Importar Rung

3. Ubique el archivo que descargó de la página de Prosoft y selecciónelo

(MVI56EMNET_AddOn_Run
(MVI56EMNET_AddOn_Rung_v1_4.L5X).
g_v1_4.L5X). Al hacerlo se abre la ventana de
Configuración de Importación, mostrando los tags de Controlador que serán
creados.

Figura 48 Configuración de los tags para la importación

En el caso de la figura, el módulo se encuentra en el slot 1 del chasis local. En caso

que el módulo que está configurando se encuentre en un slot diferente, cambie
estos tags (Local:1:x) por los tags que corresponden.

Página 60 de 183
 Cambie el primer parámetro por el nombre del tag que va a usar la instrucción.
instrucc Por
ejemplo, si la tarjeta fue creada como MNET_1, puede usar AOI56MNET_1 en este
campo.

Igualmente, cambie el nombre del módulo por el nombre asignado en los pasos
anteriores. Por ejemplo, cambie MNET por MNET_1.

Pulse OK para importar la lógica.

4. Al finalizar la importación, se deben haber creado dos instrucciones en un solo

renglón, como se muestra en la figura:

Figura 49 Instrucciones importadas

En la instrucción GSV importada se debe seleccionar el módulo Prosoft adicionado,

para el caso de este ejemplo seleccione el texto MNET que corresponde al
parámetro Instance Name y seleccione el nombre del módulo (MNET_1) del listado
que se despliega.

5. Al realizar esta importación, también se han importado tipos nuevos de datos

da y la
instrucción AOI56MNET, la cual se puede encontrar en la pestaña Add-On
Add de la
barra de instrucciones.

Figura 50 Instrucción AOI56MNET en la barra de instrucciones

La información que se intercambia con la tarjeta (escrit

(escrituras
uras y lecturas) se realiza por
medio del tag definido en el parámetro MNET de la instrucción AOI56MNET (en el caso
del ejemplo de la Figura 49 es el tag MNET_1). Este tag es una UDT con los siguientes
miembros:
 • MNET_1
o MNET_1.DATA
 MNET_1.DATA.ReadData[600]
 MNET_1.DATA.WriteData[600]
o MNET_1.STATUS
o MNET_1.CONTROL
o MNET_1.UTIL

Las imágenes de entrada y salida se acceden por medio de los miembros ReadData y
WriteData, las cuales son vectores de 600 posiciones de valores enteros.

Los módulos Prosoft se configuran por medio de la herramienta Prosoft Configuration

Builder (PCB). Aunque los parámetros de configuración pueden variar de una tarjeta a
otra, en todas se debe confi
configurar
gurar una tabla de comandos cuando el módulo es usado
en modo Maestro de la red.
Esta tabla relaciona los comandos que el módulo estará ejecutando, así como las
frecuencias de actualización y las direcciones de memoria que se van a acceder, y se
accede a través
ravés de la opción MNet Client 0 Commands, como se muestra en la figura:

Figura 51 Opción para acceder la lista de comandos

Figura 52 Tabla de comandos de ejemplo

Página 62 de 183
 Los parámetros que se configuran por cada comando son:
• Enable: Seleccione Yes o No para habilitar/deshabilitar el comando.
• Internal Address: Ingrese la dirección de memoria interna usada para el
comando
• Poll Interval: Es el tiempo de retardo en decimas de segundo para la emisión de
un comando. Si se especifica un valor de 10 para este parámetro, el comando
se ejecutará cada segundo.
• Reg Count: Este parámetro especifica la cantidad de registros de 16 bits, o el
número de bits (dependiendo del tipo de comando) que serán usados.
• Node IP Address y Serv Port: Este parámetro es exclusivo de este tipo de
módulo (MVI56E-MNET), y sirve para especificar la dirección IP y puerto TCP
del nodo remoto.
• Slave Address: Corresponde a la dirección Modbus del nodo remoto.
• Modbus Function: Es la función Modbus a ser ejecutada, presenta un listado
con las diferentes opciones (leer Holding Register, escribir múltiples coils, etc).
• MB Address: Es la posición de memoria en el dispositivo remoto que se desea
leer o escribir.

La relación entre los comandos de la tabla anterior, y los elementos ReadData y

WriteData del UDT de la tarjeta se presenta a continuación:

ID Internal Add Modbus Function MB Address Comment Tag Controllogix

1 0 FC15 (Write Multiple Coil) 099 Comandos Broadcast WriteData[0].0
2 648 FC3 (Read Holding Reg) 100 Read Well DELE-B1 ReadData[48]
3 435 FC5 (Write Single Coil) 008 Write WV DELE-B1 WriteData[27].3
4 135 FC6 (Write Single Reg) 1994 Write V. Choke DELE-B1 WriteData[135]
5 0 FC15 (Write Multiple Coil) 099 Comandos Broadcast WriteData[0].0
6 600 FC3 (Read Holding Reg) 100 Read Well YR4 ReadData[0]
7 461 FC5 (Write Single Coil) 008 Write WV YR4 WriteData[28].13
8 0 FC15 (Write Multiple Coil) 099 Comandos Broadcast WriteData[0].0
9 608 FC3 (Read Holding Reg) 100 Read Well YR5 ReadData[8]
10 427 FC5 (Write Single Coil) 008 Write WV YR5 WriteData[26].11
11 0 FC15 (Write Multiple Coil) 099 Comandos Broadcast WriteData[0].0
12 616 FC3 (Read Holding Reg) 100 Read Well YR6 ReadData[16]
13 453 FC5 (Write Single Coil) 008 Write WV YR6 WriteData[28].5
14 153 FC6 (Write Single Reg) 1994 Write V. Choke YR6 WriteData[153]

En esta tabla puede verse la partición de la memoria interna:

• Las posiciones entre la 0 y 599: Posiciones de escritura, relacionadas con
WriteData[]
• Las posiciones entre la 600 y 1199: Posiciones de lectura, relacionadas con
ReadData[]

Por ejemplo, en la tabla puede verse que una operación de lectura FC3 del registro Modbus
40101 (comando con ID 2) guarda el resultado en la posición interna de memoria 648. Esta
posición corresponde con el tag de Controllogix ReadData[48]
5.14. LOGICA DE DIAGNOSTICOS
Los diagnósticos se implementan en el programa Diagnostics, usando la estructura general
presentada en la siguiente figura:

Figura 53 Rutinas del Sistema de Diagnósticos

Se usa el prefijo “Rxx”, donde xx es un número consecutivo, con el objetivo de mantener

organizadas las rutinas en un determinado orden. La primera rutina (DiagMain) es la rutina
principal del Programa, y su función principal es llamar a las otras rutinas.

Las primeras 4 rutinas (R00 a R03) se encargan de recopilar la información general del
chasis, como el diagnóstico de las fuentes redundantes, el consumo de memoria del
procesador, el estado de la redundancia (cuando aplique) y el estado general de los
módulos de I/O y de la batería del procesador. Estas rutinas son generales para todos los
procesadores.

Luego se encuentran las rutinas de diagnóstico de cada módulo en el chasis, por lo que la
estructura depende de la organización de módulos que cada chasis tenga. Se usa la
siguiente convención para nombrar cada rutina:
• Para los módulos de I/O que se encuentran en el mismo chasis del procesador, se crea
la rutina Rxx_LOCAL (en el caso de la Figura 53, no existen módulos de I/O en el mismo
chasis que el procesador).
• Las tarjetas Controlnet se diagnostican en rutinas llamadas Rxx_CNETyy, donde yy es el
slot en el cual se encuentra alojada la tarjeta.
• Los chasis de I/O remoto sobre Controlnet se diagnostican en rutinas llamadas
Rxx_CNETyy_Nzz, en donde:
o yy indica el slot de la tarjeta Controlnet desde que sale la red.
o zz indica el nodo Controlnet del chasis remoto.

Página 64 de 183
 Por ejemplo, para el chasis de I/O que se muestra en la Figura 54 (chasis PCS_80001A), la
rutina correspondiente de diagnóstico es la Rxx_CNET02_N03 (el chasis del Nodo 03, que se
conecta a la Controlnet asociada al módulo del Slot 02 del chasis principal).

Figura 54 Chasis SGPPCS

Para realizar el diagnóstico de los módulos del sistema de control, se usan principalmente
instrucciones GSV (una instrucción por cada módulo), las cuales al ser usadas
simultáneamente en grandes cantidades pueden afectar el consumo de memoria de I/O del
procesador (afectando por consiguiente su desempeño). Para evitar esta situación, se
implementa una lógica de ejecución secuencial, en la cual se tiene una variable que se
autoincrementa cada segundo, de forma que diferentes grupos de instrucciones GSV se
ejecutan en diferentes valores de la variable. La lógica de esta variable (Diag_Step) está
implementada en la rutina DiagMain.

De esta manera, solo se tiene un conjunto de instrucciones GSV siendo ejecutadas en un

determinado segundo. Para el caso del PLC Colombia PCS, esta variable llega hasta el valor
43 y luego se reinicializa (esto quiere decir, que el proceso de revisar todos los módulos de
este PLC tarda 43 segundos).

5.14.1 TIPOS DE DATOS DEFINIDOS POR EL USUARIO (UDTs)

Los siguientes UDTs fueron definidos para la implementación del sistema de
diagnóstico:
• Diag_CNET_Data
Name Data Type Descripción
EntryStatus INT
ConnStatus INT Module Connection Status:
16#4000 = Running
FaultInfo DINT
FaultCode INT
ChA_Status SINT Chan A Status
ChB_Status SINT Chan B Status
 Running BOOL Module Running
Ch_Red_Warning BOOL Module Channel Redundancy Warning
Ch_Active BOOL Active Channel:
0=B
1=A
ScanIOPulse1 BOOL 1=Scanning Remote IO
ScanIOPulse2 BOOL 1=Scanning Remote IO
ScanIOPulse3 BOOL 1=Scanning Remote IO

Esta UDT se usa para crear tags que agrupan los datos de cada una de las tarjetas
Controlnet del sistema.

• Diag_Code_83
Name Data Type Descripción
SMAC_Version SINT MAC Version Number
Station_Status INT
Vendor_Specific SINT
LED_Status SINT Controlnet Led Status

Esta UDT es usada para crear tags que recuperan el estado de los Leds de las tarjetas
Controlnet (para revisar el estado de los canales).

• Diag_Gen_Data
Name Data Descripción
Type
Free_Mem_IO DINT
Free_Mem_DT DINT
Free_Mem_Gen DINT
Free_Memory DINT
Total_Mem_IO DINT
Total_Mem_DT DINT
Total_Mem_Gen DINT
Total_Memory DINT
Used_Memory_IO DINT
Used_Memory_DT DINT
Total_Used_Memory DINT
Biggest_Gen_Mem_Size_Ava DINT
Biggest_IO_Mem_Size_Ava DINT
Biggest_DT_Mem_Size_Ava DINT
RedundancyState INT Redundancy State:
1 = PowerUp
2 = Prim & sec Sync

Página 66 de 183
 Name Data Descripción
Type
3 = Prim & sec Disq
4 = Prim sin Sec
5 = Prim & Sec enSyn
PhysicalChassisID INT 1 = Chasis A
2 = Chasis B
IOLedStatus INT 0=No IO listed
1=No modules respond
2=At least 1 module responds
3=All modules respond
PrimProcBattery BOOL Primary Controller
Battery Status
1 = Alarm
SecProcBattery BOOL Secondary Controller Battery
Status
1 = Alarm

Con esta UDT se agrupan los principales datos de diagnósticos relacionados con el
Controlador, de forma que el HMI lea toda esta información en un solo bloque.

• Diag_IOChasis
Name Data Type Descripción
Slot SINT Slot number of the module
EntryStatus INT From GSV Instruction
ConnStatus INT Connection Status (16#4000 = OK)
FaultCode INT Fault Code
FaultInfo DINT Fault Info (Extended Information)

Esta UDT se usa para crear los tags que agrupan la información de los módulos de I/O
en los chasis remotos.

• Diag_ProcFault
Name Data Type Descripción
DateTime DINT[2] Fault DateTime in UTC format
Type INT Fault Type
Code INT Fault Code
Last_DateTime DINT[2] Last Fault DateTime in UTC format
Last_Type INT Last Fault Type
Last_Code INT Last Fault Code

UDT usada para agrupar la información de falla de PLC (usada en la lógica de

monitoreo cruzado de fallas entre Controladores).
 • Diag_Proc_Ptge
Name Data Type Descripción
Free_Mem_IO REAL Free Memory IO Porcentage
Used_Mem_IO REAL Used Memory IO Porcentage
Total_Mem_IO REAL Total Memory IO Porcentage
Free_Mem_DT REAL Free Memory Data Porcentage
Used_Mem_DT REAL Used Memory IO Porcentage
Total_Mem_DT REAL Total Memory Data Porcentage

Esta UDT agrupa la información de consumo de memoria del PLC (en porcentaje) para
lectura desde el HMI.

5.14.2 RUTINA DiagMain

En esta rutina se encuentra la lógica de incremento secuencial (una variable que se
autoincrementa cada segundo, hasta un valor determinado por el número de pasos
que se programen en la lógica de diagnósticos), y saltos hacia las otras subrutinas del
sistema de diagnósticos.

La lógica de incremento secuencial se presenta en la siguiente figura:

Figura 55 Lógica de incremento secuencial

El tiempo de incremento está determinado por el temporizador del renglón cero, el

cual está configurado con un valor de preselección de 1 segundo. Luego, el bit DONE
de este temporizador se usa para realizar el autoincremento de un tag llamado

Página 68 de 183
 Diag_Step (ess decir, Diag_Step se autoincrementa en una posición cada segundo),
hasta que Diag_Step llegue al valor programado (en la figura, hasta el valor de 22).

El tag Diag_Step es usado posteriormente en la lógica para coordinar la ejecución de

instrucciones GSV V y otro tipo de lógica de diagnósticos (para de esta manera balancear
la carga en la ejecución de este tipo de instrucciones).

El resto de la rutina son los saltos hacia las otras subrutinas del sistema de
diagnósticos:

Figura 56 Saltos hacia otras subrutinas de diagnósticos

5.14.3 RUTINA R00_PowerSupply

Las fuentes de 24 VDC redundantes poseen un cable anunciador (el cual, en
condiciones normales se encuentra cerrado – valor de ‘1’), y cuando alguna fuente falla
se abre (asume el val
valor
or de ‘0’). Esta señal debe ser cableada a un punto de entrada
discreta, y ser copiada a una posición de un tag llamado “Diag_PowerSupply”, el cual
es de tipo DINT.

Figura 57 Señal de fuente de voltaje redundante

En el caso de la figura, solo se tiene una entrada de diagnóstico de fuente, la cual se

está copiando a la posición 0 del tag (Diag_PowerSupply.0). En caso que existan más
señale de diagnóstico de fuentes se deben copiar a posiciones consecutivas de este
mismo tag (Diag_PowerSupply.1,
_PowerSupply.1, Diag_PowerSupply.2, etc).

El tag Diag_PowerSupply es luego revisado por el sistema HMI para generar las
indicaciones correspondientes en pantalla.
5.14.4 RUTINA R01_ProcessMem
Esta rutina es la encargada de recuperar el consumo de memoria del PLC, se hace
durante el paso 0 del ciclo de diagnóstico por medio de una instrucción MSG:

La instrucción MSG se configura con la siguiente información:

Figura 58 Configuración instrucción mensaje - Memoria PLC

Source Element: Diag_Memory_Request_Data[0]\

Destination: Diag_Memory_Temp[0]
Path: 1,0

Esta es una instrucción mensaje genérica para solicitar parámetros a una clase (en este
caso la Clase 72, la cual corresponde al uso de memoria del PLC). Los elementos
solicitados se encuentran definidos en el vector definido en Source Element (en este
caso, el vector Diag_Memory_Request_Data[]), el cual contiene la siguiente
información:
• Diag_Memory_Request_Data[0] = 5 (# de atributos solicitados – 5 atributos)
• Diag_Memory_Request_Data[1] = 0

Página 70 de 183
 • Diag_Memory_Request_Data[2] = 1 (atributo #1 – Memoria Libre)
• Diag_Memory_Request_Data[3
Diag_Memory_Request_Data[3] = 0
• Diag_Memory_Request_Data[4] = 2 (atributo #2 – Memoria Total)
• Diag_Memory_R
Diag_Memory_Request_Data[5] = 0
• Diag_Memory_Request_Data[6] = 5 (atributo #5 – Bloque de Memoria
M Max)
• Diag_Memory_Request_Data[7
Diag_Memory_Request_Data[7] = 0
• Diag_Memory_Request_Data[8] = 6 (atributo #6 – Bloque de Mem IO Max)
• Diag_Memory_Request_Data[9] = 0
• Diag_Memory_Request_Data[
Diag_Memory_Request_Data[10] = 7 (atributo #7 – Bloque de Mem DT Max)
• Diag_Memory_Request_Data[11
Diag_Memory_Request_Data[11] = 0

El resultado de esta consulta se guarda en el vector Diag_Memory_Temp[0],

Diag_Memory_Temp[0] el cual se
convierte a valores en bytes en los renglones siguientes de la rutina. Note que los
valores finales se guardan en el tag Diag_Gen_Data, el cual es un tag creado a partir del
UDT del mismo nombre.

Figura 59 Lógica para acondicionar datos de Memoria Libre

 Figura 60 Lógica para acondicionar datos de Memoria Usada

Figura 61 Lógica para acondicionar datos de Bloques Max Libres

Página 72 de 183
Figura 62 Cálculo de valores totales de Mem DT y IO usadas

Figura 63 Cálculo de porcentaje libre de memoria de I/O

Figura 64 Cálculo de porcentaje libre de memoria de DT

 Figura 65 Cálculos de memoria usada de I/O y DT

Figura 66 Generación de alarmas por consumos altos de memoria de I/O

Figura 67 Generación de alarmas por consumos altos de memoria de DT

Página 74 de 183
5.14.5 RUTINA R02_RedundancyState
En los PLCs redundantes, esta rutina se encarga de recuperar el estado de la
redundancia de procesadores.

Figura 68 Obtención del estado de la redundancia

Los valores de las instrucciones GSV son guardados en los elementos

“RedundancyState” y “PhysicalChassisID” del tag Diag_Gen_Data.

Cuando el PLC no es redundante, debe dejar una instrucción AFI al principio del
renglón,
glón, o eliminar esta rutina.

5.14.6 RUTINA R03_ProcessorInd

Esta rutina recupera dos indicadores del PLC:
• Estado de la batería del PLC (y de la batería del secundario, cuando aplica).
• Estado del led de estado general de IO.

Figura 69 Instrucción para recuperar las fallas menores (estado de la batería)

 En la figura se muestra un PLC que no tiene redundancia, por lo tanto la instrucción
GSV que recupera el estado de la batería del secundario se encuentra deshabilitada por
un AFI. En el caso de los PLCs con redundancia, dicho AFI se debe remover.

Figura 70 Generación de los indicadores de falla de batería y IO Led

Existe otra instrucción GSV cuyo propósito es la obtención del estado del led de estado
del sistema
ema de I/O, la cual devuelve una palabra entera con los siguientes posibles
valores:
• 0 = No hay tarjetas de IO creadas en el I/O Configuration.
• 1 = Ninguno de los módulos de I/O responden.
• 2 = 1 o más módulos de I/O con problemas.
• 3 = Todos los módulos de I/O OK.
Finalmente la rutina genera los bits de alarma de batería, seleccionando los bits
apropiados en la palabra recuperada por la instrucción GSV.

5.14.7 RUTINA R04_LOCAL

Para los sistemas que tienen tarjetas de I/O en el chasis local del procesador, se debe
creare esta rutina para recuperar el estado de los módulos en este chasis.

Al inicio de la rutina se generan 3 pulsos desfasados 1 segundo entre ellos, para

ejecutar las instrucciones GSV que recuperan el estado de los módulos de I/O (se
agrupa la lecturaa de estos módulos en 3 grupos).

Página 76 de 183
 Figura 71 Generación de pulsos para lectura de tarjetas de I/O

Figura 72 Lógica de adquisición de estado de una tarjeta de I/O

Este renglón se encarga de recuperar la palabra EntryStatus de la tarjeta, la cual en

condiciones normales debe tener el cuarto byte con un valor de ‘4’ (16#4xxx). Si esta
palabra se encuentra en un valor diferente, se usan instrucciones GSV para recuperar el
 código de falla. Nótese que los res
resultados
ultados de las instrucciones se guardan en un vector
llamado Diag_LOCAL_IO[x], donde x es el slot correspondiente a la tarjeta.

Esta misma instrucción se debe repetir por cada tarjeta de I/O presente en el chasis,
agrupando las tarjetas de forma uniforme (por ejemplo, si en el chasis existen 9 tarjetas
de I/O, se debe usar ScanPulse1 para leer la información de las 3 primeras, ScanPulse2
para las 3 siguientes, y ScanPulse3 para las 3 finales).

5.14.8 RUTINA RXX_CNETYY

En estas rutinas (RXX_CNETYY) se tiene la ló lógica
gica para recuperar el estado de las
tarjetas Controlnet en chasis local (XX es un número consecutivo para conservar el
orden de las instrucciones, y YY corresponde al slot de la tarjeta).

Figura 73 Recuperación estado tarjeta Controlnet Local

Las primeras dos líneas se encargan de recuperar el estado de la tarjeta Controlnet, y

de generar un bit que indica si la tarjeta se encuentra funcionando correctamente
(Diag_CNETYY.Running).

Posteriormente, con esta indicación, se recup

recupera
era el estado de falla de la tarjeta (si esta
indicación está en cero):

Página 78 de 183
 Figura 74 Recuperación código falla CNET Local

Finalmente, se hace uso de una instrucción MSG para recuperar el estado de los leds de
canal de la tarjeta Controlnet:

Figura 75 Instrucción para leer estado leds de canal Controlnet

La configuración de la instrucción mensaje es como sigue:

 Figura 76 Mensaje para leer leds Controlnet

El tag de destino es Diag_CNET01_ChStatus, de tipo Diag_Code_83. El path de

comunicaciones se debe establecer para que apunte a la tarjeta Controlnet deseada.

Finalmente se recupera la información obtenida por la instrucción mensaje,

moviéndola a los tags que son leídos por el HMI:

Página 80 de 183
 Figura 77 Estado de leds de Controlnet

El estado de los leds de la Controlnet se guardan en una palabra entera con los
siguientes valores posibles:
• 000 = Led OFF
• 001 = Led Verde
• 010 = Led parpadeando verde (OK, recuperando)
• 011 = Led parpadeando rojo (Mal, tratando de recuperar)
• 100 = Led parpadeando rojo/verde (Mala configuración de red)
• 101 = Ambos leds parpadeando rojo alternadamente (errores físicos de red)
• 110 = Ambos leds parpadeando rojo/verde alternadamente (Mala
configuración de red)
• 111 = Rojo estático (tarjeta en falla).

Finalmente se generan las alarmas por tarjeta Controlnet, las cuales son desplegadas
por el HMI:
 Figura 78 Generación alarmas Controlnet

5.14.9 RUTINA RXX_CNETYY_NZZ

En estas rutinas se encuentra la lógica que recupera el estado de falla de los chasis
remotos, los cuales se acceden a través de la tarjeta Controlnet del nodo ZZ, la cual
se encuentra en la red asociada a la tarjeta Controlnet del slot YY. Al igual que en
los casos anteriores, XX es un número consecutivo para conservar el orden de las
instrucciones.

Por ejemplo, para el chasis mostrado en la figura:

Chasis remoto

Figura 79 Ejemplo de I/O Configuration

El chasis
is remoto se encontraría en la rutina RXX_CNET01_N03.

Diag_CNETxx_Nyy_IO[zz]

Slot Tarjeta Madre Nodo del chasis Slot del módulo de I/O
en chasis Principal remoto en el chasis remoto
Página 82 de 183
Lo primero que hace la rutina es evaluar el estado de la tarjeta Controlnet en el
chasis remoto, como se muestra en la siguiente figura:

Figura 80 Revisión estado tarjeta Controlnet remota

Si la tarjeta se encuentra con problemas (.Running = 0) se procede a revisar el

código
igo de falla de la misma:

Figura 81 Revisión falla tarjeta Controlnet remota

Si la tarjeta se encuentra saludable (.Running = 1) se procede a generar los pulsos

para leer las tarjetas de IO remoto:
Figura 82 Generación de pulsos para revisión de tarjetas en chasis remoto

Figura 83 Adquisición de estado tarjeta de I/O slot 1 en chasis remoto

Nótese que el vector de recepción de los datos se llama

Diag_CNETYY_NZZ_IO[slot],
Y_NZZ_IO[slot], el cual es un tag de tipo Diag_IOChasis[17].
Diag_IOChasis[17] Cada
tarjeta guarda sus datos en la posición ‘slot’ que le corresponde (en la figura, se

Página 84 de 183
 muestra la adquisición de datos de la tarjeta de I/O del slot 1). Por ejemplo, en la
siguiente figura se m
muestra
uestra el renglón para la tarjeta del slot 2 del mismo chasis:

Figura 84 Adquisición de estado tarjeta de I/O slot 2 en chasis remoto

Esta misma instrucción se debe repetir por cada tarjeta de I/O presente en el chasis,
agrupando las tarjetas de forma uniforme (por ejemplo, si en el chasis existen 9 tarjetas
de I/O, se debe usar ScanPulse1 para leer la información de las 3 primeras, ScanPulse2
para las 3 siguientes, y ScanPulse3 para las 3 finales).

Esta misma estructura debe repetirse para todas las tarjetas Controlnet y chasis
remotos que maneje el PLC. Por ejemplo, para el I/O Configuration que se muestra en
la figura:

Figura 85 Ejemplo de I/O Configuration

Se tendrían las rutinas:

• R05_CNET01: Para obtener el estado de la tarjeta Controlnet del slot 1
• R06_CNET01_N03: Para el estado de la tarjeta Controlnet del nodo 3 (cuyo
padre es la tarjeta del slot 1).
• R07_CNET01_N04: Para el estado de la tarjeta Controlnet del nodo 4 (cuyo
padre es la tarjeta del slot 1).
 • R07_CNET01_N05: Para el estado de la tarjeta Controlnet del nodo 5 (cuyo
padre es la tarjeta del slot 1).

5.14.10 RUTINA RXX_CheckRemProc

Uno de los objetivos del sistema de diagnósticos es mantener información sobre el
estado de fallas de los PLCs (en caso que un PLC falle, conocer cual es el código y
descripción de la falla). Desafortunadamente, esta es una información que no es
posible obtener programáticamente directamente en el Controlador (al irse a falla,
se detiene la ejecución d de
e la lógica, por lo que cualquier lógica que se programe
para recuperar el estado de falla simplemente no se ejecuta). Debido a esto, se
plantea la solución de realizar un monitoreo cruzado entre los PLCs de la planta, de
forma que cada PLC monitorea el es estado
tado de otro Controlador diferente.

La escogencia del PLC que se va a monitorear, debe ser tal que se minimizen los
efectos de falla de punto común (por ejemplo, que un PLC no monitoree a otro que
funciona en el mismo tablero en donde éste se encuentra). Por ejemplo, el PLC
Gateway (que se encuentra en la subestación 69) monitorea el estado del PLC LTO2
PSS (el cual se encuentra en otra ubicación física distinta).

Para la recuperación del código de falla se usa una instrucción mensaje:

Figura 86 Instrucción de mensaje para recuperar falla de PLC remoto

La configuración de la instrucción es:

Página 86 de 183
 Figura 87 Instrucción mensaje para leer estado PLC remoto

Source Element: Diag_ProcFault_Request_Data[0] – SINT[4]

Destination: Diag_ProcFault_Temp[0] – INT[70]

Se usa un mensaje para recuperar los atributos de la clase 73 (relacionada con el

estado del PLC), y los atributos solicitados se configuran en el tag
Diag_ProcFault_Request_Data:
• Diag_ProcFault_Request_Data [0] = 1 (# de atributos solicitados – 1 atributo)
• Diag_ProcFault_Request_Data [1] = 0
• Diag_ProcFault_Request_Data [2] = 3 (atributo #3 – Estado del PLC)
• Diag_ProcFault_Request_Data [3] = 0

En la pestaña Communication se debe configurar el path de comunicaciones apropiado

para llegar hasta el PLC remoto, por ejemplo:

Path = 1, 2, 2, 10.0.0.155, 1, 0

Se muestra el path en formato numérico, pues es más que probable que no se tenga al
PLC remoto deseado incluido en el I/O Configuration del PLC. En este caso el path
significa:
1, = Bajar al backplane
2, = Ir al slot 2
2, = En el módulo (una tarjeta 1756-ENBT), salir al puerto de comunicaciones
(Ethernet).
10.0.0.155, = En la red Ethernet, buscar el dispositivo que tiene esta dirección.
1, = En el módulo (la tarjeta Ethernet remota), bajar al backplane
0 = Número de slot del PLC remoto
Como puede verse, el path siempre se especifica en parejas (x1,x2,y1,y2,z1,z2), en
donde el primer elemento (x1, y1, z1) es un número que especifica el puerto por el cual
salir:
1 = Bajar al backplane
2 = Salir al puerto de comunicaciones

Y los segundos elementos (x2, y2, z2) corresponden a las direcciones del elemento
destino, y depende de la red de comunicación en la cual se encuentre:
Si es Backplane = Es un número que representa el slot en el backplane.
Si es red Controlnet = Es el número de nodo de la tarjeta destino.
Si es red Ethernet = Es la dirección IP de la tarjeta destino.

Para este tipo de lógica, se deben usar los paths con comunicaciones Ethernet, y solo
pasar por Controlnet en aquellos casos en los que la comunicación Ethernet no sea
posible.

Las siguientes líneas se usan para convertir los valores leídos por la instrucción y
guardarlos en el UDT de tipo Diag_ProcFault correspondiente:

Figura 88 Copia de los valores y fecha/hora de falla de PLC remoto

En este caso, se está realizando el monitoreo de falla del PLC SGPESD, desde la lógica
programa en LTO2 PCS. El tag destino de las operaciones de copia es

Página 88 de 183
Diag_SGPESD_Fault (de tipo de Diag_ProcFault). El objetivo de estas líneas es
mantener los códigos de falla actuales y los de la última falla (para que en caso que se
limpien las fallas del PLC, guardar el último valor registrado). Estos valores son
registrados en el HMI como eventos, de forma que una vez suceda el evento, quede un
registro en el sistema HMI con los códigos de falla y la fecha/hora de ocurrencia.

Finalmente también se realiza la recuperación del estado de operación del PLC (modo
Program, Run o Fault), para también llevar un registro de posibles eventos que puedan
suceder por un PLC que sea movido a modo Program accidentalmente. Se usa una
instrucción mensaje:

Figura 89 Instrucción mensaje para recuperar estado de operación

La configuración de la instrucción se muestra a continuación:

Figura 90 Configuración mensaje recuperación estado de operación

Source Element: Diag_ProcRunProg_Request_Data[0] – SINT[4]

Destination: Diag_ProcRunProg_Temp[0]
rocRunProg_Temp[0] - SINT[8]

Se usa el mismo path de comunicaci

comunicación
ón que el usado para recuperar el estado de falla.

Figura 91 Generación palabra de estado del PLC remoto - parte 1

Página 90 de 183
 Figura 92 Generación palabra de estado del PLC remoto - parte 2

Figura 93 Generación palabra de estado del PLC remoto - parte 3

Las figuras anteriores muestran la generación de la palabra Diag_SGPEDS_State (tipo

DINT) como un número entre 0 y 4 cocon los siguientes significados:
• 0 = Rem Run
• 1 = Rem Prog
• 2 = Key Run
• 3 = Key Prog
• 4 = Faulted

Por último, se guarda una copia del último estado de este indicador (para que en caso
de eventos fortuitos de corta duración, poder mantener el estado en la variable
varia
Diag_SGPEDS_Last_State):
 Figura 94 Copia del último valor de estado registrado

5.15. RECOMENDACIONES SOBRE LA DOCUMENTACION DEL

PROYECTO DE PLC
Una parte importante del proyecto de PLC consiste en la documentación que se debe realizar
en los diferentes componentes que constituyen el programa de PLC. Como puede verse en las
secciones anteriores, los ejemplos mostrados en las figuras incluyen comentarios que permiten
aclarar la funcionalidad de cada segmento de código. Esta sección busca definir las pautas
generales que se deben seguir para realizar la documentación del programa de control.

RSLogix5000 permite el ingreso de comentarios en varios niveles del archivo del PLC, las cuales
deben realizarse en idioma español.

• Propiedades de Controlador: Esta ventana muestra las propiedades generales del

proyecto del PLC, incluyendo una descripción general del proyecto. Ingrese una
descripción que indique la funcionalidad general del proyecto del PLC.

Figura 95 Propiedades del PLC FH82001 y K85101

Las descripciones deben incluir la identificación del proceso, área o máquina que está
controlando.

• Descripciones de tags: Los tags deben incluir descripciones que indiquen claramente la
función y/o equipo específico al cual está relacionado. Para el caso de dispositivos,
basta con crear la descripción para el tag base, ya que las descripciones de los
miembros son heredadas del tipo de dato específico.

Página 92 de 183
Por ejemplo, al crear el tag P77015A usando el tipo de datos AOI_FVNR, solo se debe
definir la descripción para el tag principal (por ejemplo, Bomba de Inyeccion EG - P-
77015A).). Los miembros de este tag usarán la descripción que se ha colocado al tag
principal más la descripción heredada del tipo de datos:

Figura 96 Ejemplo de comentarios en tag tipo AOI_FVNR

Como puede verse en la figura anterior, la descripción se asocia únicamente al tag

principal, de forma que sus miembros usan esta descripción concatenada con la
descripción que se definió para cada miembro en el tipo de datos.

Para el caso de los tags que se crean para operaciones intermedias (booleanos, enteros,
temporizadores, etc) la descripción debe indicar la funcionalidad del tag, y en el caso de
tags booleanos, el signif
significado
icado que tiene un determinado estado, por ejemplo:

Figura 97 Ejemplo de comentario tag intermedio

Figura 98 Ejemplo comentario en Timer

• Descripciones en las Tareas y los Programas: Según las recomendaciones de esta guía,
por lo general solo debe haber una sola tarea principal (MainTask) y dos programas
(MainProgram y Diagnostics). En el caso que se decida crear Tareas o Programas
adicionales, se debe incluir una descripción del propósito de es
esos
os componentes en la
página de propiedades que cada uno posee:

Figura 99 Comentarios en las propiedades de los Programas

• Descripciones de rutinas: En la ventana de configuración de cada rutina es posible

incluir una descripción para detallar la funcionalidad específica de cada una de ellas.
Estas descripciones aparecen en la rutina principal en la sección que realiza los saltos
hacia las otras subrutinas (de esta forma, no es necesario incluir comentarios de renglón
en estos saltos).

Figura 100 Comentarios en rutinas

Página 94 de 183
• Comentarios de renglones: Cada renglón del programa de control debe tener un
comentario describiendo su funcionalidad. Se deben agrupar los renglones que estén
relacionados entre sí, y us
usar
ar unos caracteres especiales para separar conjuntos de
renglones:

Figura 101 Comentarios de renglones

En el caso de la figura anterior, los dos primeros renglones están relacionados con una
válvula FY8301D, y en cada renglón se presenta un comentario explicando la
funcionalidad de cada uno de ellos. Note que el primer renglón del conjunto inicia con
los caracteres ‘/’, de forma que se crea una especie de separación que puede ser
identificada a primera vista. Esta misma separació
separaciónn se realiza en el renglón #2, para
indicar que a partir de ahí inicia la lógica de otro dispositivo distinto.

En el caso que se tengan renglones evaluando condiciones, y generando acciones de

acuerdo al resultado de dichas evaluaciones, se sugiere separa
separarr en la descripción dichas
condiciones de las acciones resultantes. Por ejemplo, en el renglón #1 de la figura
anterior se puede observar que la primera línea de la descripción corresponde a las
condiciones que se están evaluando (“cuando exista una condic condición
ión de flujo Bajo-
Bajo
 Bajo…”) y luego una línea más abajo se coloca las acciones (“ordenar el cierre de la
válvula…”).

• Comentarios en rutinas FBD: En el caso de las rutinas FBD se debe crear un comentario
corto por cada hoja de instrucción FBD que exista en llaa rutina, y adicionalmente se debe
adicionar un elemento “Text Box” por cada instrucción que exista en la hoja FBD. Este
punto se muestra en el siguiente ejemplo:

Descripción de la hoja FBD

Use el pin para “fijar” el text

box a la instrucción principal
(haga click sobre el pin y
arrastre el mouse hacia la
instrucción deseada). Objetos text box: Se añade un
text box por cada instrucción
para ingresar una descripción
por cada una de ellas.

Figura 102 Comentarios en rutinas FBD

• Comentarios en módulos de I/O: No es indispensable crear un comentario por cada

módulo de I/O que exista en el proyecto, pero se debería incluir comentarios en aquellos
módulos que realizan una función especializada (por ejemplejemplo,o, las tarjetas de red
Modbus Prosoft) o aquellas que reúnen un conjunto de otros módulos (por ejemplo, las
tarjetas Controlnet en chasis remoto, por intermedio de las cuales se leen los módulos
de I/O de un chasis completo).

Página 96 de 183
 Módulo

Comentario

Figura 103 Comentarios en módulos

5.16. MANEJO DE FALLAS DEL PLC

Si ocurre una condición de falla de alta severidad el controlador genera lo que se conoce como
una falla mayor, detiene la ejecución de la lógica y conmuta a modo Program.

En algunas ocasiones, es deseable que no todas las posibles fallas mayores que se generan en el
procesador produzcan una parada general del sistema de control, o se puede desear ejecutar
una lógica determinada antes que el procesador detenga la ejecución de la lógica.

Nunca se debe usar la información detallada en esta sección para limpiar continuamente las
fallas del PLC. Las rutinas de falla deben ser selectivas con el tipo de fallas que van a
monitorear y cuáles de ellas puede limpiar.

Ubicación de las rutinas de falla

Una rutina de falla permite la ejecución de lógica para tomar alguna acción específica cuando
ocurre una falla, y pueden ser configuradas a nivel de Programa, Controlador, o en el Manejador
de Energización (Power-Up Handler).

La ubicación de la rutina de falla depende del tipo de falla que se desea capturar:
• Rutina de falla a nivel de programa (Program Fault Routine): En este nivel se deben
colocar la lógica para capturar las fallas producidas por una instrucción (corresponden a
los tipos de falla mayor identificados con el número 4). Por ejemplo, cuando en la lógica
se usa direccionamiento indirecto (se usa el valor de un tag como índice de un vector) un
valor incorrecto en el índice puede provocar una falla mayor tipo 4. Se puede programar
 una rutina a nivel de programa para capturar este tipo de situaciones y evitar que el PLC
se vaya a falla.

Figura 104 Rutina de falla a nivel de Programa

• Rutina de falla a nivel de Controlador (Controller Fault Routine): Las rutinas de falla en
este nivel se recomiendan para capturar fallas relacionadas a:
o Falla de comunicaciones con un módulo de I/O (cuando se configura que la
pérdida de comunicaciones con el módulo produzca una falla mayor),
correspondientes a las fallas tipo 3.
o Falla por tiempo de Watchdog excedido, correspondientes a las fallas tipo 6.
o Fallas relacionadas a equipos de control de movimiento (falla de un eje de
control de movimiento) correspondientes a las fallas tipo 11.

Figura 105 Rutina de falla a nivel de Controlador

• Rutina en el Power-Up Handler: Utilice una rutina de Power-Up Handler para evitar que
el PLC se vaya a modo Falla cuando es energizado en modo Run o Remote Run. Esto
sucede normalmente en un PLC que se encuentra en funcionamiento y se apaga por
una falla en el suministro eléctrico. En el momento en que el PLC se alimenta
nuevamente, entra en modo falla.

Figura 106 Rutina de falla en el Power-Up Handler

Rutina de fallas típicas para la aplicación

Página 98 de 183
Un punto importante a tener en cuenta sobre las rutinas de falla, es que corresponde a lógica
que se ejecuta en un solo scan justo antes que el PLC se vaya a modo falla. Esto quiere decir que
no es posible implementar lógica que dependa de varios scans para completarse (como por
ejemplo, implementar un temporizador que controle algún elemento después de un tiempo de
detectada la falla – el temporizador no trabajará pues solamente va a ser escaneado una vez).

Por defecto la rutina de falla debe ser creada en el Controller Fault Handler, y debe ser usada
para realizar acciones muy puntuales en caso de falla del procesador, como establecer tags de
comunicaciones para notificarles a los otros PLCs del sistema la ocurrencia de la falla (de forma
que estos otros PLCs puedan ejecutar alguna acción de respuesta a ese evento).

Para crear la rutina de manejo de fallas, realice los siguientes pasos:

1. Creación del Programa manejador de error: Haga click con el botón derecho sobre la
carpeta Controller Fault Handler del RSLogix 5000 y seleccione “New Program”

Figura 107 Creación del Programa de Falla

2. Ingrese el nombre “Fault_Handler” como nombre del programa y pulse OK. Ahora
haga click con el botón derecho sobre este programa recién creado y seleccione la
opción “New Routine” e ingreses el nombre el nombre “Fault_Routine” para esta nueva
rutina.

Figura 108 Creación de rutina de manejo de fallas

3. Una vez haya creado la rutina, debe asociarla como rutina principal del programa de
falla (de la misma manera como se hace con las rutinas/programas convencionales.
Para hacerlo haga click con el botón derecho sobre el programa de falla (Fault_Handler)
y seleccione la opción “Properties”. En la ventana que se abre seleccione la pestaña
“Configuration” y seleccione la rutina de falla “Fault_Routine” como rutina principal de
este programa. Para finalizar pulse OK.
 Figura 109 Asignación de rutina de falla

4. Si se requieren más rutinas que deban ser ejecutadas en caso de falla (por ejemplo, para
ofrecer una estructura más organizada de esta lógica) se puede dejar la rutina anterior
como rutina principal, implementando instrucciones de salto (JSR) hacia las otras
rutinas que se creen debajo de este programa.

Recuerde que la función falla segura del sistema se debe lograr por medio de la configuración
del estado de falla de los puntos de salida del PLC (cuando se configuran las tarjetas de salida
en el I/O configuration, al definir el estado de dichas salidas en caso de falla), y no depender
únicamente de la lógica programada en la rutina de fallas.

Por ejemplo, en la siguiente figura se muestra una rutina que establece unos bits de falla para
indicarle a otros PLCs remotos que este Controlador entró en falla, de forma que sea posible
programar lógica en los otros controladores para reaccionar adecuadamente a este evento:

Figura 110 Establecimiento de bits producidos para indicar PLC en falla

Se debe recordar escribir lógica que limpie todas las posibles banderas que se establezcan en la
rutina de fallas, una vez el PLC entre nuevamente en modo RUN. Para ello puede implementar
una rutina de First Scan, como se explica a continuación:

1. Cree una rutina de tipo ladder llamada First_Scan en el programa principal del PLC.

Página 100 de 183

 2. En la rutina principal del programa, coloque en el primer renglón (rung #0) una
instrucción JSR que se ejecute con el primer scan del PLC (por medio de una instrucción
XIC usando la dirección S:FS), como se muestra en la figura:

Figura 111 Rutina de First Scan

3. Dentro de esta rutina implemente la lógica que debe ejecutarse cuando el PLC en modo
RUN, por ejemplo, el reset de las banderas de indicación de PLC en falla:

Figura 112 Borrado de banderas de indicación de PLC en Falla

6 GUIA DE PROGRAMACION HMI

Los principales sistemas HMI (o sistemas de supervisión) usados en las facilidades son Wonderware
Intouch y Factory Talk View de Rockwell. El propósito de esta sección es entregar lineamientos
generales que pueden ser aplicados a ambas plataformas, y presentar el desarrollo básico de un
estándar HMI para Factory Talk View.

6.1 COMPONENTES GENERALES DEL SISTEMA DE SUPERVISION

Un sistema HMI está conformado básicamente por los siguientes componentes:
• Un componente de comunicaciones con los dispositivos en campo (PLCs).
 • Un componente de Supervisión y Control, para presentar por medio de pantallas la
información del proceso y permitirle al operador interactuar con él.
• Un componente de manejo de alarmas, para notificar al operador cuando existan
condiciones por fuera del rango normal de operación.
• Un componente de almacenamiento de datos, para el análisis de los cambios en las
variables seleccionadas en el tiempo.
• Una interfaz de configuración, para poder modificar los componentes mencionados.

SLC 5/05 CPU INPUT INPUT OUTPUT

Logix5550 < > E THE RN ET ControlNET DC INPUT DC INPUT DC INPUT DC OUTPUT DC OUTPUT ANALOG INP UT ANALOG OUTP UT
RUN FOR CE 0 4 8 12 0 4 8 12 0 4 8 12
RUN I/O ST 0 1 2 3 4 5 6 7 ST 0 1 2 3 4 5 6 7 POWER
1 5 9 13 1 5 9 13 1 5 9 13
POWER
Rs2 32
A * 03 ST 0 1 2 3 4 5 6 7
O
K
FLT 0 1 2 3 4 5 6 7
O
K
FLT 0 1 2 3 4 5 6 7
O
K
ST 0 1 2 3 4 5 6 7
O
K
ST 0 1 2 3 4 5 6 7
O
K
CAL
O
K
CA L
O
K
FLT Dh4 85
2 6 10 14 2 6 10 14 2 6 10 14
QUALIT Y
Allen-Bradley ST 89 10 11 12 13 14 15 ST 89 10 11 12 13 14 15 ST 89 10 11 12 13 14 15 S T 8 9 10 11 12 13 14 15 S T 8 9 10 11 12 13 14 15 OK OK
3 7 11 15 3 7 11 15 3 7 11 15
BATT Rs 23 2
BAT OK FLT 89 10 11 12 13 14 15 FLT 89 10 11 12 13 14 15
RXD TXD OK OK RUN REM PROG DC-SIN K DC-SIN K RELAY ANAL OG
IN
ANAL OG
OUT D
C 1 00 10 00 10
D
AT DIANO STI C DIANO STI C C 1 00 10 00 10
R UN REM PR O G 1
( 2 BIT ) 1
( 2 BIT )
O 0
01 11 01 1
02 12 02 12
0 01 1
02 12
01
02
11
12
TO
03 13 03 13
I TO 03 13 03 13
RUN RUN U 3 04
T 0 05 14 04 14 N 3 04 14 04 14
P 15 05 15
06 16 06 16
P 0 05 15
06 16
05
06
15
16
FLT FLT U v 07 17 07 17 U v 07 17 07 17
T T

ALLE N BRADLEY

QU ALIT Y

2
NOT ICE

NOT ICE

NOT ICE

NOT ICE

NOT ICE

NOT ICE

NOT ICE
NO TICE

AT All e n-Bra dl e y
P LC-5/ 80 E

Figura 113 Esquema general del Sistema de Supervisión

Se iniciará la discusión de estos componentes iniciando de abajo hacia arriba, tratando primero
el tema de las comunicaciones entre el HMI y el Sistema de Control.

6.2 SISTEMA DE COMUNICACIONES - ARQUITECTURA

Para la implementación del sistema de comunicaciones, los paquetes HMI ofrecen
generalmente dos opciones:
• Usar un software de comunicaciones desarrollado por el mismo fabricante del HMI: Es
posible que el fabricante del sistema HMI ofrezca componentes de comunicaciones
hacia los PLCs, los cuales tienen la fortaleza de tener una integración nativa con el
sistema, pero pueden no ser óptimos para comunicarse con diferentes marcas de
controladores.

En el caso de Wonderware, estos componentes se llaman I/O drivers y más

recientemente, DAS Servers, y existen diferentes versiones del software de acuerdo a
las marcas de PLC que se desean acceder.

Página 102 de 183

 En el caso de Rockwell el sistema Factory Talk View SE ofrece conexión nativa con los
controladores del mismo fabricante (marca Allen Bradley) a través de un software
llamado RSLinx Enterprise.

• Usar un software de comunicaciones OPC: Normalmente estos sistemas ofrecen la

posibilidad de acceder datos por medio de una tecnología llamada OPC (Ole for Process
Control). Para esto se instala un software de comunicaciones (generalmente creado por
el fabricante del PLC), el cual se comunica con los controladores usando el lenguaje
nativo hablado por ellos. De esta forma, el sistema HMI interactúa con el software de
comunicaciones usando la tecnología OPC.

Para el caso de las facilidades se presentan las siguientes recomendaciones:

Sistemas Wonderware con PLCs Allen Bradley: Se debe usar RSLinx clásico como servidor
OPC y FSGateway (de Wonderware) como cliente OPC del lado del HMI. De esta manera
RSLinx se encarga de comunicarse con los controladores usando el protocolo CIP, y
Wonderware accede a esta información a través de OPC. En la Figura 114 se muestra una
arquitectura de ejemplo usando este esquema. Esta arquitectura tiene las siguientes
características:

• Se hace uso de servidores HMI Wonderware redundantes. En estos computadores la

adquisición de datos se hace a través del FSGateway que se encuentra instalado en
cada uno de ellos. La comunicación con los dispositivos de campo se hace a través de
RsLinx. Esta recuperación de datos la hace solo un servidor al tiempo, en estado normal
el servidor 1 es el único que está recuperando datos de campo a través de RsLinx, pero
al ocurrir una falla en este servidor que no permita la comunicación con campo y
posterior despliegue de la información hacia InTouch, inmediatamente el servidor 2
entra a suplir estas funciones para permitir que la aplicación siga corriendo, incluso sin
llegar a notarse cambio alguno en los clientes.
 Figura 114 Arquitectura Wonderware y PLCs Allen Bradley

Las líneas continuas en la figura anterior representan las conexiones activas (los
caminos por los cuales se mueve la información) mientras que las líneas punteadas
representan los caminos alternos que el sistema usa cuando los componentes primarios
fallan.

• Los clientes usan el FSGateway del servidor activo, de forma que todo el sistema
solamente usa una sola fuente de datos (evitando la sobrecarga de solicitudes en la red
de control). La configuración de este esquema de comunicaciones se detalla en la
sección 6.4.

Al implementar la arquitectura de esta manera, se tienen los siguientes beneficios:

• La configuración de la aplicación HMI para todos los componentes del sistema es única
(no se debe mantener una versión que corra en el servidor, y otra para los clientes). De
esta manera se simplifica el mantenimiento de la misma (se modifica una única
aplicación y se propagan a todos los clientes y servidores).
• Los datos provienen de un servicio que corre de manera independiente a Intouch (el
servicio FSGateway). Esto significa que los clientes pueden adquirir datos sin necesidad
de correr Intouch en los Servidores.

Sistemas Factory Talk View con PLCs Allen Bradley: Para los sistemas Factory Talk View SE
se debe usar RSLinx Enterprise para realizar las comunicaciones entre los Controladores y el
Sistema de Supervisión. Bajo este esquema se tiene la siguiente arquitectura:

• Se tiene un servidor dedicado como el Directorio del sistema Factory Talk (Factory Talk
Directory). La funcionalidad de este equipo es conservar los listados de los proyectos
HMI existentes, y el listado de los equipos en los cuales se encuentra distribuida la

Página 104 de 183

 aplicación. De esta manera solo se debe hacer apuntar los clientes hacia el Directorio
del sistema, y de esta manera cada cliente recupera los parámetros operativos de la
aplicación HMI.

• Se hace uso de servidores HMI Factory Talk View redundantes. En cada uno de estos
servidores se encuentra instalado RSLinx Enterprise, el cual se encarga de realizar la
comunicación entre los controladores y el sistema Factory Talk View. Solo un servidor
HMI y un componente RSLinx Enterprise se encuentra activo en un momento dado.

• Los clientes se comunican con el RSLinx Enterprise de los servidores, de forma que solo
un componente RSLinx Enterprise se encuentra activo al mismo tiempo (evitando la
sobrecarga de solicitudes en la red de control).

• Cuando alguno de los componentes servidor falla (ya sea el servidor HMI o el RSLinx
Enterprise) los clientes conmutan al otro servidor de Standby. Esta arquitectura se
muestra en la siguiente figura:

Directorio HMI Server 1 HMI Server 2

RSLE 1 RSLE 2 Clientes

Figura 115 Arquitectura Rockwell y PLCs Allen Bradley

6.3 ESTRUCTURA DE BASE DE DATOS DE TAGS HMI -

GENERALIDADES
La base de tags es un repositorio en el cual se definen los nombres de las variables de los PLCs
que van a ser usadas por el sistema HMI, por medio de las cuales se realizan las animaciones en
pantallas, se permite el control de dispositivos en campo, se generan las alarmas del sistema y
se realiza la captura de tendencias históricas.
 Aún cuando existen sistemas que pueden acceder directamente a la memoria de los PLCs sin
necesidad de base de datos HMI (Factory Talk View SE, por ejemplo), se decide mantener el uso
de las base de datos de tags por las siguientes razones:
• Uniformidad en las implementaciones, independiente del sistema HMI seleccionado.
• Mantener toda la información de señales de los PLCs concentradas en una única base
de datos, de forma que sea más sencillo ubicar una señal específica y poderla modificar,
sin tener que buscarla por todos los componentes que puedan hacer uso de ella
(pantallas, tendencias,
ndencias, alarmas, etc).
• Ofrecer un mecanismo de poder importar señales usando un formato específico (por
ejemplo, un archivo separado por comas).

Como norma general debe recordar que los nombres usados para los tags de la base de
datos HMI deben correspo
corresponder
nder exactamente con los nombres de los tags en los PLCs,
PLCs
realizando los ajustes que sean necesarios de acuerdo a las limitaciones del sistema HMI.
Por ejemplo, en los PLCs se hace uso de estructuras de datos, los cuales bajo un mismo
nombre agrupan varios miembros distintos como se muestra en la siguiente tabla. En los
sistemas HMI muy posiblemente no sea posible usar la misma sintaxis (tag.miembro), pero
se pueden usar alternativas como jerarquía de carpetas HMI en Factory Talk View SE, o
SuperTags en Wonderware
derware Intouch).

Tag de PLC Tag de HMI

FT8153 FT8153C (carpeta HMI o SuperTag)
SuperTag
FT8153.EuMax FT8153\EuMax
FT8153.EuMin FT8153\EuMin
FT8153.HHAlmLimit FT8153\HHAlmLimit
FT8153.HAlmLimit FT8153\HAlmLimit
FT8153.LAlmLimit FT8153\LAlmLimit
FT8153.LLAlmLimit FT8153\LLAlmLimit
Tabla 4 Tags HMI

En el caso de Factory Talk, la creación de la estructura de carpetas HMI es un proceso

sencillo, siguiendo un procedimiento similar al que se realiza en el explorador de Windows:
En cada
ada carpeta se crean las sub
sub-carpetas
carpetas deseadas, y dentro de ellas los tags requeridos.

Tags HMI

Carpetas HMI

Figura 116 Estructura de carpetas y tags HMI en FT View SE

Página 106 de 183

 Para el caso de Intouch no se manejan carpetas de tags HMI, pero se puede usar el
concepto de “SuperTag” para lograr un efecto de organización similar. La creación de la
plantilla del SuperTag se realiza con la herramienta TemplateMaker de Wonderware. Una
vez se crea la plantilla con los miembros específicos de cada estructura de datos, se puede
proceder a crear tags de HMI de ese tipo de plantilla (ver la siguiente figura).

2. New Template (Transmisor)

1. Add Member (EuMax, EuMin,

HAlmLimit, etc)

TemplateMaker

Al crear el nuevo tag, se puede seleccionar el tipo

“Transmisor” (template creado anteriormente)

Figura 117 Proceso general de creación de un SuperTag en Intouch

6.4 PRIORIZACION DE FRECUENCIAS DE ADQUISICION DE DATOS

Dependiendo del sistema HMI utilizado, existen diferentes alternativas para optimizar el
esquema de comunicaciones por medio de la definición de diferentes frecuencias de
actualización para los valores que se están leyendo desde campo. Para el caso de los sistemas
que manejan comunicaciones por OPC (como la combinación de Intouch y FSGateway que ha
sido propuesta en este documento), la frecuencia de actualización se define por grupos de
datos (por cada Grupo OPC). En el caso de FT View SE, las frecuencias se definen por pantalla.

6.4.1 Sistemas Wonderware con PLCs Allen Bradley:

En este caso se tiene un servidor OPC (RSLinx Classic) el cual se encarga de comunicarse con los
controladores de campo, sirviendo datos hacia un cliente OPC (FSGateway). Dentro del
servidor OPC se definen Tópicos, los cuales son nombres que se asignan a caminos de conexión
hacia determinados PLCs. De esta manera, los clientes pueden acceder a la información de los
PLCs usando el nombre de tópico definido, sin necesidad de conocer los detalles de la ruta de
conexión específica que pueda tener cada controlador. Usualmente se crea un tópico OPC por
cada controlador que se desea comunicar, más sin embargo también es correcto crear varios
tópicos OPC que apunten a un mismo PLC.
En la figura se muestra la ventana de configuración de tópicos OPC de RSLinx Classic:

Configuración de
Tópicos

Tópicos creados

Figura 118 Ventana de configuración de tópicos en RSLinx Classic

En esta ventana existe una pestaña llamada “Data Collection”, y en ella hay un parámetro que
se llama “Polled Messages (mSec)”, la cual tiene por defecto el valor de 1000 mSec. Es
importante recalcar que este parámetro define la frecuencia de actualización del tópico para
clientes DDE, pero no tiene ningún efecto en la definición de las frecuencias de actualización
para clientes OPC.

Como se comentó anteriormente, el cliente OPC para esta arquitectura se llama FSGateway, el
cual funciona como un cliente OPC para RSLinx, e intercambia información con Intouch por
medio del protocolo SuiteLink.

Dentro del cliente OPC se define la siguiente organización:

• Identificación del Servidor OPC: Se debe especificar el tipo, nombre y ubicación del
Servidor OPC.
• Grupo OPC: Es el equivalente a una carpeta en un sistema de archivos. Corresponde a
un contenedor de tags, en el cual se define la tasa de actualización que van a tener
estos datos.

Página 108 de 183

 • Item OPC: Cada ítem corresponde a un tag.

El cliente OPC es el encargado de definir los ítems con los cuales necesita establecer
comunicaciones, y por lo tanto, es el cliente el que define los grupos OPC que van a ser creados
en el servidor. Debido a lo anterior, las frecuencias de actualización de la información la define
el cliente OPC.

No se deben confundir los clientes OPC con los clientes del sistema de supervisión.
Retomando la arquitectura mostrada en la Figura 114 en ella se encuentra que existen dos (2)
clientes OPC, representados por los dos computadores que están corriendo el software
FSGateway (existen cuatro clientes HMI, los cuales reciben la información de FSGateway).

Para los propósitos de esta guía se presentan las siguientes recomendaciones:

• Definición de Tópicos OPC: Se sugiere crear un tópico OPC por cada PLC que exista en
la planta, usando el nombre del PLC como nombre de Tópico. Por ejemplo, si el nombre
asignado al PLC es BOOSTER206B, este mismo nombre debe ser usado para su
correspondiente Tópico OPC.
• Se debe realizar una segmentación de los datos que son leídos del PLC en grupos OPC
actualizados a diferentes velocidades, de acuerdo a la naturaleza de la información y los
requerimientos de la aplicación. Cree al menos un grupo OPC por cada área que posea
la aplicación del PL y divídalos en grupos por cada conjunto de datos que posean
requerimientos similares de velocidad de actualización:
o Grupo OPC para datos booleanos: Por lo general, estos datos corresponden a
disparos, indicadores en campo y banderas que requieren tiempos de
actualización rápidos. Para este tipo de datos se recomienda una tasa de
actualización de 1000 mSec.
o Grupo OPC para datos análogos de cambio rápido: Existen variables de proceso
que presentan cambios rápidos en el tiempo, como flujos y presiones. Se puede
crear un grupo OPC que agrupe este tipo de señales, con un tiempo de
actualización recomendado de 2000 mSec.
o Grupo OPC para datos análogos de cambio lento: Se puede crear este grupo
para aquellas variables que por su naturaleza presentan cambios lentos en el
tiempo, como la mayoría de las temperaturas y los niveles. Se puede configurar
una tasa de actualización de 5000 mSec.
• No se debe limitar la segmentación de los grupos a los criterios definidos
anteriormente, sino que se debe realizar un análisis de los tiempos de actualización de
cada tipo de dato según las necesidades de la aplicación.
• Los tiempos definidos anteriormente son consistentes con una aplicación que usa una
red de comunicaciones rápida como Ethernet o Controlnet, pero pueden no ser
apropiados para sistemas que se comunican sobre redes más lentas (como enlaces
seriales o inalámbricos). Nuevamente se insiste en la necesidad de analizar las
características de la aplicación para definir los grupos OPC requeridos y sus tiempos de
actualización correspondientes.
Para crear la configuración en FSGateway siga los siguientes pasos:
1. Abra el SMC (Archestra System Management Console)
2. Expanda las categorías “DAServer Manager”, “Default Group”, “Local”,
“ArchestrA.FSGateway.1”, “Configuration”

Figura 119 FSGateway en SMC

3. Pulse con click derecho sobre “Configuration” y seleccione “Add OPC Object”. Se
debe adicionar un OPC Object por cada PLC que desee comunicarse (no es
obligatorio, pero es parte de la recomendación de esta guía). Al hacerlo se crea una
entrada
ntrada con el nombre genérico ““New_OPC_000”, ”, renómbrelo con el nombre del
PLC. En la parte derecha aparece la ventana de propiedades del objeto OPC.

OPC Objects

Figura 120 Ventana de configuración de objeto OPC

En el campo “Server Name” use el botón para abrir un diálogo que le muestra los
Servidores OPC disponibles en el equipo. Seleccione “RSLinx OPC Server”.

En la figura anterior puede verse una configuración en la cual se ha creado un objeto

OPC por cada PLC que va a sser usado.

4. Creación de los grupos OPC: Pulse click derecho sobre el nombre del PLC deseado y
seleccione “Add OPCGroup Object” del menú contextual. Al hacerlo se crea una
entrada con el nombre genérico ““New_OPCGroup_000”, ”, renómbrelo con el
nombre de grupo d deseado.
eseado. Por ejemplo, si el PLC PCS_Proc maneja dos áreas
(Amina y DewPoint) se podría crear la estructura mostrada en la siguiente figura:

Página 110 de 183

 Grupos OPC

Figura 121 Grupos OPC de ejemplo

En la parte derecha de la pantalla aparecen los parámetros de configuración del

grupo OPC:

Figura 122 Propiedades Grupo OPC

A continuación se explican cada uno de estos parámetros:
• Device Group Name: Es el nombre completo del grupo OPC (el nombre que
debe ser usado desde Intouch para acceder a los datos representados por
este grupo). Corresponde al nombre del objeto OPC concatenado con el
nombre seleccionado para el grupo (“PCS_Proc” y “_Amina_AI2”).
• Update Rate: Es el tiempo de actualización del grupo OPC en milisegundos.
m
Ingrese el valor escogido para el grupo, teniendo en cuenta los criterios
explicados anteriormente.
• OPC Item ID Prefix: Se puede usar este campo para definir un prefijo que va
a ser aplicado a todos los ítems que van a ser manejados por el grupo.
gru Por
ejemplo, si se trata de un grupo OPC que va a realizar lecturas de Holding
Registers Modbus, podría especificarse en este campo el prefijo “40”. De
esta manera cuando desde Intouch se lea el ítem “001” a través de este
grupo OPC, en realidad se har haráá una solicitud hacia el ítem “40001” al
servidor OPC respectivo. No se recomienda usar este parámetro.
• Use Group Name as Access Path: Utilice esta opción para que FSGateway
use el nombre del Grupo OPC como Access Name para todos los ítems.
Para el caso de esta guía, no debe seleccionar esta opción.
opción
• Read Only: Esta opción hace que los items que se encuentran en este grupo
OPC sean de solo lectura.
 • Browse OPC Items: Este botón sirve para abrir el navegador OPC, por
medio del cual se pueden seleccionar ítems directamente del OPC Server.
Para la implementación discutida en esta guía, no se considera crear ítems
en FSGateway, por lo que esta opción no se usa.

5. Creación de Items OPC: FSGateway ofrece la posibilidad de crear ítems

directamente en cada grupo OPC (ver en la Figura 122 la pestaña “Device Items”),
de forma que se mantiene una base de datos de tags en esta herramienta. Esta
opción no debe ser usada en las aplicaciones de las facilidades. El sistema HMI ya
posee una base de datos de tags, en la cual aquellos que son tags de PLC ya poseen
el direccionamiento necesario para comunicarse con el PLC a través de los grupos
OPC creados. De esta manera, los ítems OPC son creados en FSGateway de manera
dinámica cuando éstos son solicitados por Intouch.

El objetivo de este punto es evitar tener la misma información duplicada en dos

componentes distintos (en este caso, la base de datos de Intouch y FSGateway). La
creación dinámica de ítems no supone un detrimento en el desempeño general del
servidor OPC, y por lo tanto es el esquema recomendado por esta guía.

Una vez finalizados estos pasos, se puede proceder a realizar las configuraciones en
Intouch:
6. Creación de Access Names de Intouch: Se debe crear un Access Name por cada
grupo OPC creado en los pasos anteriores. Los Access Names se usan para
indicarle a cada tag HMI la ruta que debe usar para comunicarse con el PLC.

Figura 123 Creación de Access Names

Los Access Names se crean en Intouch, en el menú “Configure” –> “Access Names”.
En la ventana se muestran los Access Names configurados, para adicionar uno
nuevo se usa el botón “Add…”, con lo que se abre la ventana de configuración del
elemento (como se muestra en la figura anterior).

Página 112 de 183

 Ingrese un nombre para el Access Name, se recomienda usar el mismo nombre
usado en la creación del grupo OPC (por ejemplo, crear el Access Name Amina_AI1
para el grupo OPC Amina_AI1).

En el campo “Node Name” ingrese el nombre del Servidor (o en su defecto su

dirección IP). Esto debe hacerse debido a que esta configuración será copiada a
todos los componentes del sistema HMI (Servidores y Clientes), por lo que es
necesario que todos conozcan la dirección en la cual consultar la información.

“Application Name” debe ser “FSGateway”, corresponde al nombre del

componente cliente OPC.

En “Topic Name” se ingresa el nombre completo del tópico OPC de FSGateway, el

cual está compuesto de la siguiente manera: objeto OPC + _ + grupo OPC. Por
ejemplo, para el caso del grupo “Amina_AI1” creado bajo el objeto OPC “PCS_Proc”
se debe usar “PCS_Proc_Amina_AI1” como nombre de Tópico.

El protocolo debe ser seleccionado como “SuiteLink”. DDE es un protocolo

estándar de Windows, el cual es bastante antiguo y no ofrece el desempeño que se
puede lograr con SuiteLink.

En la sección “When to advise server” se debe seleccionar “Advise only active

ítems”, de forma que solo se realicen requerimientos al servidor OPC de los ítems
que están siendo usados en ese momento (ya sea en pantallas abiertas, alarmas,
tendencias, scripts, etc). No se debe usar la opción de leer todos los ítems, pues
esto afecta negativamente el desempeño de todo el sistema.

La opción “Enable Secondary Source” debe ser usada cuando se tenga un sistema
de servidores redundantes. Al habilitarlo, se despliega el mismo conjunto de
parámetros discutidos anteriormente para el segundo servidor.

7. Direccionamiento del tag: El proceso para comunicar el tag HMI con el PLC a través
del FSGateway consiste en especificar el Access Name correspondiente, y el ítem
usando la nomenclatura adecuada. Por ejemplo, para direccionar el miembro
.Value de un tag HMI de tipo transmisor, la configuración se realizaría como se
muestra:
 Seleccione el Access
Name que corresponde
Ingrese el nombre del
Item OPC

Figura 124 Ejemplo de Configuración de tag HMI en Intouch

El nombre de ítem está conformado por las siguientes partes:

[Tópico OPC]Nombre_Item

Donde “Tópico OPC” corresponde al nombre del tópico creado en RSLinx, y

“Nombre_Item” corresponde al nombre del tag en el PLC. En el caso de la figura
anterior, el nombre de ítem usado es [PCS_Proc]FT8153C.Value.

6.4.2 Sistema Factory Talk View SE con PLCs Allen Bradley:

En los sistemas Factory Talk View SE el servidor de datos es un componente llamado RSLinx
Enterprise, y la tecnología subyacente en las comunicaciones entre este componente y el resto
del sistema HMI se conoce como Factory Talk Live Data.

El sistema soporta servidores RSLinx Enterprise redundantes, los cuales por lo general residen
en los mismos computadores que funcionan como servidores HMI.

De manera similar a RSLinx Classic (el cual tiene tópicos OPC), el sistema RSLinx Enterprise
define los enlaces
ces de comunicaciones con el nombre “shortcut”. Se debe crear un “shortcut” por
cada PLC que se desee comunicar, usando el nombre del PLC como nombre de “shortcut”.

Shortcuts
PLCs

Figura 125 Shortcuts en RSLinx Enterprise

Página 114 de 183

Una vez que se tenga configurado RSLinx Enterprise, se puede acceder a la información de los
PLCs por dos medios:
• Referencias directas en las pantallas: Son llamados tags del servidor de datos, pues se
acceden directamente desde la aplicación a través de RSLinx Enterprise (sin necesidad
de pasar por una base de datos de tags HMI).
• Tags HMI: Corresponden a los tags que se crean en la aplicación HMI y que poseen
algunas características adicionales como escalización de datos, seguridad e
implementación de alarmas.

Como regla general debe usarse tags HMI para:

• Los datos que necesitan ser desplegados en una pantalla parametrizada, como por
ejemplo los faceplates de los lazos de control, de las válvulas, motores y demás
dispositivos.
• Para todos los tags que necesiten generar alarmas en el sistema.
• Para limitar los posibles valores de entrada de un setpoint de operador.

Definición de las frecuencias de actualización

En el caso de Factory Talk View SE, no es posible definir frecuencias de actualización para tags
individuales (ya sean tags HMI o tags de Servidor de datos). Las frecuencias de actualización se
definen de acuerdo a los componentes que hacen uso de los tags:
• Tags en pantallas HMI: Cuando una pantalla HMI se despliega, los tags que existen en
esta pantalla se activan. La frecuencia de actualización de estos tags se configura en la
ventana de propiedades de la pantalla, usando el parámetro “Maximum Tag Update
Rate”.

Tiempo de actualización de tags

Figura 126 Propiedades de la pantalla

Por defecto este parámetro se encuentra configurado a 1 segundo, el cual es un tiempo

apropiado para la mayoría de las pantallas. Sin embargo, la selección de este tiempo
de actualización debe hacerse de acuerdo a las necesidades específicas de cada
pantalla.
 La ventana de propiedades también permite dejar en caché la pantalla, lo cual significa
que la pantalla se mantiene en memoria aún después de haber cerrado la pantalla, y si
se usa la opción de “Always Updating” los tags se mantendrán activos aún después de
haber cerrado la pantalla. Por lo tanto, no se recomienda hacer uso de estas opciones,
salvo en casos muy específicos (alguna pantalla que requiera ser consultada con mucha
frecuencia). El tener mucha
muchass pantallas con estos parámetros habilitados trae como
consecuencia el incremento de la memoria usada por el cliente, y el aumento del flujo
de datos a través del servidor de datos.

• Tags de alarma: La frecuencia de actualización de los tags que pertenecen al sistema de

alarmas se configura en la ventana “Alarm Setup”, la cual se puede acceder a través del
explorador del proyecto de Factory Talk View SE:

Tiempo de actualización de alarmas

Figura 127 Pantalla de configuración g

general de alarmas

Por defecto, el tiempo de actualización de los tags de alarmas es de 2 segundos. Se

recomienda mantener este tiempo en este valor.

• Tags derivados: Si se necesita hacer uso de tags derivados, estos deben estar
organizados en grupos que ttengan
engan necesidades similares de tiempo de actualización.
Para modificar este tiempo, se debe abrir el archivo de tag derivados, y luego usar el
menú Setup
Derived Tag Setup, con lo cual se abre la ventana de configuración
general del tag derivado:

Página 116 de 183

 2. Use el menú Setup para abrir la ventana de
Configuración del tag derivado

1. Abra el archivo de tags derivados

Figura 128 Configuración general de archivo de tags derivados

• Archivos de eventos: Al igual que sucede con los tags derivados, la frecuencia de
actualización este tipo de componentes se configura abriendo el archivo de eventos, y
luego seleccionando Setup
Event Setup.

• Datalog Models: En cada archivo de datalog es posible seleccionar entre 3 diferentes

formas de realizar la adquisición y almacenamiento de los datos históricos, por medio
de la ventana de configuración usando la pestaña “Log Triggers”:
o Periodic: En este caso se define el intervalo en el cual los tags van a ser
actualizados desde el PLC y guardados en la base de datos del Datalog. La
configuración de este tiempo depende del tipo de variable que se esté
historizando, para variables rápidas como flujos y presiones se pueden tener
tiempos de 10 segundos (o menos), mientras que para variables más lentas se
pueden configurar tiempos de adquisición más largos.

Figura 129 Datalog en modo periódico

o On Change: En este modo solo se almacenan datos cuando suceden cambios en

los tags. Obviamente, los tags se deben monitorear a una frecuencia
determinada para poder identificar si el valor del tag a cambiado, esta
 frecuencia se configura en el parámetro “Maximum Update Rate”. En el caso de
la figura, este parámetro está configurado en 1 segundo, lo que significa que
cada segundo este modelo está consultado al servidor de datos por
actualizaciones en los valores de los tags.

Figura 130 Datalog en modo por cambio de valor

o On Demand: Este modo se usa para almacenar datos únicamente cuando se

recibe un comando específico para ello. Al igual que el caso anterior, existe un
parámetro llamado “Maximum Update Rate” que dicta que tan rápido se
consultará al servidor de datos.

6.5 CONFIGURACION DE APLICACIÓN HMI TIPICA EN FT VIEW SE

6.5.1 Seguridad
La aplicación HMI se debe asegurar para evitar que usuarios no autorizados realicen
acciones sobre el proceso. En esta sección se mostrarán los pasos requeridos para crear y
administrar usuarios de Factory Talk, la configuración de seguridad usando usuarios de
Windows no se incluye en este documento. Esto se realiza por medio de la seguridad
integrada de Factory Talk, siguiendo los siguientes pasos:

Aseguramiento inicial del sistema

1. Ingrese al Windows de uno de los computadores que participan en la arquitectura HMI
(por lo general, la estación de ingeniería) usando un usuario que pertenezca al grupo de
administradores de Windows.
2. Abra el Factory Talk View Studio (FTVS) y regístrese en el directorio al cual pertenece la
aplicación HMI.
3. Configuración de la política de seguridad: En el FTVS navegue a la carpeta System,
Policies, System Policies y haga doble click sobre Security Policy para abrir la ventana
de propiedades de la política de seguridad:

Página 118 de 183

 Figura 131 Ventana de propiedades de la política de seguridad

a. En el campo “Account lockout threshold” ingrese un valor de cero (0). Esto se

hace para evitar que las cuentas se bloqueen por intentos fallidos de ingreso al
sistema.

Opcionalmente modifique los siguientes parámetros:

b. Passwords must meet complexity requeriments: Puede habilitar esta opción
para forzar a los usuarios a usar passwords más seguros, de acuerdo a las
siguientes reglas:
i. El password no puede contener la totalidad del nombre de usuario. Por
ejemplo, el usuario Juan12 no puede usar el password Juan1234, pero
12Juan si es permitido.
ii. La longitud mínima del password son 6 caracteres.
iii. Debe contener caracteres de al menos 3 de las siguientes categorías:
• Caracteres en mayúsculas (A – Z)
• Caracteres en minúscula (a – z)
• Números (0 – 9)
• Caracteres no alfanuméricos (¡, @, #, %)

c. Minimum password length: Define la longitud mínima que debe tener el

password. Cuando la opción de complejidad mínima está habilitada, la longitud
mínima es al menos 6 caracteres, o el número definido en este parámetro si es
superior a 6.
d. Previous passwords remembered: Determina el número de passwords que
serán “recordados” por el sistema, para evitar que el usuario los reuse.
e. Minimum password age: Define el número de días que el pasword debe estar en
efecto para permitir cambiarlo. Un valor de cero inhabilita esta opción.
f. Maximum password age: Define el tiempo de expiración del password. Una vez
se cumpla este tiempo el sistema le solicita al usuario cambiar el password. Un
valor de cero indica que el password nunca expira.

4. Creación de usuarios administradores: Se debe crear al menos un usuario administrador

del sistema.
a. En el FTVS navegue a la carpeta System, User and Groups, y haga click con el
botón derecho sobre Users, y seleccione New User. Ingrese la información
 solicitada por la ventana (solo los campos User Name y Password son
mandatorios, sin embargo se sugiere llenar los demás campos con los detalles
de identificación de la persona).

Como regla general evite crear usuarios genéricos (por ejemplo operador1,
gas_operator, etc). Los roles de los usuarios se definirán más adelante por
medio de grupos, por lo tanto es preferible crear un usuario específico por cada
persona que necesite interactuar con el sistema.

En este caso, por ejemplo, se crea el usuario rbecerra, el cual va a ser

adicionado al grupo de administradores de la aplicación.

Figura 132 Ejemplo de creación de usuario

5. Adición del usuario creado en el paso anterior al grupo de administradores: En el FTVS

navegue a la carpeta System, User and Groups, User Groups. Haga click con el botón
derecho sobre el grupo “Administrators” y seleccione “Properties”, con lo cual se abre la
ventana de propiedades del grupo administrador. En esta ventana haga click sobre el
botón “Add…” con lo cual se abre la ventana de selección de usuarios, en donde debe
seleccionar la opción “Show users only”.

Figura 133 Ventana de selección de usuario

Página 120 de 183

 Seleccione las cuentas de usuario a las cuales le quiere asignar privilegios de
administrador y pulse OK. Al hacerlo se cierra la ventana de selección de usuarios, y la
ventana de propiedades del grupo debe mostrar ahora los usuarios que tienen estos
privilegios:

Figura 134 Ventana de propiedades Grupo Administrador

6. Cierre la sesión del usuario actual: En el menú “File” seleccione la opción “Log Off”.
7. Inicie sesión con el usuario administrador que acaba de configurar: En el menú “File”
seleccione la opción “Log On” e ingrese como el usuario administrador que creó en el
paso #4.
8. Restringir el acceso al sistema:
Atención: Antes de realizar este paso confirme que ha creado al menos un usuario
administrador, y que lo adicionó al grupo “Administrators” (no al grupo “Windows
Administrators”). Si no es asi, puede perder acceso al sistema.

Abra la ventana de propiedades del grupo “Administrators”, seleccione “Windows

Administrators” y pulse el botón “Remove”.

Figura 135 Remover "Windows Administrators" del grupo administrador

 En el FTVS navegue a la carpeta System, Users and Groups, User Groups. Haga click
con el botón derecho sobre “Windows Administrators” y seleccione la opción “Delete”
del menú contextual que aparece.

Figura 136 Eliminación del grupo "Windows Administrators"

Al remover el grupo “Windows Administrators” del sistema se previene que cualquier

persona que haya iniciado sesión en Windows con privilegios de administrador pueda
tener los mismos privilegios en el sistema Factory Talk.

9. Restringir el acceso a todos los usuarios:

En la parte superior izquierda de la ventana del FTVS haga click derecho sobre
“Network” y seleccione la opción “Security” en el menú contextual que aparece.

Figura 137 Opción de seguridad del directorio

En la pestaña “Permissions” seleccione “All Users”, y en la parte inferior en el campo

“All Actions” limpie los cuadros de selección “Allow” y “Deny”. Finalmente expanda el
grupo de acciones “Common” y marque los cuadros de selección “Allow” en las
entradas “List Children” y “Read”.

Página 122 de 183

 Figura 138 Restricción de acciones a todos los usuarios

Este paso se realiza para permitir que cualquier usuario no autenticado (“All Users”)
pueda únicamente ver el árbol general del proyecto, pero no realizar ninguna acción de
configuración y/o operación sobre el sistema.

Creación de cuentas de usuario y grupos

Las cuentas de usuario permiten realizar el control de las personas que puedan acceder
al sistema y que acciones puede realizar.

El sistema Factory Talk permite crear dos tipos diferentes de cuentas de usuario:
Usuarios de Factory Talk y Cuentas de Usuario vinculadas a cuentas de Windows. Para
el alcance de este documento, se realiza el proceso de creación de Usuarios de Factory
Talk.

1. Creación de usuarios: En FTVS navegue a System, Users and Groups, y haga click con el
botón derecho sobre “Users”. Seleccione la opción “New User” en el menú contextual
que aparece.
2. Ingrese los datos del usuario (Nombre de usuario, Nombre completo, descripción del
usuario y password) y seleccione la opción “User must change password at next logon”
(de esta manera, se asigna un password genérico al usuario pero se forza al usuario a
cambiarlo la primera vez que se autentique en el sistema).
 Figura 139 Creación de un usuario

Pulse OK para crear el usuario.

3. Repita el paso anterior por cada uno de los usuarios que va hacer uso del sistema, sin
importar el rol que desempeñe (operador, supervisor, administrador, etc).
4. Creación del usuario Invitado: Se debe crear un usuario el cual solo va a tener privilegios
para visualizar las pantallas de la aplicación, pero no va a poder realizar ninguna acción
de control. Este usuario será usado para mantener activo el cliente HMI cuando no haya
ninguna persona usando el sistema. Este usuario debe ser creado con el nombre
“Invitado”, y se deben habilitar las opciones “User cannot change password” y
“Password never expires”. El password de esta cuenta debe ser “invitado”.

Figura 140 Creación del usuario Invitado

5. Creación de grupos de usuarios: Los grupos de usuario sirven para definir un conjunto
de reglas (permisos) que son comunes a varios usuarios. En el caso del sistema HMI
discutido en este documento, se deben manejar tres grupos:
• Administrators: Es el grupo de administradores de FT View que el sistema trae
por defecto.
• Operadores: Corresponde al grupo del personal de operación del sistema HMI.
• Supervisores: Corresponde al grupo de supervisores de area/turno.

Página 124 de 183

 Creación del grupo Operadores: En FTVS navegue hasta System, Users and Groups, y
haga click derecho sobre “User Groups”. Seleccione la opción “New User Group”.
Ingrese el nombre del grupo (Operadores), la descripción del grupo (Grupo de
Operadores) y adicione los usuarios que pertenecen a este grupo por medio del botón
“Add…”.

Figura 141 Creación de grupo de usuarios

Repita este paso para crear el grupo “Supervisores”, y adicione los usuarios que
pertenecen a este grupo.

Configuración de los códigos de seguridad y asignación a Grupos de Usuario

Una vez se hayan creado los usuarios y sus grupos se deben adicionar al listado de
cuentas de seguridad en el editor de seguridad Runtime (Runtime Security Editor). Al
adicionar las cuentas en este editor, se seleccionan los códigos de seguridad asociados
a cada grupo/usuario. Estos códigos son letras de la A a la P, los cuales se asignan a
componentes específicos del sistema HMI (comando, macro, pantalla, tag HMI, etc),
con lo cual queda determinado que componentes son accesibles por determinados
grupos y/o usuarios.

Para el caso de esta guía, se han definido los siguientes códigos:

• Usuario Invitado: Acceso a códigos A

• Grupo Operadores: Acceso a códigos A, B, C y D
• Grupo Supervisores: Acceso a códigos A, B, C, D, E, F y G
• Grupo Administrators: Acceso a todos los códigos

Esto significa que el código A es usado para todos los componentes que pueden ser
usados por cualquier tipo de usuario (por ejemplo, todas las pantallas por lo general
tendrán código A, para permitir que cualquier usuario pueda navegar por ellas, pero el
control de arranque de un motor tendrá código B para permitir que solo usuarios
autorizados puedan realizar esta acción).
 Para realizar esta configuración, abra el menú “Settings” en el Factory Talk View, y
seleccione la opción “Runtime Security”.

Figura 142 Ventana Runtime Security

Pulse en el botón “Security Accounts…” que se muestra en la Figura 142, con lo cual se
abre la ventana de configuración de seguridad para la aplicación. En esta ventana se
van a adicionar los grupos/usuarios y los respectivos códigos que van a manejar.

1. Por defecto el sistema habilita a todos los usuarios a acceder y manipular la aplicación
HMI, para eliminar esta característica seleccione “All Users” en la ventana de
configuración y pulse el botón “Remove”.

Figura 143 Remoción de "All Users" en la configuración de seguridad

2. Ahora, pulse sobre el botón “Add…” y en la ventana que se abre seleccione la opción
“Show users only” en el filtro, con lo cual se deben desplegar los usuarios configurados
en el sistema. Seleccione el usuario “Invitado” y pulse OK.

Página 126 de 183

 Figura 144 Adición del usuario "Invitado"

Al hacerlo se muestra el usuario en la ventana de configuración de seguridad, con todos

los códigos habilitados (en el área All Actions). Expanda la categoría “FactoryTalk View
Security Codes” para ver los códigos de seguridad.

Pulse sobre el cuadro “Allow” que se encuentra en frente de “FactoryTalk View Security
Codes” para limpiar todos los cuadros correspondientes a los códigos, y posteriormente
habilite el cuadro “Allow” de únicamente el código A. Pulse OK para finalizar la adición
de este usuario, con lo cual debe queda en la ventana de configuración de seguridad
para la aplicación (Figura 143).

Primero pulse aquí para

limpiar todos los códigos Luego seleccione
únicamente el código A

Figura 145 Habilitación de código A para usuario Invitado

Normalmente este proceso se realiza sobre grupos de usuario, en vez de usuarios

individuales.
3. Adición del grupo Operadores: Nuevamente pulse el botón “Add…” y en la ventana que
se abre seleccione la opción “Show groups only” en el filtro, con lo cual se deben
desplegar los grupos de usuarios configurados en el sistema. Seleccione el grupo
“Operadores” y pulse OK.

Al hacerlo se muestra el grupo en la ventana de configuración de seguridad, con todos

los códigos habilitados (en el área All Actions). Expanda la categoría “FactoryTalk View
Security Codes” para ver los códigos de seguridad.

Al igual que en el caso anterior, pulse sobre el cuadro “Allow” que se encuentra en
frente de “FactoryTalk View Security Codes” para limpiar todos los cuadros
correspondientes a los códigos, y posteriormente habilite el cuadro “Allow” de los
códigos A, B, C y D. Pulse OK para finalizar la adición de este grupo, con lo cual debe
queda en la ventana de configuración de seguridad para la aplicación (Figura 143).

4. Adición del grupo Supervisores: Siga el mismo procedimiento desarrollado en el punto

anterior, pero dejando habilitados los códigos A, B, C, D, E, F y G. Pulse OK para
finalizar la adición de este grupo, con lo cual debe queda en la ventana de configuración
de seguridad para la aplicación (Figura 143).

5. Adición del grupo Administrators: Finalmente siga el mismo procedimiento

desarrollado anteriormente, pero dejando habilitados todos los códigos de seguridad.
Pulse OK para finalizar la adición de este grupo, con lo cual debe queda en la ventana de
configuración de seguridad para la aplicación (Figura 143). Cierre esta ventana por
medio del botón “Close”.

En las secciones siguientes se hará referencia a estos códigos configurados, para

determinar que componentes del sistema HMI pueden ser manipulados por
determinados usuarios.

6.5.2 Sistema de alarmas

El sistema de alarmas de la aplicación se maneja por medio de la base de datos de tags HMI
de Factory Talk View SE, en el cual se pueden crear alarmas de tipo digital y análogo. Para
el caso de esta implementación, todas las alarmas que se van a manejar en el sistema son
digitales, ya que las alarmas correspondientes a valores análogos se evalúan en el PLC y se
registran en el sistema HMI como alarmas digitales.

Al abrir la base de datos de tags y definir un tag como alarma, se encuentra una ventana
como la que se muestra:

Página 128 de 183

 Figura 146 Ventana de configuración de alarma

En esta ventana se pueden apreciar los principales parámetros que deben definirse para una
alarma:
• Alarm Type (Tipo de alarma): Define el valor que debe asumir el tag para que el
sistema lo identifique como una alarma, y puede configurarse con las siguientes
opciones:
o On: Alarma mientras el tag se encuentre en ‘1’.
o Off: Alarma mientras el tag se encuentre el ‘0’
o Any Change: Se genera alarma cada vez que el tag cambie de valor.
o Changes to On: Se genera una alarma ante la transición del tag a ‘1’.
o Changes to Off: Se genera una alarma ante la transición del tag a ‘0’.

La diferencia entre “On” y “Changes to On” (y “Off” y “Changes to Off”) radica en

que en las primeras la condición de alarma se genera y se mantiene mientras el tag
conserve el valor (por ejemplo, una alarma “On” se genera cuando el tag asume el
valor de ‘1’, y se mantiene mientras el tag conserve este valor). Las alarmas “Change
to On” se generan cuando el tag asume el valor de ‘1’, pero no se mantienen (una
vez que el operador reconozca alarmas, esta alarma desaparece).

Por lo general, las alarmas manejadas en este sistema deben ser de tipo “On”.

• Alarm Label (Etiqueta de alarma): Es el texto que se encuentra asociado a la alarma,

y que aparece en el resumen de alarmas (y en el registro de eventos del sistema)
cuando se generan las alarmas. Es un texto corto que debe comunicar rápidamente
el significado de la alarma. Los alarm labels definidos para la aplicación son:
o HIGH, HIGH HIGH, LOW, LOW LOW: Usados para indicar el nivel de alarma
de un transmisor, o la condición de alarma de un Switch.
o FAULT: Indica una falla de un transmisor o de un motor.
o FTC: Fail-To-Close – Falla al cerrar, se produce en las válvulas que poseen
switchs de final de carrera cuando se ordena cerrar la válvula y no se recibe
la señal de confirmación de cierre después de un tiempo determinado.
 o FTO: Fail-To-Open – Falla al abrir, se produce en las válvulas que poseen
switchs de final de carrera cuando se ordena abrir la válvula y no se recibe la
señal de confirmación de apertura después de un tiempo determinado.
o FTStart: Fail-To-Start – Falla al arrancar, ocurre en los motores cuando se
ordena arrancar el motor y no se recibe confirmación de contactor cerrado
después de un tiempo determinado.
o FTStop: Fail-To_Stop – Falla al parar, ocurre en los motores cuando se
ordena detener un motor y se sigue recibiendo la señal de confirmación del
contactor después de un tiempo determinado.

• Severity (Severidad): En un número que indica la severidad de la alarma, en la cual

un número pequeño es más severo que un número grande. Para la aplicación se
manejan 3 niveles de severidad relacionadas con alarmas, y un nivel de severidad
que se utiliza para identificar eventos.
o Nivel 1: Son las alarmas relacionadas con una parada general, corresponde
al mayor nivel de severidad. Estas alarmas se identifican de color rojo en los
resúmenes de alarma.
o Nivel 2: Son las alarmas relacionadas con paradas sin despresurización, y se
identifican de color naranja.
o Nivel 3: Son las alarmas relacionadas a paradas de máquinas, y se
identifican de color amarillo.
o Nivel 8: Usado para identificar eventos de falla del sistema de control (no
aparecen en los resúmenes de alarma del operador, solo en el sistema de
diagnóstico del sistema de control).

En la sección correspondiente a cada tipo de dispositivo se presentan las configuraciones de

los tags de alarma que corresponde a cada uno de ellos, y ejemplos de la forma como esas
alarmas se visualizan en el sistema. El alarm summary debe conservar el mismo manejo de
colores, como se muestra en los siguientes ejemplos:

Figura 147 Resumen de alarmas - Alarma Severidad 3

En la figura anterior puede verse un transmisor cuya alarma por valor alto se ha configurado
con severidad #3, lo cual se indica gráficamente por el color amarillo que se muestra en el

Página 130 de 183

resumen de alarmas, en el cuadro del transmisor en pantalla y en la indicación de alarma
reciente de la barra de navegación. Los registros de color morado en la figura corresponden
a alarmas que han sido reconocidas pero que todavía se encuentran activas.

Figura 148 Resumen de alarmas - Alarma Severidad 2

En el caso de la figura anterior, el flujo siguió subiendo en el transmisor, hasta generar la

alarma por valor Alto Alto, la cual fue configurada con severidad #2 en la base de datos. Por
lo tanto, todos los indicadores de pantalla muestran esta alarma de color naranja. Lo mismo
ocurre con las alarmas de severidad #1, las cuales producirán que los indicadores en
pantalla se animen de color rojo.

6.5.3 Implementación del sistema de tendencias

El sistema Factory Talk permite el manejo de dos tipos principales de tendencias:
Tendencias en tiempo real y tendencias históricas. Las tendencias en tiempo real consisten
en los gráficos que muestran el comportamiento de una señal en el tiempo, pero en el cual
no se guarda ninguna historia (cuando el operador abre la pantalla de tendencia, esta se
muestra vacía, y comienza a mostrar el gráfico del comportamiento de la señal
monitoreada mientras la pantalla se mantenga abierta).
Las tendencias históricas se grafican a partir de información histórica que ha sido guardada
en una base de datos. Para ello se debe hacer uso de unos componentes llamados “Datalog
Models”, los cuales deben seguir las siguientes reglas generales de configuración:

1. Creación de los Data Log Models: Se debe crear un modelo por cada conjunto de tags
que posean unas necesidades similares de velocidad de adquisición de datos, y
agrupados en las áreas principales que maneja la aplicación. Para crear un Data Log se
hace click con el botón derecho sobre “Data Log Models” y se selecciona la opción New,
como se muestra en la figura:
 Figura 149 Creación de Data Log

Por ejemplo, las señales de flujo presentan una variación más rápida en el tiempo que
las señales de temperatura, por lo tanto se deberá crear un modelo para manejar los
flujos (con una velocidad de adquisición rápida, por ejemplo, 10 segundos) y otro
modelo para manejar las temperaturas (con una frecuencia más lenta, por ejemplo, 30
segundos).

2. La ventana de configuración del modelo tiene varias pestañas, en la figura anterior se

muestra la pestaña inicial en la cual básicamente se ingresa una descripción para el
modelo, y se especifica que se va a manejar la base de datos interna de Factory Talk
View (existe la opción de enviar la información a una base de datos por medio de ODBC,
pero esa opción no será discutida en este documento). Seleccione la pestaña “Paths”
para definir la ubicación de los archivos del modelo:

Figura 150 Configuración del directorio del modelo

Por defecto al crear un nuevo modelo, este se configura para crear archivos en la
carpeta del proyecto HMI del Servidor. En el caso de este documento, los servidores
HMI deben tener una partición independiente para el almacenamiento de tendencias
(de forma que los archivos de los modelos Data Log no vayan a generar una situación
de poco espacio en el disco duro principal de un servidor). Por lo tanto, lo primero que
debe hacerse el seleccionar la opción “Absolute Path” e ingresar la carpeta en la cual
serán guardados los archivos del Data Log, la cual debe estar en una partición diferente
a la partición del Sistema Operativo (por ejemplo, en D:\Datalogs).

Página 132 de 183

3. En la pestaña “File Management” se debe configurar la política de creación de nuevos
archivos del Data Log:

Figura 151 Política de creación de nuevos archivos del Data Log

En esta sección se deben usar los siguientes valores:

• Start New Files: Periodic, y seleccionar la opción Daily. De esta manera se
creará un archivo por cada día, lo cual crea muchos menos archivos que la
opción “Hourly” (cada hora), y el tamaño de los archivos es adecuado.
• Se debe seleccionar la opción “After Maximum Time: 6 Months” en el campo
“Delete Oldest Files”. De esta manera el sistema guardará una historia de los
últimos 6 meses.

4. Pestaña “Log Triggers”: En esta pestaña se definen los eventos que producirán que se
guarden datos en el modelo, y existen tres opciones:
• Periodic: Es la opción por defecto que debe ser usada en la mayoría de los
casos, en la cual el sistema guarda los valores de los tags que pertenecen al
modelo de manera periódica, en el lapso de tiempo especificado en el campo
“Interval”.

Figura 152 Registro periódico de datos en el Data Log

• On Change: Esta opción se usa para que los datos sean guardados cuando
presenten un cambio igual o superior al porcentaje de cambio definido en la
ventana:
 Figura 153 Registro por cambio en el Data Log

En este caso el parámetro “Maximum Update Rate” define la máxima

frecuencia efectiva a la cual se van a guardar los datos, y sirve para evitar
saturar los archivos del modelo cuando algún tag presenta variaciones
mayores al porcentaje definido de una forma muy rápida.

El parámetro “Change Percentage” corresponde al porcentaje de variación que

se debe presentar en el tag que pertenece al modelo para que el sistema
guarde su valor en el registro histórico.

Finalmente, el parámetro “Heartbeat” define el tiempo en el cual el sistema

guarda los valores de los tags cuando estos no cambian. Un valor de cero
inhabilita esta característica.

• Finalmente, existe la opción “On Demand”, en la cual la información histórica

se guarda únicamente cuando se recibe un comando desde el HMI. Esta opción
no se contempla en este documento.

5. Pestaña “Tags in Model”: En esta pestaña se definen los tags que serán monitoreados y
guardados por este modelo. Contiene dos cuadros de texto, el cuadro superior sirve
para adicionar nuevos tags al modelo, mientras que el cuadro de texto inferior muestra
el listado de los tags que pertenecen al modelo.

Figura 154 Ventana de tags que pertenecen al modelo

Página 134 de 183

6. Al pulsar OK se finaliza la creación del modelo, con lo cual el sistema le solicitará que
ingrese un nombre para ese componente. Use un nombre que contenga el nombre del
área al cual pertenece los tags adicionados, y el tipo de variable registrada (por
ejemplo, Area1_Temperaturas).

6.5.4 Resolución típica de la aplicación

La aplicación debe ser creada usando una resolución de 1280 x 1024 pixeles. Los elementos
descritos en esta sección se encuentran dimensionados teniendo en cuenta esta resolución.

6.5.5 Color de fondo de las pantallas

El color típico de fondo de las pantallas debe ser verde aguamarina, el cual se configura en
las propiedades de la pantalla como se muestra en la figura (el color se muestra encerrado
en un círculo de color rojo):

Figura 155 Selección de color de fondo en pantallas

6.5.6 Distribución de los elementos en pantalla

El sistema se conforma básicamente de tres áreas en la pantalla, las cuales son:
Barra de Navegación
Es una ventana que siempre se encuentra en la parte superior de la pantalla, y que
presenta controles que son comunes a to
todas las pantallas:

Fecha y Hora Título de la ventana actual

Estado general de la red de Control

Usuario actual registrado en el sistema

Botones de navegación

Figura 156 Barra de Navegación

Los elementos de esta pantalla (mostrada en la Figura 156) son:

o Fecha y hora actual.
o Titulo de la ventana actual: Es un texto que se anima dinámicamente de
acuerdo a la ventana desplegada actualmente.
o Estado general de la red de control: Es un recuadro que indica por medio de
colores el estado general del sistema de control. En condiciones normales
se mantiene gris, en caso de una falla crítica del sistema se coloca de color
rojo, y en el caso de una alarma se coloca de color amarillo.
o Usuario actual registrado en el sistema: En este recuadro se muestra el
usuario registrado actualmente en el sistema. Pulsando este recuadro se
abre la pantalla de cambio de usuario (Logi
(Login/Logout).
o Botones de navegación: Controles para poder abrir otras pantallas. pantallas
Normalmente se coloca en esta barra botones para abrir pantallas
principales (desde las cuales se pueden acceder a otras pantallas). El
espacio reservado para esta funcionalidad permite la creación hasta de 4
botones de este tipo, sin embargo, se puede hacer uso de ventanas de
popup para permitir mostrar más botones (en la figura se muestra un
recuadro que aparece al pulsar el botón “Grupo Pantallas”, por medio del
cual se pueden abrir otras pantallas). De esta forma se puede crear un
botón por cada área principal que se tenga, y por debajo de él adicionar los
botones de las pantallas de cada área.
o Indicación de la alarma más re reciente:
ciente: En este recuadro se muestra la alarma
más reciente
ente registrada por el sistema de control. Al pulsar sobre este
elemento se abre la ventana de resúmen de alarmas.
o Botón de reconocimiento de alarmas: Por medio de este botón el operador
puede reconocer todas las alarmas activas del sistema. Se encuentra
deshabilitado
eshabilitado cuando no hay un usuario autenticado en el sistema (usuario
Invitado).

Página 136 de 183

 El objetivo de la Barra de Navegación es mantener una única pantalla con los
elementos que son comunes a todas las pantallas, de forma que no sea necesario
replicar la misma información en cada pantalla de proceso.

Como tal, esta pantalla debe ser configurada con los siguientes parámetros:
o Tipo: On Top
o Size: 1280 x 100
o Allow Display to be Resized: NO
o Position: x:0; y:0
o Size to Main Window at Runtime: NO
o Todos los demás valores por defecto.
o El objeto de texto para el título (el cual muestra el texto “Pantalla 1” en la
figura anterior), se debe nombrar como “txtTitle” en su cuadro de
propiedades, y se debe seleccionar “VBA Control” en el campo
“ExposeToVBA”.

Configuración de seguridad
La barra de Navegación debe dejarse sin código de seguridad (Security Code = *) de
forma que todos los usuarios puedan navegar por la aplicación.

El único control de esta pantalla que debe manejar seguridad es el botón de

reconocimiento de alarmas (botón “ACK”), pues solamente los operadores o
perfiles de más alto privilegio pueden realizar esta acción. Sin embargo, la
validación de seguridad no se realiza en el botón, sino que se prefiere asegurar los
comandos de reconocimiento (de esta manera los comandos de reconocimiento de
alarma quedan asegurados sin importar en que parte del sistema sean usados).

Para asegurar los comandos de reconocimiento siga los siguientes pasos:

1. Abra la aplicación HMI en Factory Talk View Studio (FTVS) y seleccione la opción
“Runtime Secured Commands…” en el menú “Settings”.

2. En la ventana que se abre (“Secured Commands”) se encuentra una matriz que en la

posición #1 tiene la entrada “UNSPECIFIED_COMMAND” la cual no se puede
eliminar y corresponde al nivel de seguridad de cualquier otro comando que no sea
especificado en esa lista. El código de seguridad para esta entrada se deja por
defecto en (*).

3. Seleccione la siguiente posición libre de la matriz (si no la ha modificado todavía,

debe ser la posición #2) e ingrese el comando “ACKNOWLEDGE” en el campo
“Command:”, y seleccione el código de seguridad “B” en el campo “Security Code:”
Finalmente pulse el botón “Accept” para guardar esa entrada.

4. Repita el paso anterior para asegurar el comando “ACKNOWLEDGEALL”, también

con código de seguridad “B”. Al finalizar estos pasos la ventana debe aparecer
como se muestra a continuación:
 Figura 157 Adición de seguridad a comandos

De esta manera quedan asegurados los comandos de reconocimiento de alarma, si

en el sistema no se encuentra autenticado un usuario con permisos, el comando no
será efectivo, y se registrarán estos intentos inválidos en la barra de estado y log del
sistema:

Figura 158 Registro de acceso no autorizado

Pantalla de proceso
Corresponde a cada una de las pantallas que conforman el sistema de supervisión, y en
su gran mayoría corresponden a representaciones de áreas de la planta. En la siguiente
figura se muestra la pantalla completa:

Página 138 de 183

 Barra de
Navegación

Pantalla de
proceso

Barra de estado
de FTV

Figura 159 Ejemplo de pantalla completa

Los parámetros de configuración de este tipo de pantallas son:

o Tipo: Replace
o Size: 1280 x 884
o Allow Display to be Resized: NO
o Position: x:0; y:100
o Size to Main Window at Runtime: NO
o Todos los demás valores por defecto.

Se debe escribir un script en cada una de estas pantallas para modificar el cuadro de
texto de la barra de navegación cuando la pantalla es abierta. Para hacerlo pulse sobre
un área despejada de la ventana y seleccione “VBA Code…” en el cuadro de diálogo que
aparece, con lo cual debe abrirse el editor de VBA. Seleccione el evento
“AnimationStart” del objeto “Display”, e ingrese el siguiente código:

LoadedDisplays(“BarraNavegacion”).txtTitle.Caption = “Nombre de la pantalla”

Cambie “Nombre de la pantalla” por el título que desea usar para esta pantalla (por
ejemplo, “Unidad Turboexpander #1”). El editor de VBA se muestra en la siguiente
figura:
 2. Seleccione “Display” en el primer combo, y “AnimationStart” en el segundo

1. Verifique que se encuentra en la pantalla deseada, y en el objeto ThisDisplay

Figura 160 Editor de VBA

De esta manera cada vez que cambie de pantalla este código se encargará de colocar el
título en el control correspondiente en la barra de navegación.

Barra de estado de Factory Talk View

Barra de Estado de Factory Talk View: Para que el cliente muestre la barra de estado de
Factory Talk View SE, solo basta con seleccionar que se muestre este elemento en el
cuadro de configuración del cliente usando la opción “Display diagnostic list”.

Ventana emergente de cuentas de usuario

Como se mencionó anteriormente en la descripción de la barra de navegación, existe un
área en la parte superior derecha de la misma que muestra el nombre del usuario
actualmente registrado en el sistema. Al hacer click sobre esta área se abre la ventana
emergente de cuentas de usuario, la cual presenta la siguiente
información/funcionalidad:
• Nombre del usuario actualmente registrado
• Botón para ingresar otro nombre de usuario: Al pulsarlo aparece la ventana de
ingreso de usuario de Factory Talk.
• Botón para cambiar contraseña: Por medio de este control se abre la ventana
de cambio de contraseña de usuario de Factory Talk.
• Botón para desconectar al usuario actual (realizar Log Off): Por medio de este
botón se ingresa al sistema como usuario “Invitado”, el cual solo tiene permisos
para navegar por las pantallas de la aplicación.
• Botón para cerrar la ventana emergente

Página 140 de 183

 Figura 161 Ventana de cuentas de usuario

Sobre el usuario Invitado: Factory Talk crea el usuario “Anonymous Logon” durante la
instalación del sistema, y lo usa para efectos de configuración. Sin embargo, una vez el
sistema se encuentra instalado y funcionando, este usuario no cumple ninguna función
(no puede ser usado por ejemplo como un usuario sin privilegios para navegar por la
aplicación). El usar la función LogOff de Factory Talk produce que el cliente HMI se
cierre, permitiendo su apertura únicamente cuando se registra un nuevo usuario. Por lo
tanto, para permitir mantener abierta la aplicación HMI cliente con un usuario sin
permisos, se crea el usuario “Invitado”.

6.5.7 Organización de la base de datos de tags

La Base de datos de los tags HMI está por carpetas HMI, en donde el primer nivel
corresponde a carpetas que representan los PLCs del sistema, y dentro de estas, cada
dispositivo (motor, válvula, transmisor, etc) tiene una carpeta que contiene todos los tags
relacionados a cada uno de ellos. De esta manera se obtiene una distribución organizada,
bastante similar a las estructuras de datos creadas en los PLCs. En la siguiente figura se
muestra un ejemplo de esta base de datos de tags:
 Figura 162 Distribución base de datos de tags

En la figura puede apreciarse la carpeta SGPPCS, en la cual se encuentran todos los

elementos relacionados con este PLC de proceso principal de la planta de gas. Por debajo
de esta carpeta se encuentran carpetas por cada dispositivo que se necesite comunicar,
como por ejemplo el transmisor FT8101. A partir de esta última carpeta se encuentran los
tags correspondientes a dicho transmisor.

Tags típicos para un transmisor

Los tags típicos de base de datos HMI para un transmisor son:
Tag Tipo Descripción
AI Analog Valor escalizado de la señal leída por el transmisor
AlmDeadBand Analog Valor de configuración de la banda muerta para las
alarmas.
FAULTED Digital Indicación de falla del transmisor
HALM Digital Indicación de alarma por valor Alto
HALMEn Digital Indicación de alarma por valor Alto habilitada
HALMLMT Analog Límite para generar alarma por valor Alto
HHALM Digital Indicación de alarma por valor Alto Alto
HHALMEn Digital Indicación de alarma por valor Alto Alto habilitada
HHALMLMT Analog Límite para generar alarma por valor Alto Alto
LALM Digital Indicación de alarma por valor Bajo
LALMEn Digital Indicación de alarma por valor Bajo habilitada
LALMLMT Analog Límite para generar alarma por valor Bajo
LLALM Digital Indicación de alarma por valor Bajo Bajo
LLALMEn Digital Indicación de alarma por valor Bajo Bajo habilitada
LLALMLMT Analog Límite para generar alarma por valor Bajo Bajo

De estos tags, los siguientes se configuran como alarmas:

Tag Alarm Type Alarm Label
FAULTED On FAULT

Página 142 de 183

 HALM On HIGH
HHALM On HIGH HIGH
LALM On LOW
LLALM On LOW LOW

Tags típicos para un switch

Los tags típicos de base de datos HMI para un switch son:
Tag Tipo Descripción
ZS Digital Indicación de indicación (o alarma) del transmisor

6.5.8 Generalidades sobre objetos de Factory Talk View para dispositivos

Los dispositivos se crean bajo la estructura de objetos globales, en una librería destinada
para los mismos. El objetivo de usar objetos globales es tener un mayor nivel de
organización en los elementos usados en las pantallas, logrando mayor uniformidad y
estandarización. Manteniendo definiciones globales de los elementos gráficos permite
realizar modificaciones en los mismos que puedan ser propagados a todo el sistema de
supervisión.

Para cada dispositivo se define un conjunto específico de parámetros, los cuales se acceden
al instanciar (copiar) un objeto desde la librería y pegarlo a la pantalla deseada, y
seleccionando la opción “Global Object Parameter Values” que aparece en el menú
contextual que se despliega a dar click con el botón derecho sobre el objeto.

Figura 163 Parámetros de un objeto global

6.5.9 Transmisores
Este dispositivo muestra en pantalla el valor de la entrada análoga que se le haya
relacionado en el PLC, las alarmas que tenga configuradas, el rango y sus correspondientes
unidades. Además, cuando se da click sobre él se abre una pantalla paramétrica que
muestra los valores límites de alarma que tenga configurados, y si se mantiene presionado
sobre él despliega una ventana con la tendencia de la señal análoga.

Funcionalidad:
En condiciones normales, el mímico en pantalla se muestra con las letras de color verde y el
fondo negro. Los estados de alarma del transmisor se animan en el fondo del indicador, de
acuerdo a la severidad configurada por cada tipo de alarma. Estos estados se resumen en la
siguiente figura:

Condiciones Alarma Alarma Alarma

normales Severidad 3 Severidad 2 Severidad 1

Figura 164 Animación de estado del transmisor

En todos los casos anteriores el color de fondo se muestra parpadeando mientras la alarma
no haya sido reconocida, una vez se reconoce se mantiene del color correspondiente hasta
que la condición de alarma se normalice.

En caso que el transmisor reporte falla, el fondo se mantiene negro pero las letras se
animan de color rojo:

Figura 165 Transmisor en falla

Al dar un solo click sobre el objeto se abre el faceplate del transmisor:

Figura 166 Faceplate del transmisor

En este faceplate se muestra el nombre del transmisor, el valor del mismo (los colores de
fondo y de texto siguen las mismas reglas definidas anteriormente).

Página 144 de 183

En la parte izquierda de la ventana se muestra una barra que se anima de acuerdo al valor
del transmisor y a su condición de alarma (en condiciones normales la barra se muestra de
color verde).

En la parte derecha del faceplate se muestran los valores de alarma para el transmisor, y
posee validación de seguridad para que solo usuarios autorizados puedan modificar dichos
valores.

Si se mantiene pulsado sobre el cuadro del transmisor, se abre la ventana de tendencias:

Figura 167 Pantalla de tendencia de transmisor

Dependiendo de la configuración que se haga del objeto esta pantalla mostrará una
tendencia en tiempo real, o una de tipo histórico (asociada a un modelo de Data Log).

Configuración
Para instanciar un elemento de tipo transmisor en la pantalla siga los siguientes pasos:
Creación de los tags HMI
1. En este punto se realizará la creación de los tags HMI usando las plantillas en
formato CVS creadas para este propósito. Para este ejemplo, se crearán los tags
HMIs de dos transmisores (FT8153C y TT8107B), los cuales pertenecen al mismo
PLC (SGPPCS).
a. Ubique el archivo “TX Tags.CSV” y cópielo con otro nombre (por ejemplo,
“Pantalla1_TX Tags.CSV”).
b. Abra el archivo usando MS Excel.
c. En este archivo se encuentra la definición de tags HMI para un transmisor:
 Sección de definición de
carpetas HMI

Sección de definición de
tags HMI

Figura 168 Plantilla de tags para un transmisor

d. Realice los siguientes reemplazos:

• PLCNAME por el nombre del link de RSLinx Enterprise que apunta al
PLC (en este ejemplo, SGPPCS).
• TXNAME por el nombre del transmisor (FT8153C)
• XXXDESCRIPCION por la descripción del transmisor (ejemplo: Flujo de
agua caliente a reboiler Amina #1).
• MINEU por el valor mínimo de escala del transmisor (por ejemplo, 0)
• MAXEU por el valor máximo de escala del transmisor (por ejemplo, 100)
• XXXUNITS por las unidades que maneja el transmisor (por ejemplo,
GPM).
e. Guarde los cambios realizados y mantenga abierto este archivo.
f. Ahora abra el archivo original “TX Tags.CSV” y copie la definición de la carpeta
HMI del transmisor y péguela en el archivo que está editando, al final de la
sección de definición de carpetas HMI.

Figura 169 Adición de nueva definición de carpeta HMI

g. En el archivo original “TX Tags.CSV” copie las filas correspondientes a la

definición de los tags HMI del transmisor (filas de la 9 a la 23) y péguelas en el
archivo que está editando, al final de la sección de definición de tags HMI.
Cierre el archivo original “TX Tags.CSV”.
h. Realice ahora los reemplazos correspondientes al segundo transmisor:

Página 146 de 183

 • PLCNAME por el nombre del link de RSLinx Enterprise que apunta al
PLC (en este ejemplo, SGPPCS).
• TXNAME por el nombre del transmisor (TT8107B)
• XXXDESCRIPCION por la descripción del transmisor (ejemplo:
Temperatura Torre de Amina #1).
• MINEU por el valor mínimo de escala del transmisor (por ejemplo, 0)
• MAXEU por el valor máximo de escala del transmisor (por ejemplo, 150)
• XXXUNITS por las unidades que maneja el transmisor (por ejemplo, °F).
i. Guarde el archivo. Repita los pasos desde f hasta h para transmisor adicional
que desee adicionar.

Creación de los tags de alarma HMI

2. Ahora se procede a crear los tags HMI de alarma, siguiendo un proceso similar al
desarrollado en los pasos anteriores.
a. Ubique el archivo “TX Alms.CSV” y cópielo con otro nombre (por ejemplo,
“Pantalla1_TX Alms.CSV”).
b. Abra el archivo usando MS Excel.
c. En este archivo se encuentra la definición de alarmas HMI para un transmisor:

Figura 170 Plantilla de alarmas de un transmisor

d. Realice los siguientes reemplazos y modificaciones:

• PLCNAME por el nombre del link de RSLinx Enterprise que apunta al
PLC (en este ejemplo, SGPPCS).
• TXNAME por el nombre del transmisor (FT8153C)
• Modifique las severidades de cada alarma según sea necesario (por
defecto la plantilla tiene las severidades en 3).
e. Guarde los cambios realizados y mantenga abierto este archivo.
f. Ahora abra el archivo original “TX Alms.CSV” y copie las filas correspondientes
a la definición de las alarmas HMI del transmisor (filas de la 5 a la 9) y péguelas
al final del archivo que está editando. Cierre el archivo original “TX Alms.CSV”.
g. Realice ahora los reemplazos correspondientes al segundo transmisor:
• PLCNAME por el nombre del link de RSLinx Enterprise que apunta al
PLC (en este ejemplo, SGPPCS).
• TXNAME por el nombre del transmisor (TT8107B)
• Modifique las severidades de cada alarma según sea necesario (por
defecto la plantilla tiene las severidades en 3).
 h. Guarde el archivo. Repita los pasos desde 1.f hasta 1.h para transmisor adicional
que desee adicionar.

Importación de tags HMI

3. El proceso de importación de tags HMI debe realizarse desde el mismo servidor que
ejecuta el proyecto HMI (es decir, no es posible importar tags desde una estación de
ingeniería remota). Para hacerlo siga los siguientes pasos:
a. Desde Factory Talk View Studio, seleccione la opción “Tag Import and Export
Wizard” que se encuentra en el menú “Tools”.

Figura 171 Herramienta de importación de tags HMI

b. Seleccione la opción de Importar tags (Import FactoryTalk View CSV files) y

pulse Next.
c. En el tipo de proyecto seleccione “Site Edition”, y en el cuadro inferior utilice el
botón “…” para ubicar la carpeta en la cual se encuentra el proyecto HMI, y
seleccione el archivo .SED que se encuentra dentro de esa carpeta.

Figura 172 Selección del Proyecto HMI para importar tags

d. En la ventana que se abre coloque la marca de selección sobre “Tags” y sobre

“Alarms”, y use los botones de “…” para ubicar los archivos creados en los pasos
anteriores (“TX Tags.CSV” para los tags, y “TX Alms.CSV” para las alarmas).

Figura 173 Selección de archivos para importar

Página 148 de 183

 e. Pulse next para continuar, y seleccione la opción de importación que más se
ajuste a sus necesidades:
• Skip existing: Utilice esta opción si los tags que va a importar son
nuevos (van a ser creados por primera vez).
• Update existing: Utilice esta opción si los tags que desea importar ya
existen en la base de datos, y lo que desea es actualizarlos.
f. Pulse Next y finalmente Finish. Al terminar la herramienta muestra un resumen
del proceso de importación:

Figura 174 Ventana de resumen de la operación de importación

Opcional: Adición del transmisor a un datalog

4. En esta parte se realizan los pasos para adicionar el tag de los transmisores al
registro histórico de tendencias.
a. Siga los pasos descritos en la sección 6.5.3 para crear un datalog para las
señales de flujo (Area1_Flujos), y otro para las de temperatura
(Area1_Temperaturas).
b. Abra las propiedades del datalog “Area1_Flujos”, y seleccione la pestaña “Tags
in Model”.
c. Use el botón “…” para abrir el explorador de tags, y seleccione el tag “AI” de la
carpeta HMI “SGPPCS\FT8153C\”, y pulse el botón “Add Tag(s) to List”. Finalice
pulsando OK, para devolverse a la pantalla principal del datalog.

Figura 175 Adición de tag al Datalog

d. Finalice el proceso de adición pulsando el botón “Add”. De esta manera el tag

se adiciona a la lista de tags del datalog:
 Figura 176 Paso final de la adición de un tag al datalog

e. Pulse OK para finalizar la edición del datalog.

f. Repita este procedimiento desde el paso b para adicionar el tag TT8107B al
datalog “Area1_Temperaturas”.

Instanciamiento del objeto en pantalla

5. Abra el archivo de librería de objetos globales “LIB_1” , haga click sobre el objeto
transmisor y copiélo (puede usar el método de teclado <Ctrl> + <C>, o hacer click
con el botón derecho del mouse sobre el transmisor y seleccionar “Copy” en el
menú contextual.

Figura 177 Copia del objeto global transmisor

6. Cambie hacia la pantalla en la cual desea crear el transmisor, y pegue el objeto

copiado en el paso anterior (puede usar el método de teclado <Ctrl> + <V>, o hacer
click sobre el fondo de la pantalla y seleccionar la opción “Paste” del menú
contextual.
7. Haga click con el botón derecho del mouse sobre el transmisor que acaba de copiar,
y seleccione la opción “Global Object Parameter Values”.

Página 150 de 183

 Figura 178 Configuración del objeto instanciado de transmisor

Configuración de parámetros
8. #1= Ingrese (o seleccione usando el botón “…”) la carpeta HMI que corresponde al
transmisor (la carpeta creada en el paso 1 de este apartado). Ejemplo:
SGPPCS\FT8153C.
9. #2= Ingrese el nombre del transmisor, corresponde al texto que debe aparecer en el
cuadro del objeto, y también aparece como el título del faceplate del transmisor. El
botón “…” no sirve para llenar este parámetro.
10. #3= Este es un parámetro opcional:
a. Si se deja en blanco, el transmisor no tiene asociado un tag en el sistema de
registro de históricos, y por lo tanto, al abrir la ventana de tendencia de este
transmisor se mostrará una tendencia en tiempo real.
b. Si el transmisor se registra en el sistema histórico, puede ingresar el nombre del
datalog asociado en este parámetro. De esta manera al abrir la ventana de
tendencia se mostrará una con la información histórica del datalog. Para el caso
de este ejemplo puede ingresar “Area1_Flujos”, que corresponde al datalog
creado en los pasos anteriores.
11. #4= La ventana de tendencia grafica por defecto el tag “AI” que se encuentra en la
carpeta HMI definida por el parámetro #1. Se ofrece este parámetro para graficar
otro tag diferente que exista dentro de la misma carpeta HMI del transmisor.
12. #5 = Este parámetro define el nivel de seguridad del transmisor (un valor entre A y
P). Si no ingresa nada en este campo (o ingresa un valor inválido) el transmisor
quedará sin seguridad. El nivel de seguridad define si el usuario registrado en el
sistema tiene permisos para modificar los límites de alarma.

En la siguiente figura se muestra el transmisor con los parámetros configurados:

Figura 179 Ejemplo de parámetros para un transmisor

 13. Pulse OK para cerrar la ventana de parámetros. De esta manera, el transmisor
queda configurado.

6.5.10 Válvulas
Este dispositivo permite operar y visualizar el estado de abierto o cerrado de una válvula.
Cuando se da click sobre este dispositivo se despliega una pantalla que permite la operación
de la misma.

Funcionalidad:
El mímico de la válvula se divide en dos secciones:
• Un rectángulo superior que indica el comando activo hacia la válvula (abrir o cerrar).
• El cuerpo de la válvula (dos triángulos unidos por un círculo) que indica el estado
actual de apertura o cierre de la válvula (de acuerdo al estado de los switchs de final
de carrera).

El rectángulo superior se anima de color verde cuando el PLC comanda la válvula a abrir, y
se anima de color rojo cuando el comando es de cierre.

El cuerpo de la válvula se muestra de color verde cuando la válvula está abierta, y de color
rojo cuando está cerrada. La condición de apertura y cierre se determina por medio de la
presencia de los switchs de final de carrera (ZSO – Switch de final de carrera que indica que
la válvula está abierta, y ZSC – Switch de final de carrera que indica que la válvula está
cerrada), los cuales se encuentran como miembros de la estructura de datos de la válvula en
el PLC. Para el caso de válvulas que no tienen switchs de final de carrera (o que poseen solo
uno de los dos) la lógica del PLC se encarga de simular las señales ZSC/ZSO
correspondientes, de forma que la animación funciona también para este tipo de válvulas.

Comando de apertura Se recibe comando de Válvula viajando de Comando de cierre

Válvula abierta cierre. abierta a cerrada Válvula cerrada

Figura 180 Estados de operación de la válvula

En el caso mostrado en la figura anterior se muestra la secuencia típica de operación de una

válvula que está abierta y su transición a estado cerrado. Inicialmente se muestra el
dispositivo con el comando de apertura activo y los switchs de fin de carrera indicando que
la válvula se encuentra abierta. En el segundo gráfico la válvula indica que recibió un
comando de cierre, pero el limit switch de apertura sigue activo (indicando que la válvula
sigue abierta). A medida que la válvula se desplaza, el limit switch de apertura se desactiva,
lo que se indica con el cuerpo de la válvula de color gris (la válvula se encuentra viajando, no
hay limit switchs activos). Finalmente, el limit switch de cierre se activa, lo que hace que el
cuerpo de la válvula se anime de color rojo.

Página 152 de 183

Dependiendo del tamaño de la válvula, es posible que no se alcancen a visualizar algunos de
los estados intermedios (la válvula pasa de rojo a verde instantáneamente, o viceversa).

Como puede verse en la Figura 180 la válvula posee un rombo de color negro en la parte
superior. El objetivo de este rombo es indicar el estado de bypass de la válvula por medio de
una animación de color:
• Rombo de color negro: El bypass se encuentra deshabilitado.
• Rombo de color azul celeste: El bypass se encuentra habilitado.

Adicionalmente el mímico de la válvula posee un recuadro negro con la letra “M”, la cual
aparece cuando el dispositivo se encuentra en control manual desde pantalla (Control por
Operador).

Figura 181 Válvula con Bypass Habilitado

Cuando el bypass se encuentra habilitado (rombo de color azul celeste) la válvula solamente
puede ser comandada desde el HMI. Los comandos de enclavamiento y de comando desde
PLC se desactivan en este modo.

Falla al cerrar (FTC)

Recuadro de nombre de
válvula, se anima de acuerdo a
la severidad de la alarma
Falla al abrir (FTO)

Figura 182 Indicación de fallas de la válvula

En la Figura 182 se muestra las animaciones que muestra la válvula ante una falla al cerrar
(FTC – Fail To Close), en la cual el cuerpo de la válvula titila entre rojo y amarillo, y una falla
al abrir (FTO – Fail To Open), en la cual se muestra titilando entre verde y amarillo. La
severidad de la alarma se indica con el color del recuadro de nombre de la válvula, titilando
de color amarillo si la alarma tiene severidad 3, naranja para severidad 2 y rojo para
severidad 1.

Al hacer click sobre la válvula se abre el faceplate de control, el cual muestra el estado del
comando y del feedback de la válvula, y presenta botones para operar el dispositivo. Este
faceplate se muestra en la siguiente figura:
 Tag de la válvula Estado del Comando hacia
la válvula. Rojo = Cerrar
Verde = Abrir
Comandos de
apertura/cierre Indicación del Feedback de
la válvula. Rojo = Cerrada
Verde = Abierta
Cambiar a modo Programa
o modo Operador

Modo actual: Programa u

Operador
Figura 183 Faceplate de Válvulas

Como puede verse en la figura anterior, el faceplate maneja el mismo código de colores que
el mímico, mostrando en la parte superior una animación del estado del comando
(abrir/cerrar) y en el cuadro del estado un texto y animación de color con el estado real de la
válvula (determinado por los switchs de final de carrera, cuando éstos existen). En la
siguiente figura se muestra las posibles transiciones presentadas en el faceplate cuando se
ordena abrir una válvula:

Figura 184 Animaciones en el faceplate al cerrar una válvula

La secuencia presentada en la figura anterior es la misma explicada en la Figura 180,

iniciando con la válvula abierta, la cual posteriormente recibe un comando de cierre,
comienza a cerrarse (válvula en transición) para finalmente cerrarse.

En caso de falla el cuadro de indicación de estado se anima de manera similar a como se

anima el cuerpo del mímico de la válvula, titilando entre amarillo y verde para la falla
durante apertura (FTO), y entre amarillo y rojo para la falla durante el cierre (FTC). Al estar
en falla, el texto “ESTADO” se cambia por un botón que permite hacer un reset individual

Página 154 de 183

de la falla de la válvula (es decir, se puede limpiar la falla de una sola válvula individual). Esta
situación se muestra en la siguiente figura:

Reset de falla

Figura 185 Reset de falla

Cuando el usuario registrado en el sistema no posee el nivel de permiso requerido para

operar la válvula (el cual se define durante la configuración de la misma) el faceplate no
muestra ninguno de los botones de operación, como se muestra a continuación:

Figura 186 Faceplate de válvula con usuario sin permisos

Configuración
Para instanciar un elemento de tipo válvula en la pantalla siga los siguientes pasos:

Creación de los tags HMI

1. En este punto se realizará la creación de los tags HMI usando las plantillas en
formato CVS creadas para este propósito. Para este ejemplo, se creará los tags
HMIs de la válvula FY8301D perteneciente al PLC SGPPCS. El procedimiento
detallado ya se ha realizado con transmisores en la sección 6.5.9, por lo tanto en
esta sección se muestra el procedimiento resumido aplicado a válvulas.
a. Ubique el archivo “Valve Tags.CSV” y cópielo con otro nombre (por ejemplo,
“Pantalla1_Valve Tags.CSV”).
b. Abra el archivo usando MS Excel.
c. Realice los siguientes reemplazos:
i. PLCNAME por el nombre del link de RSLinx Enterprise que apunta al PLC
(en este ejemplo, SGPPCS).
ii. VALVENAME por el nombre de la válvula (FY8301D)
 iii. XXXDESCRIPCION por la descripción de la válvula (ejemplo: Válvula de
Bypass del tambor de succión – Expander 3).
d. Guarde los cambios realizados. Si necesita adicionar más válvulas, copie la
definición del archivo de la plantilla al archivo que esta editando y realice los
reemplazos correspondientes.

Creación de los tags de alarma HMI

2. Ahora se procede a crear los tags HMI de alarma, siguiendo un proceso similar al
desarrollado en los pasos anteriores.
a. Ubique el archivo “Valve Alms.CSV” y cópielo con otro nombre (por ejemplo,
“Pantalla1_Valve Alms.CSV”).
b. Abra el archivo usando MS Excel.
c. Realice los siguientes reemplazos y modificaciones:
i. PLCNAME por el nombre del link de RSLinx Enterprise que apunta al PLC
(en este ejemplo, SGPPCS).
ii. VALVENAME por el nombre de la válvula (FY8301D)
iii. Modifique las severidades de cada alarma según sea necesario (por defecto
la plantilla tiene las severidades en 3).
d. Guarde los cambios realizados. Si necesita adicionar más válvulas, copie la
definición del archivo de la plantilla al archivo que esta editando y realice los
reemplazos correspondientes.

Importación de tags HMI

3. El proceso de importación de tags HMI debe realizarse desde el mismo servidor que
ejecuta el proyecto HMI (es decir, no es posible importar tags desde una estación de
ingeniería remota). Use la herramienta Tag Import/Export Wizard de FTV para
importar los archivos de Tags y Alarmas creados en el paso anterior. En la sección
6.5.9 se explica en detalle cómo usar la herramienta de importación de tags.

Instanciamiento del objeto en pantalla

4. Abra el archivo de librería de objetos globales “LIB_1” , haga click sobre el objeto
válvula (en la orientación requerida) y copiélo (puede usar el método de teclado
<Ctrl> + <C>, o hacer click con el botón derecho del mouse sobre la válvula y
seleccionar “Copy” en el menú contextual.

Figura 187 Librería de Válvulas

Página 156 de 183

 5. Cambie hacia la pantalla en la cual desea crear el transmisor, y pegue el objeto
copiado en el paso anterior (puede usar el método de teclado <Ctrl> + <V>, o hacer
click sobre el fondo de la pantalla y seleccionar la opción “Paste” del menú
contextual.
6. Haga click con el botón derecho del mouse sobre la válvula que acaba de copiar, y
seleccione la opción “Global Object Parameter Values”.

Configuración de parámetros
7. #1= Ingrese (o seleccione usando el botón “…”) la carpeta HMI que corresponde a la
válvula (la carpeta HMI creada en el paso 1 de este apartado). Ejemplo: SGPPCS\
FY8301D.
8. #2= Ingrese el nombre de la válvula, corresponde al texto que debe aparecer en el
cuadro del objeto, y también aparece como el título del faceplate de la válvula. El
botón “…” no sirve para llenar este parámetro.
9. #3 = Este parámetro define el nivel de seguridad de la válvula (un valor entre A y P).
Si no ingresa nada en este campo (o ingresa un valor inválido) la válvula quedará sin
seguridad. El nivel de seguridad define si el usuario registrado en el sistema tiene
permisos para operar la válvula (abrir/cerrar y cambiar modo de operación).

En la siguiente figura se muestra la válvula con los parámetros configurados:

Figura 188 Ejemplo de parámetros para una válvula

10. Pulse OK para cerrar la ventana de parámetros. De esta manera, la válvula queda
configurada.

6.5.11 Motor
Este dispositivo permite operar y visualizar el estado de un motor convencional (Full
Voltage Non-Reversible).

Funcionalidad:

6.5.12 Switch

6.5.13 PID
6.6 IMPLEMENTACION HMI DEL SISTEMA DE DIAGNOSTICOS:
DIAGNOSTICOS

6.6.1 Base de datos de tags

Para el sistema de diagnósticos se define una carpeta principal la cual se encuentra en la
raíz de la base de datos con el nombre “Diag”, y en la cual se adicionan las señales usadas
por el sistema de diagnósticos. En este nivel se encuentran dos subcarpetas:
• Critical: Corresponde a todas las señales que indican fallas críticas del sistema de
control, como por ejemplo:
o Consumo de la memoria de I/O o de datos de un procesador por encima del
80%.
o Falla de módulo de I/O o módulo Controlnet
o Falla de un PLC
o Falla de ambos canales de una tarjeta Controlnet redundante
o Falla de canal de una tarjeta Controlnet no redundante
• Warning: Correspond
Corresponde
e a las señales que constituyen una advertencia sobre la salud
del sistema de control. Indican situaciones en las cuales el sistema de control está
trabajando de manera degradada, como por ejemplo:
o Pérdida de redundancia de las fuentes de 24Vdc.
o Consumo de la memoria de I/O o de de datos de un procesador por encima
del 75%.
o Falla de la batería de un PLC.
o Pérdida de redundancia en alguno de los PLCs que trabajan bajo este
esquema.
o Pérdida de redundancia de una canal Controlnet.

Dentro de cada una de estas ccarpetas

arpetas se debe crear una carpeta por cada PLC que sea
monitoreado por este sistema. De esta forma se llega a tener una estructura de carpetas
HMI como la mostrada en la siguiente figura:

Figura 189 Estructura de ejemplo de tags HMI - Sistema de Diagnósticos

Página 158 de 183

Los tags dentro de cada carpeta varían de PLC a PLC (dependen de la distribución de I/O
que maneja el PLC, la cantidad y distribución de tarjetas de comunicaciones y si el sistema
maneja redundancia de PLC o no). Se presenta como ejemplo los tags creados para el
sistema Colombia PCS, en el cual se recogen los elementos más comunes que deben ser
configurados. Recuerde que los nombres de los tags HMI deben corresponder con los
nombres de los tags de PLC. En el caso del PLC SGPPCS, se tiene la siguiente estructura:

• Carpeta Critical\SGPPCS
Alarmas relacionadas con el Controlador:
o Diag_SGPPCS_Faulted: Indicación de PLC en falla
o Diag_Proc_Used_Mem_DT_HHAlarm
o Diag_Proc_Used_Mem_IO_HHAlarm

Alarmas relacionadas con la tarjeta Controlnet Slot 01:

o Diag_CNET01_CH_Critical_Alarm
o Diag_CNET01_Faulted

Alarmas relacionadas con la tarjeta Controlnet Nodo 04:

o Diag_CNET02_N04_Faulted
o Diag_CNET02_N04_S0_Faulted – Falla del módulo del slot 0
o Diag_CNET02_N04_S1_Faulted – Falla del modulo del slot 1
o Diag_CNET02_N04_Sx_Faulted – Falla del módulo del slot x

• Carpeta Warning\SGPPCS
Warnings relacionados con el Controlador:
o Diag_Gen_Data_PrimProcBattery
o Diag_Gen_Data_SecProcBattery
o Diag_Proc_Used_Mem_DT_HAlarm
o Diag_Proc_Used_Mem_IO_HAlarm

Warning relacionado con la pérdida de redundancia:

o Diag_Proc_Redund_Alarm

Warnings relacionados con la tarjeta Controlnet del Slot 01

o Diag_CNET01_CHA_Warning
o Diag_CNET01_CHB_Warning

6.6.2 Presentación de Pantallas

Para la presentación del sistema de diagnósticos se debe contar con una pantalla principal
la cual resuma la arquitectura de control. En la siguiente figura se presenta la pantalla de
arquitectura de la red de Control de Cusiana:
 Gateway

Colombia ESD

Colombia PCS

Figura 190 Pantalla Overview - Sistema de Diagnósticos

Como puede verse en la figura, los PLCs se encuentran agrupados y encerrados en

recuadros, los cuales representan los tableros en los cuales se encuentran dichos
Controladores. Sin embargo, no es necesario limitar el mímico de la arquitectura usando
únicamente la distribución de tableros, pues generalmente resulta más cómodo mostrar los
chasis de acuerdo a su relación con otros.

Por ejemplo, en la figura se muestran los PLCs Gateway, Colombia PCS y Colombia ESD
encerrados en recuadros independientes, pero físicamente esos PLCs se encuentran
instalados en el mismo tablero (tablero PCS-80001). Por lo tanto, esos tres recuadros
representan en mismo tablero, y al pulsar sobre cualquiera de ellos se abrirá la ventana del
tablero PCS-80001.

Cuando ocurre una falla “crítica” el recuadro del PLC parpadeará de color rojo indicando
que existe una falla crítica en el (los) PLC(s) respectivo(s), y se generará la alarma crítica del
sistema de Control.

Página 160 de 183

 Figura 191 Indicación de falla crítica

Cuando ocurre un “warning” el área de PLC parpadeará de color amarillo indicando que
existe una advertencia en el (los) PLC(s) respectivo(s).

Figura 192 Indicación de Warning

Al hacer click sobre el área se desplegará una pantalla donde se muestra el respectivo
tablero físico con los PLC que se encuentren en él. En las siguientes dos figuras se muestran
la representación de los paneles ESD-80001 y IO-80002

Figura 193 Diagnóstico Panel ESD-80001

 Figura 194 Diagnóstico Panel IO-80002

Dentro de cada pantalla de panel se muestra la distribución de los chasis de control que se
encuentran en ella, mostrando animaciones para representar las alarmas y/o warnings que
existen en cada uno de los elementos del tablero:
• Para el caso de las fuentes de alimentación de 24 VDC: Bajo condiciones normales,
las fuentes se muestran sin ninguna animación (como las mostradas en la Figura
193 y Figura 194. Cuando se pierde la redundancia de las fuentes, éstas se animan
con un recuadro parpadeante de color amarillo en el fondo.

• Para el caso de los módulos de PLC, existe un recuadro de indicación de falla que se
encuentra en el borde inferior de cada uno de ellos, el cual se anima de color rojo
ante una situación de falla crítica, o de color amarillo ante un warning.

Falla crítica Warning

Falla redundancia fuentes

24VDC

Figura 195 Indicación de pérdida de redundancia fuente 24 VDC

Página 162 de 183

La mayoría de los componentes del sistema de control abren una ventana de detalle al
pulsar sobre ellos. Por ejemplo, al hacer click sobre un procesador se abre la siguiente
ventana:

Figura 196 Ventana de estado del procesador

Esta ventana muestra los valores Totales, Libres y Usados de la memoria de I/O y de la
memoria de Datos/Lógica. Adicionalmente, cuando el PLC es redundante, muestra el
estado de la redundancia:
• Identificación del chasis primario (Chasis A o Chasis B)
• Estado de la batería de ambos procesadores (Primario y Secundario)
• Estado de la redundancia: Es un texto indicando el estado:
o PowerUp
o Prim & Sec Sync
o Prim & Sec Disq
o Prim & NO Sec
• Estado General de los módulos de I/O: Presenta un resumen general del estado del
sistema de I/O del Procesador:
o No IO listed
o No modules respond
o At least 1 module responds
o All modules respond
• Modo del PLC: Esta sección muestra el modo de operación del PLC (Program, Run,
Faulted), y el tipo y código de falla (en caso que el PLC esté fallado).

En el caso de los módulos Controlnet se despliega la siguiente ventana:

Figura 197 Ventana de estado de tarjeta Controlnet

En esta pantalla se muestra el estado general de falla del módulo, el código y la descripción
de la falla (si existe), así como el estado de los canales Controlnet de la tarjeta, y el canal
activo. Se incluye un texto que describe la red a la cual está asociado (en el caso de la figura,
red de F&G).

Para los otros módulos se tiene una ventana genérica de estado, la cual indica básicamente
si el módulo se encuentra en falla, y el código y mensaje de falla (si existe).

Figura 198 Estado de módulo de I/O

6.6.3 Registro histórico de datos

El sistema fue diseñado para llevar un registro histórico de los datos de diagnóstico
recopilados de dos maneras complementarias:
• Registro histórico de alarmas: El sistema genera alarmas digitales que quedan
registradas en el histórico de alarmas cada vez que un elemento se encuentre en falla
(alarma por alto consumo de memoria del PLC, falla de módulo, falla de PLC, etc), el
cual tiene severidad 8 (esta severidad queda asignada a los eventos del sistema de
diagnósticos).
• Registro en Datalog Model: Los códigos de falla recopilados por el sistema son
guardados en un Datalog Model (de esta manera, se guarda en el HMI los códigos de
falla en el momento en que son detectados).

El sistema crea un archivo por día en la carpeta D:\Datalogs\Diagnostics del Servidor HMI,
utilizando la nomenclatura: YYYY MM DD 0000 Diag (Float).DAT, donde YYYY
corresponde al año, MM al mes y DD. La información se guarda por un espacio de 6 meses.
Debido a la naturaleza poco variable de estos datos (se espera que la planta funcione sin
reportar códigos de error constantemente en el sistema de Control), se configuró la
adquisición de datos por cambio de valor (Data Change).

El siguiente es el procedimiento para revisar los archivos del datalog, el cual debe ser
ejecutado en la estación de ingeniería:
1. Para garantizar que el archivo de datos tenga la información más actualizada, abra
RSView Studio, y ejecute el comando: DataLogSnapshot diagnostics
2. Copie la carpeta D:\Datalogs\Diagnostics del Servidor HMI (\\Server1) a la estación de
ingeniería (o copie los archivos del día que desea revisar).
3. Ejecute la aplicación RSView Enterprise File Viewer, y use el menú File
Open para
abrir el archivo del día que desea revisar. La utilidad muestra la información en filas y
columnas, mostrando la fecha y hora del evento, el nombre y valor del tag.

Página 164 de 183

 Figura 199 RSView Enterprise File Viewer

La herramienta permite exportar los registros a un archivo separado por comas, para
efectos de poder filtrar y analizar la información. Para hacerlo utilice el menú File
Save
As.

7 ANEXOS

7.1 Explicación Filtro Digital en Tarjetas de Entrada analógica

Los canales de entrada de las tarjetas analógicas poseen un parámetro llamado digital
filter, el cual se ingresa como un valor en milisegundos.

Si se usara una entrada de escalón en la entrada del canal (un cambio de 0% al 100% del
rango del canal), el valor filtrado llegaría a un 63% cuando se cumpla el primer periodo de
tiempo definido por el filtro. A partir de ahí, cada periodo de tiempo la señal filtrada
aumentaría un 63% del valor restante.

Por ejemplo, si se usa un filtro digital de 0,5 segundos y se aplica una entrada en escalón:
• En el tiempo t = 0,5 segundos la salida llegará al 63%.
• En el tiempo t = 1 segundo, la salida será del 86,3%
(63 + (100-63)*6.3)
• En el tiempo t = 1.5 segundos, la salida será del 94.9%
(86.3 + (100-86.3)*6.3)
• Y así sucesivamente.

7.2 Implementación de la instrucción de entrada analógica AOI_AIN

La instrucción AOI_AIN fue implementada en lenguaje ladder, utilizando los componentes
descritos a continuación.

Parámetros
Name Usage Type Description
InputAdd Input REAL Valor leído del modulo de entrada (escalizado en la tarjeta)
FaultAdd Input BOOL Indicación de canal en falla de la tarjeta
EuMax Input REAL Valor máximo en Unidades de Ingeniería
EuMin Input REAL Valor mínimo en Unidades de Ingeniería
 Name Usage Type Description
HHAlmLimit Input REAL Valor de alarma HH
HAlmLimit Input REAL Valor de alarma H
LAlmLimit Input REAL Valor de alarma L
LLAlmLimit Input REAL Valor de alarma LL
AlmDeadband Input REAL Deadband de los limites de alarma
HHAlmEn Input BOOL Habilitar alarma HH
HAlmEn Input BOOL Habilitar alarma H
LAlmEn Input BOOL Habilitar alarma L
LLAlmEn Input BOOL Habilitar alarma LL
BypassEn Input BOOL Habilitar Bypass:
0 = Deshabilitado
1 = Habilitado
HHAlarm Output BOOL Alarma HH Activa
HAlarm Output BOOL Alarma H Activa
LAlarm Output BOOL Alarma L Activa
LLAlarm Output BOOL Alarma LL Activa
Faulted Output BOOL Indicación de canal en falla
TripHH Output BOOL Disparo por HH
(0 = Disparo)
TripLL Output BOOL Disparo por LL
(0 = Disparo)
Value Output REAL Valor escalizado

Local Tags:
Name Type Default Description
EuDelta REAL 0.0 Valor leído del modulo de entrada (escalizado en la tarjeta)
EuErrPerc REAL 0.1 Indicación de canal en falla de la tarjeta
EuORValue REAL 0.0 Valor máximo en Unidades de Ingeniería
EuURValue REAL 0.0 Valor mínimo en Unidades de Ingeniería
IntValue REAL 0.0 Valor de alarma HH
SqrEn BOOL 0.0 Valor de alarma H
SqrEuMax REAL 0.0 Valor de alarma L
SqrEuMin REAL 0.0 Valor de alarma LL
SqrRawMax REAL 0.0 Habilitar alarma HH
SqrRawMin REAL 0.0 Habilitar alarma H

Lógica:

Página 166 de 183

Se calcula el Span del transmisor (EuMax –
EuMin) y se multiplica
ltiplica por el porcentaje de
Error definido por el usuario (EuErrPerc,
por defecto es 0.1)
Con el Delta calculado, se obtiene el valor máximo y mínimo permitido
para la señal (EuORValue y EuURValue). Cuando la señal sube por
encima de EuORValue se tiene un OverRange, cuando cae por debajo
de EuURValue se tiene un UnderRange.

Indicación de falla del canal de la

tarjeta (pasado a la instrucción como
parámetro).

Detectar falla por OverRange

Detectar falla por UnderRange

 Este renglón verifica que el valor leído se
encuentra por encima del valor mínimo. Si no es
así, coloca la salida en el valor mínimo (para evitar
mostrar valores irreales debido a una desconexión
de cable, por ejemplo).

Cálculo de raíz cuadrada: Existe un Local Tag llamado SqrEn (valor por defecto 0), el cual habilita el
cálculo de raíz cuadrada cuando está activo. La instrucción extrae la raíz cuadrada del valor leído del
canal, y la escaliza de acuerdo a los valores definidos en SqrRawMin, SqrRawMax (los valores mínimos y
máximos esperados del valor en raíz cuadrada)
cuadrada), SqrEuMin y SqrEuMax (los valores máximos y mínimos
en la nueva unidad de ingeniería calcula – por ejemplo, scfm).
Estos valores deben ser ingresados por el programador.

Página 168 de 183

Lógica de Generación de alarmas HH y H:
Cada alarma tiene su bit de habilitación ón individual
(HHAlmEn, HAlmEn), los cuales son accesibles desde el
programa de PLC (para escribir lógica que pueda
habilitar/deshabilitar alarmas). Cuando Value supera el
limite definido se genera la alarma, y se retiene hasta que
Value caiga por debajo del Deadband.

Lógica de Generación de alarmas L y LL:

Cada alarma tiene su bit de habilitación individual (LAlmEn,
LLAlmEn), los cuales son accesibles desde el programa de
PLC (para escribir lógica que pueda habilitar/deshabilitar
alarmas). Cuando Value
ue cae por debajo el limite definido se
genera la alarma, y se retiene hasta que Value suba por
encima del Deadband.
Generar disparo por canal en falla (solo si
FaultTripType = 1) o por alarma HH

El Disparo se inhabilita si BypassEn = 1

Faulted se puede generar por OverRange o

UnderRange. Si la instrucción se encuentra
configurada para hacer disparo por LL ante la falla
del canal (FaultTripType = 0), entonces este
renglón evita que se produzca disparo por HH
ante falla.

Generar disparo por canal en falla (solo si

FaultTripType = 1) o por alarma HH

El Disparo se inhabilita si BypassEn = 1

Faulted
ted se puede generar por OverRange o
UnderRange. Si la instrucción se encuentra
configurada para hacer disparo por LL ante la falla
del canal (FaultTripType = 0), entonces este
renglón evita que se produzca disparo por HH
ante falla.

Página 170 de 183

7.3 Implementación de la instrucción de control de motores AOI_FVNR
La instrucción AOI_FVNR fue implementada en lenguaje ladder, utilizando los
componentes descritos a continuación.

Parámetros
Name Usage Type Description
HSR Input BOOL Contacto de Arranque desde Campo
(1 = Arranque)
HSS Input BOOL Contacto de Parada desde Campo
(0 = Parar)
Fail Input BOOL Falla General del Motor
(1 = Falla)
Aux Input BOOL Contacto Auxiliar
(1=Arrancado)
HMI_Stop Input BOOL Comando de Parada desde HMI
HMI_Reset Input BOOL Comando de Reset desde HMI
XSR Output BOOL Contacto de Arranque (1 = Arrancar)
XSS Output BOOL Contacto de Parada (0 = Parar)
FailToStart Output BOOL Falla de arranque (Contacto de Arranque Cerrado y No AUX)
FailToStop Output BOOL Falla de Parada (Contacto de Arranque abierto y AUX activo)

Local Tags:
Name Type Default Description
StartTMR Timer 15000 Temporizado para generar falla durante arranque
StopTMR Timer 15000 Temporizado para generar falla durante parada
Lógica:

Energización contacto de arranque (XSR): Energizar la salida XSR cuando

HSR se active, si no existen fallas en el motor y si el Contacto de Parada
(HSS) está en su valor normal (‘1’).

Contacto de parada (XSS): En condiciones normales este contacto está energizado para
permitir el arranque del motor. Cuando llegue un comando de parada desde campo (HSS = ‘0’)
ó cuando llegue un coamdno de parada desde HMI (HMI_Stop = ‘1’) o ante una falla en el motor
el contacto XSS se abre para parar el motor.

Página 172 de 183

 Generación de falla durante la parada (FailToStop): Cuando se des des-energiza
energiza el contacto para
arrancar el motor, se espera el tiempo definido por StopTMR para esperar que se abra el
contacto Auxiliar (Aux = ‘0’). Si al cumplirse ese tiempo Aux sigue siendo ‘1’ se engancha el valor
de FailToStop.

Reset de fallas: Las fallas FailToStart y FailToStop son enganc

enganchadas
hadas cuando ocurren. Para
volver a normalizar estas fallas se tiene el tag HMI_Reset, el cual reinicializa estas fallas cuando
HMI_Reset = ‘1’.

7.4Implementación de la instrucción de control de válvulas discretas

AOI_Valve
La instrucción AOI_Valve fue implementada en lenguaje ladder, utilizando los
componentes descritos a continuación.

Parámetros
Name Usage Type Description
ZSC Input BOOL Limit Switch de Cierre
ZSO Input BOOL Limit Switch de Apertura
Intlck_Req Input BOOL Se debe mantener en '1' para comandar la válvula al estado
de Interlock.
Intlck_State Input BOOL Estado de interlock:
0 = Cerrar Válvula
1 = Abrir Válvula
Mode Input BOOL Modo de Operación:
0 = Control por Programa
1 = Control por Operador
 Name Usage Type Description
BypassEn Input BOOL Habilitar Bypass:
0 = Deshabilitado
1 = Habilitado
HMIOpen Input BOOL Comando de Apertura desde HMI
HMIClose Input BOOL Comando de Cierre desde HMI
ProgOpen Input BOOL Comando de Apertura desde PLC
ProgClose Input BOOL Comando de Cierre desde PLC
HMI_Reset Input BOOL Comando de Reset desde HMI
SV Output BOOL Estado Lógico:
1 = Abierta
0 = Cerrada
OUT Output BOOL Salida de Control de la Válvula
FTO Output BOOL Falla durante la Apertura (Fail-to-Open)
FTC Output BOOL Falla durante el Cierre (Fail-to-Close)
NoZSC Output BOOL Salida simulada de ZSC para válvulas que no tienen Limit
Switch de Cierre
NoZSO Output BOOL Salida simulada de ZSO para válvulas que no tienen Limit
Switch de Apertura

Página 174 de 183

 Local Tags:
Name Type Default Description
FTC_TMR Timer 10000 Temporizado para generar alarma Falla al Cerrar (FTC)
FTO_TMR Timer 10000 Temporizado para generar alarma Falla al Abrir (FTO)
Type BOOL 0 Tipo de Válvula:
0 = NC
1 = NO

Lógica:
Cuando no está habilitado el bypass, la válvula es
controlada:
- Por el programa, cuando Mode = 0.
- Por el HMI, cuando Mode = 1.
- En cualquier modo cuando exista un Interlock.

Estado lógico de la válvula: Se usa

instrucciones
strucciones OTL / OTU para que la
válvula conserve su último estado si el
PLC es pasado de modo Program a
modo Run.

Cuando el bypass está habilitado, el

control se hace únicamente por HMI
(los Interlocks no actúan).
 Esta es la misma lógica implementada
en el renglón anterior, pero para las
condiciones que hacen cerrar la
válvula.

Dependiendo del tipo de válvula (NC –

Energiza para abrir, o NO – Energiza
para cerrar) se convierte el estado
lógico (SV) en la salida de control
(OUT)

Página 176 de 183

 Estos dos renglones generan las fallas durante la apertura (FTO) y durante el cierre (FTC). Si el Limit
Switch respectivo no se activa en el tiempo especificado por FTO_TMR o FTC_TMR (según el caso) se
activa la falla respectiva.

No todas las válvulas tienen Limit Switchs de cierre y/o apertura. Para
esas válvulas se ofrece las salidas NoZSO y NoZSC, las cuales simulan
estos switches. De esta manera, si la válvula XYZ no tiene Limit Switch
de cerrado, se puede usar el tag XYZ.NoZSC para alimentar el parámetro
XYZ.ZSC.
 Finalmente se realiza la reinicialización de los tags de falla (FTO y FT
FTC)
C) cuando llega el comando de reset desde el
HMI (HMI_Reset).

Los comandos de apertura y cierre (tanto desde programa como desde HMI) se autoauto-reinicializan
reinicializan (de forma que
el HMI y/o programa solo se debe preocupar por establecer estos tags cuando se requie
requiera,
ra, pero no de limpiarlos).

7.5 Ejemplo de uso de Lazos en modo Oversampling

Un tipo de aplicación en el cual se puede usar un lazo en modo Oversampling, es por
ejemplo un horno en el cual cada 28 segundos entra un lingote de metal que es movido en
una banda
anda transportadora hacia el horno. Una cámara infraroja toma la temperatura del
lingote a la salida del horno.

En este ejemplo, cada 28 segundos aproximadamente se obtiene un nuevo PV para el

controlador (la temperatura leída por la cámara), pero debido a la naturaleza mecánica de
todo el proceso no es viable usar un controlador en modo periódico usando esta frecuencia.
Para este caso es mejor usa un controlador en modo Oversampling, habilitando la ejecución
de la instrucción cada vez que se obtiene una n
nueva lectura.

Página 178 de 183

 Habilitar visibilidad de EnableIn

Ejecutar la instrucción por medio de

EnableIn: Cablear la señal que indica que
un nuevo PV está disponible

Cablear el tag con el valor del tiempo en que tarda en llegar un

Habilitar visibilidad
nuevo PV (frecuencia de llegada de PVs). O ingrese un valor
de OversampleDT
constante (por ejemplo, 28 segundos)

Figura 200 Ejemplo de uso PIDE en modo Oversampling

8 NOTAS