universidad nacional del centro de la provincia de

UNIVERSIDAD NACIONAL DEL CENTRO DE LA PROVINCIA DE
BUENOS AIRES
FACULTAD DE CIENCIAS EXACTAS
TESIS DE GRADO DE INGENIERIA DE SISTEMAS
Herramienta para el diseño, simulación y generación de código de
sistemas de automatización industrial basados en PLCs.
Autor
Leiva Javier 1
Director
Dr. Luis Sebastián Berdun 2
1 jmaleiva@hotmail.com
2 lberdun@exa.unicen.edu.ar
Tandil, Junio de 2016
Dedicatoria
A mis padres.
A mi esposa Claudia.
A mis hijos Martina y Agustín.
Agradecimientos
A mis padres, por ser el pilar fundamental en todo lo que soy, en toda mi educación, tanto
académica como de la vida, por el sacrificio e incondicional apoyo aún en los momentos
más difíciles.
A mi esposa e hijos, por aguantar mis “ausencias”, el cansancio y todos los momentos para
compartir en familia que no pudieron ser…
A Luis, por su entera predisposición desde el principio, por su paciencia, por haberme
ayudado y guiado para que esto pueda concretarse.
A todos aquellos que me acompañaron durante todos estos años, por su generosa ayuda y
palabras de aliento en los momentos complicados.
A todos aquellos que contribuyeron en mi crecimiento.
A mis compañeros y amigos, por los momentos compartidos.
Índice General
Capítulo 1 - Introducción .............................................................................................. 12
1.1 Definición de Automatismo ............................................................................................ 12
1.2 Clasificación Tecnológica ................................................................................................ 13
1.3 Motivación ..................................................................................................................... 15
1.4 - Trabajo realizado .......................................................................................................... 18
1.5 - Organización del trabajo .............................................................................................. 21
Capítulo 2 - Marco Teórico ........................................................................................... 22
2.1 El Autómata Programable Industrial .............................................................................. 22
2.1.1 Definición ................................................................................................................. 22
2.1.2 Arquitectura del API ................................................................................................. 22
2.1.3 Constitución Física ................................................................................................... 24
2.1.4 Descripción Funcional .............................................................................................. 27
2.1.5 Unidades De Programación .................................................................................... 29
2.1.6 Programación de los Autómatas Programables Industriales.................................. 30
2.1.7 Estándar de programación IEC 61131-3 .................................................................. 30
2.1.7.1 Introducción ...................................................................................................... 30
2.1.7.2 Elementos comunes .......................................................................................... 31
2.1.7.3 Lenguajes de programación .............................................................................. 35
2.1.7.4 Top-down vs. Bottom-Up- ................................................................................. 42
2.1.7.5 Implementaciones ............................................................................................. 42
2.1.7.6 Conclusiones...................................................................................................... 43
2.2 Grafcet ............................................................................................................................ 44
2.2.1 Metodología Grafcet: Conceptos Básicos ............................................................... 45
2.2.2 Etapas ...................................................................................................................... 45
2.2.3 Transición ................................................................................................................ 47
2.2.4 Uniones Orientadas................................................................................................. 48
2.2.5 Reglas de Evolución ................................................................................................. 49
2.2.5.1 Situación Inicial ................................................................................................. 49
2.2.5.2 Franqueo de una Transición ............................................................................. 49
2.2.5.3 Evolución de las Etapas activas ........................................................................ 49
2.2.5.4 Reglas de estructuras de uso frecuente ........................................................... 50
2.2.5.5 Evoluciones Simultáneas .................................................................................. 51
2.2.5.6 Activación y Desactivación Simultánea ............................................................ 51
2.2.6 Estructuras Principales ............................................................................................. 51
2.2.6.1 Secuencia Única ................................................................................................ 52
2.2.6.2 Secuencias Simultáneas: paralelismo estructural ............................................ 52
2.2.6.3 Selección de Secuencia ..................................................................................... 53
2.2.7 Implementación del Grafcet ................................................................................... 54
2.3 Programación Orientada a Objetos ............................................................................... 57
2.4. Trabajos relacionados ................................................................................................... 60
2.4.1 Ámbito de aplicación de S7-GRAPH ......................................................................... 61
2.4.2 Características generales de S7-GRAPH................................................................... 61
2.4.3 Análisis de la Herramienta S7-GRAPH ..................................................................... 63
Capítulo 3 - Solución Propuesta .................................................................................. 65
3.1 Descripción de la Solución Propuesta ............................................................................ 65
3.2 Objetivos de la Solución Propuesta ................................................................................ 66
3.3 Representación General de la solución Propuesta ........................................................ 67
3.4 Diseño del Diagrama Grafcet .......................................................................................... 68
3.5 Programación del Proceso .............................................................................................. 70
3.5.1 Condiciones .............................................................................................................. 71
3.5.2 Lenguaje del Editor .................................................................................................. 74
3.5.3 Direcciones de memoria .......................................................................................... 74
3.5.4 Constantes ............................................................................................................... 75
3.5.5 Juego de instrucciones ............................................................................................. 75
3.6 Simulación del Proceso ................................................................................................... 78
3.7 Generación Automática de Código PLC .......................................................................... 79
Capítulo 4 - Diseño e Implementación ...................................................................... 80
4.1 Arquitectura general....................................................................................................... 80
4.1.1 Modelo ..................................................................................................................... 81
4.1.2 Controlador .............................................................................................................. 82
4.1.3 Vista.......................................................................................................................... 83
4.2 Condiciones .................................................................................................................... 85
4.2.1 Operaciones Lógicas ................................................................................................ 85
4.2.2 Diseño para la representación de condiciones ........................................................ 87
4.2.3 Implementación ....................................................................................................... 89
4.3 Simulación....................................................................................................................... 95
4.3.1 Diseño ...................................................................................................................... 95
4.3.2 Implementación ..................................................................................................... 101
Capítulo 5 - Casos de Estudio ..................................................................................... 104
5.1 Caso de Estudio N° 1 ..................................................................................................... 105
5.1.1 Descripción............................................................................................................. 105
5.1.2 Ciclo de funcionamiento ........................................................................................ 105
5.1.3 Nivel tecnológico ................................................................................................... 106
5.1.4 Implementación con la Herramienta .................................................................... 107
5.2 Caso de Estudio N° 2 ..................................................................................................... 120
5.2.1 Descripción............................................................................................................. 124
5.2.2 Ciclo de funcionamiento ........................................................................................ 126
5.2.3 Implementación con la Herramienta .................................................................... 129
Capítulo 6 - Conclusiones ............................................................................................ 148
6.1 Ventajas ........................................................................................................................ 149
6.2 Limitaciones .................................................................................................................. 150
6.3 Trabajos futuros............................................................................................................ 151
Capítulo 7 - Bibliografía .............................................................................................. 153
Apéndice A ......................................................................................................................... 155
Índice de Figuras
Figura 1.1: Estructura típica de un sistema automatizado ................................................................... 13
Figura 1.2: Función lógica y = a . b + c. .................................................................................................. 16
Figura 1.3: Representación en diagrama de contactos de y = a . b + c. ................................................ 17
Figura 1.4: Representación mediante puertas lógicas y = a . b + c. ...................................................... 17
Figura 1.5: Diagrama de Flujo de un arrancador estrella/triángulo ..................................................... 17
Figura 1.6: Diagrama Grafcet del arrancador estrella/triángulo .......................................................... 18
Figura 1.7: Diagrama general del trabajo realizado ............................................................................. 20
Figura 2.1: Arquitectura de un Autómata Programable Industrial ....................................................... 23
Figura 2.2: Autómata modular CS1 de Omron Electronics (Omron Industrial Automation)................. 24
Figura 2.3: Autómata modular M340 de Schneider Electric (Schneider Electric) ................................ 25
Figura 2.4: Autómata modular S7-300 de Siemens (Siemens, 2001) .................................................... 25
Figura 2.5: Elementos constitutivos de un autómata modular ............................................................. 25
Figura 2.6: Autómata compacto SP1E de Omron Electronics (Omron Industrial Automation) ............ 26
Figura 2.7: Autómata programable compacto M238 de Schneider (Schneider Electric)...................... 26
Figura 2.8: Autómata programable compacto S7-200 de Siemens (Siemens.com) .............................. 26
Figura 2.9: Ciclo de trabajo de un API ................................................................................................... 27
Figura 2.10: Terminal táctil programable KTP 1000 Basic de Siemens ................................................. 30
Figura 2.11: Partes de IEC 61131-3 ....................................................................................................... 31
Figura 2.12: Modelo de Software .......................................................................................................... 32
Figura 2.13: Ejemplo de SFC .................................................................................................................. 34
Figura 2.14: Ejemplo de programa en diagrama de contactos (ladder diagram) ................................. 37
Figura 2.15: Uso de funciones complejas en diagramas de contactos .................................................. 38
Figura 2.16: Representación de instrucciones en Diagrama de contactos (Ladder) ............................. 40
Figura 2.17: Representación en lenguaje de lista de instrucciones ....................................................... 40
Figura 2.18: Representación de instrucciones en listas de instrucciones y lógica de relés ................... 40
Figura 2.19: Representación en lista de instrucciones .......................................................................... 41
Figura 2.20: Representación en diagrama de bloques de funciones ..................................................... 41
Figura 2.21: Desarrollo de aplicaciones IEC 61131-3 ............................................................................ 42
Figura 2.22: Ejemplos de herramienta de desarrollo IEC 61131.3 ........................................................ 43
Figura 2.23: Componentes de un GRAFCET ........................................................................................... 45
Figura 2.24: Componentes de una Etapa .............................................................................................. 45
Figura 2.25: Bifurcación de transiciones ............................................................................................... 46
Figura 2.26: Acción asociada a la etapa 1 (nivel 1): Avance del carro 1 ............................................... 46
Figura 2.27: Acción asociada a la etapa 1 (nivel 2): AC1....................................................................... 46
Figura 2.28: Transición que une la etapa 1 con la etapa 2 ................................................................... 47
Figura 2.29: Representación literal de la receptividad .......................................................................... 48
Figura 2.30: Representación simbólica de la receptividad .................................................................... 48
Figura 2.31: Estados posibles de la Etapa Ei y sus transiciones ............................................................ 50
Figura 2.32: Divergencia en O ............................................................................................................... 50
Figura 2.33: Convergencia en O ............................................................................................................ 50
Figura 2.34: Divergencia en Y ................................................................................................................ 51
Figura 2.35: Convergencia en Y ............................................................................................................. 51
Figura 2.36: Representación de secuencia única................................................................................... 52
Figura 2.37: Representación de secuencia simultánea ......................................................................... 52
Figura 2.38: Representación de secuencia exclusiva ............................................................................. 53
Figura 2.39: Representación de salto de secuencia............................................................................... 53
Figura 2.40: Representación de paralelismo interpretado .................................................................... 54
Figura 2.41: Normalización de Etapas................................................................................................... 55
Figura 2.42: Proceso de normalización mediante la técnica "asociación etapa-biestable".................. 55
Figura 2.43: Condiciones de activación en lenguaje S7-200 con técnica relé de memoria ................... 56
Figura 2.44: Condiciones de activación en lenguaje S7-200 con técnica biestable ............................... 57
Figura 2.45: Bloques de Control Secuencial........................................................................................... 62
Figura 2.46: Ejemplo de una cadena secuencial en S7-GRAPH ............................................................. 63
Figura 3.1: Representación General de la Solución Propuesta .............................................................. 67
Figura 3.2: Edición del diagrama Grafcet .............................................................................................. 68
Figura 3.3: Programación del proceso automático secuencial ............................................................. 70
Figura 3.4: Estructura de Programa con lista de instrucciones ............................................................. 72
Figura 3.5: Representación gráfica de la estructura de programa ....................................................... 73
Figura 3.6: Representación gráfica en Nivel Grafcet ............................................................................. 73
Figura 3.7: Simulación del proceso automático secuencial ................................................................... 78
Figura 3.8: Generación automática de código de bajo nivel ................................................................. 79
Figura 4.1: Arquitectura basado en Modelo Vista Controlador (MVC) ................................................. 80
Figura 4.2: Diagrama de clases del componente Modelo ..................................................................... 81
Figura 4.3: Captura de pantalla de la vista de Grafcet ......................................................................... 85
Figura 4.4: Ejemplo de código representando una condición simple .................................................... 86
Figura 4.5: Representación gráfica una condición simple ..................................................................... 87
Figura 4.6: Diseño para representar las condiciones usando el patrón Composite .............................. 89
Figura 4.7: Diseño de operadores que pueden graficarse a sí mismos ................................................. 90
Figura 4.8: Diseño de operadores usando el patrón Template para graficar ....................................... 91
Figura 4.9: Diseño de operadores reutilizando la funcionalidad para graficar una etapa ................... 92
Figura 4.10: Implementación del método getCondicion() para el operador compuesto ...................... 93
Figura 4.11: Ejemplo de la definición de una condición usando Grafcet .............................................. 94
Figura 4.12: Ejemplo de transición de etapas en una simulación ......................................................... 96
Figura 4.13: Ejemplo de transición de etapas con una bifurcación ....................................................... 97
Figura 4.14: Ejemplo de transición de etapas con una unión................................................................ 98
Figura 4.15: Diseño para la simulación utilizando el patrón Composite ............................................... 99
Figura 4.16: Diagrama de Clases que representan las condiciones para la simulación ...................... 100
Figura 4.17: Código de la clase Etapa para implementar la simulación ............................................. 101
Figura 4.18: Código de la clase Linea para implementar la simulación .............................................. 102
Figura 4.19: Código de la clase Variable para implementar la interpretación de condiciones ........... 102
Figura 4.20: Código de la clase And para implementar la interpretación de condiciones .................. 103
Figura 5.1: Vista simbólica de la taladradora ..................................................................................... 105
Figura 5.2: Grafcet funcional de la taladradora .................................................................................. 106
Figura 5.3: Vista de pantalla de la tabla de símbolos de la Taladradora ............................................ 107
Figura 5.4: Vista de pantalla del diagrama de etapas de la Taladradora .......................................... 108
Figura 5.5: Vista de pantalla de conexiones de etapas del diagrama de la Taladradora ................... 109
Figura 5.6: Vista de pantalla del menú de edición de etapas.............................................................. 110
Figura 5.7: Vista de pantalla del menú de edición de etiquetas ......................................................... 110
Figura 5.8: Vista de pantalla del diagrama con edición de etiquetas ................................................. 111
Figura 5.9: Vista de pantalla del menú acciones de la Taladradora ................................................... 112
Figura 5.10: Vista de pantalla del menú de condiciones de la Taladradora ....................................... 112
Figura 5.11: Vista de pantalla de edición gráfica de una transición de la Taladradora...................... 113
Figura 5.12: Vista de pantalla de condición de transición 0-1 en modo sentencias........................... 113
Figura 5.13: Vista de pantalla de condición de transición 0-1 en modo gráfico ................................ 114
Figura 5.14: Vista de pantalla transcripción de condiciones ............................................................... 114
Figura 5.15: Vista de Pantalla del diagrama Grafcet completo de la Taladradora ............................ 115
Figura 5.16: Vista de pantalla del estado inicial de Simulación .......................................................... 116
Figura 5.17: Vista de pantalla del proceso de simulación de la Taladradora en estado de reposo .... 116
Figura 5.18: Vista de pantalla visualización de condiciones en simulación de la Taladradora ......... 117
Figura 5.19: Vista de pantalla franqueo de la transición 0-1 de la Taladradora ................................ 117
Figura 5.20: Vista de pantalla del proceso con estado inalterable de salto de etapas ....................... 118
Figura 5.21: Vista de pantalla con el código de programa generado automáticamente ................... 119
Figura 5.22: Vista del Procedimiento aplicado anterior al Proyecto de Automatización .................... 121
Figura 5.23: Vista del Procedimiento posterior al Proyecto de Automatización finalizado ................ 121
Figura 5.24: Vista General de la Instalación ........................................................................................ 122
Figura 5.25: Vista del Tablero de Comando General del Automatismo .............................................. 123
Figura 5.26: Vista de un Autoelevador para Transporte de Pallets .................................................... 123
Figura 5.27 Diagrama general de la instalación ................................................................................. 124
Figura 5.28: Componentes del Automatismo del Proceso................................................................... 124
Figura 5.29: Descripción de los componentes para la automatización de la pinza de acopio ............ 125
Figura 5.30: Ejemplo del diseño del automatismo de la pinza ............................................................ 127
Figura 5.31: Fragmento de código de programa en lenguaje de PLC ................................................. 128
Figura 5.32: Vista de pantalla de la tabla de símbolos de la pinza de acopio..................................... 129
Figura 5.33: Diagrama Funcional de Ejecución del ciclo ..................................................................... 130
Figura 5.34: Vista de pantalla con etapas y conexiones del Grafcet de la Pinza de Acopio ................ 131
Figura 5.35: Vista de pantalla con etiquetas en etapas del Grafcet de la Pinza de Acopio ................ 132
Figura 5.36: Vista de pantalla edición gráfica de condición 0-1 del Grafcet de la Pinza de Acopio . 133
Figura 5.37: Vista de pantalla condiciones etapa 0-1 Grafcet de la Pinza de Acopio ........................ 133
Figura 5.38: Vista de pantalla con etiquetas en transiciones Grafcet de la Pinza de Acopio.............. 134
Figura 5.39: Vista de pantalla de edición de acciones Etapa 1 del Grafcet de la Pinza de Acopio ..... 135
Figura 5.40: Vista de pantalla simulación estado de reposo del Grafcet de la Pinza de Acopio ...... 136
Figura 5.41: Vista real de la Pinza de Acopio en estado inicial del ciclo ............................................. 137
Figura 5.42: Vista de pantalla consulta de condición Grafcet de la Pinza de Acopio .......................... 137
Figura 5.43: Vista de pantalla franqueo de transición 0-1 Grafcet de la Pinza de Acopio .................. 138
Figura 5.44: Enhebrado de Uñas de la pinza para carga de pallets .................................................... 138
Figura 5.45: Vista real de la Pinza en Estado de Carga de Pallet ........................................................ 139
Figura 5.46: Vista real de la pinza con el Estado del Sistema en Etapa 2 .......................................... 140
Figura 5.47: Vista real de la pinza con el Estado del Sistema en Etapa 3 ........................................... 140
Figura 5.48: Vista real de la pinza con el Estado del Sistema en Etapa 3 ........................................... 141
Figura 5.49: Vista real de la pinza con el Estado del Sistema en Etapa 6 ........................................... 141
Figura 5.50: Vista real de la pinza con el Estado del Sistema en Etapa 7 ........................................... 142
Figura 5.51: Vista de pantalla Condiciones de Transición 1-2 con Operador OR ................................ 143
Figura 5.52: Vista de la situación con tarimas defectuosas ................................................................ 143
Figura 5.53: Ilustración Incidente provocado por tarimas defectuosas ............................................. 144
Figura 5.54: Vista de pantalla Condiciones de Transición 1-2 con Operador AND ............................. 144
Figura 5.55: Vista de pantalla de la condición de transición 2-3 Grafcet de la Pinza de Acopio ........ 145
Figura 5.56: Ilustración Incidente provocado por sobre- acopio de Pallets........................................ 145
Figura 5.57: Vista de pantalla de la condición de transición 2-3 modificada ..................................... 146
Figura 5.58: Vista de pantalla código de programa generado de la Pinza de Acopio ........................ 147
Figura 6.1: Dinamización del Sistema en Etapa 2: Ascenso veloz en Mesa......................................... 152
Figura 6.2: Dinamización del Sistema en Etapa 3: Traslación Veloz a Boxes ...................................... 152
Figura A- 1: Vista de la Interfaz de edición de Grafcet ........................................................................ 157
Figura A- 2: Vista de pantalla de generación de código ...................................................................... 160
Figura A- 3: Vista de pantalla de asignación de bits ........................................................................... 161
Figura A- 4: Vista de pantalla de tabla de símbolos ............................................................................ 161
Figura A- 5: Vista de pantalla de edición de condiciones .................................................................... 162
Figura A- 6: Vista de pantalla de edición de acciones ......................................................................... 165
Índice de Tablas
Tabla 3.1: Sintaxis de operaciones lógicas con bits ............................................................................... 71
Tabla 3.2: Tipos de área de memoria .................................................................................................... 75
Tabla 3.3: Modificadores de memoria .................................................................................................. 75
Tabla 3.4: Juego de instrucciones básicas de un API Siemens ............................................................... 76
Tabla 3.5: Juego de instrucciones acotadas del proyecto ..................................................................... 77
Introducción
Capítulo 1 - Introducción
En las últimas décadas se ha seguido la tendencia de automatizar de manera
progresiva procesos productivos de todo tipo. Esta tendencia ha sido y sigue siendo posible
gracias al desarrollo y abaratamiento de la tecnología necesaria.
La automatización de los procesos de producción persigue los objetivos de:

Mejorar la calidad y mantener un nivel de calidad uniforme.

Producir las cantidades necesarias en el momento preciso.

Mejorar la productividad y reducir costes.

Hacer más flexible el sistema productivo (facilitar los cambios en la
producción).
Estos objetivos se han convertido de hecho en requisitos indispensables para
mantener la competitividad, por lo que el aumento del nivel de automatización de los
procesos es simplemente una necesidad para sobrevivir en el mercado actual.
Se pueden distinguir varios niveles en la automatización de un proceso productivo:
1.
Nivel de máquina. En este nivel se considera la automatización de una
máquina que realiza una tarea productiva simple determinada.
2.
Nivel de célula (de grupo). En este nivel se considera el control automatizado
de un conjunto de máquinas que trabajan conjunta y coordinadamente para
realizar un proceso de producción más complejo.
3.
Nivel de planta. En este nivel se considera el control automatizado de toda la
planta de producción que trabaja de forma coordinada para cumplir unos
objetivos de producción global de la fábrica.
4.
Nivel de empresa. En este nivel se considera el conjunto de la empresa
(gestión, ventas, producción).
Los niveles 3 y 4 requieren de una red informática que permita el flujo de todos los
datos de la empresa relacionados con la producción y la gestión. En esencia estos niveles se
implementan mediante ordenadores conectados entre sí y con las células de producción del
nivel 2.
En el nivel 2 puede haber una red local de comunicación entre los distintos
elementos de una célula (si las máquinas están muy separadas). La implementación de los
niveles 1 y 2 se realiza mediante sensores, actuadores y equipos de control.
Un automatismo es en esencia una máquina o un proceso automatizado.
Los automatismos definen, por tanto, los niveles 1 y 2.
1.1 Definición de Automatismo
Se define un sistema (máquina o proceso) automatizado como aquel capaz de
reaccionar de forma automática (sin la intervención del operario) ante los cambios que se
producen en el mismo, realizando las acciones adecuadas para cumplir la función para la que
ha sido diseñado (Bolton, 1996).
12
Introducción
Figura 1.1: Estructura típica de un sistema automatizado
La Figura 1.1 muestra la estructura típica de un sistema automatizado (Peñin, Carrera,
& Barrientos, 1999). Como se puede observar, se trata de un sistema en bucle cerrado,
donde la información sobre los cambios del proceso captada por los sensores es procesada
dando lugar a las acciones necesarias, que se implementan físicamente sobre el proceso por
medio de los actuadores. Este sistema de control se comunica eventualmente con el
operador, recibiendo de éste consignas de funcionamiento, tales como marcha, paro,
cambio de características de producción, etc. y comunicándole información sobre el estado
del proceso (para la supervisión del correcto funcionamiento).
Se denomina automatismo al sistema completo, aunque con este término suele
hacerse referencia fundamentalmente al sistema de control, ya que es éste el que produce
de forma automática las acciones sobre el proceso a partir de la información captada por los
sensores. Las señales de entrada y de salida pueden ser de cualquier tipo, sin embargo el
concepto tradicional de automatismo se utiliza para sistemas de eventos discretos (también
llamados sistemas secuenciales) en los que esas señales son binarias, es decir, solo pueden
tomar 2 valores, activa o inactiva (estos valores suelen representarse como un 1 ó un 0). En
ese caso el sistema de control implementa el algoritmo de lógica binaria que relaciona los
valores que van tomando en cada instante las entradas (1 ó 0) con los valores que deben ir
tomando en cada instante las salidas (también 1 ó 0) para que el sistema funcione
adecuadamente.
1.2 Clasificación Tecnológica
En función de la tecnología empleada para la implementación del sistema de control,
se puede distinguir entre automatismos cableados y automatismos programados (Sánchez
Llopis, Romero Pérez, & Ariño Latorre, 2010).
 Automatismos cableados.
Se implementan por medio de uniones físicas entre los elementos que forman
el sistema de control (por ejemplo, contactores y relés unidos entre sí por
cables eléctricos). La estructura de conexionado entre los distintos elementos
da lugar a la función lógica que determina las señales de salida en función de
las señales de entrada. Se pueden distinguir tres tecnologías diferentes:
13
Introducción



Fluidica (neumática o hidráulica).
Eléctrica (relés o contactores).
Electrónica estática (puertas lógicas y biestables).
Los inconvenientes fundamentales de los automatismos cableados son:

Ocupan mucho espacio.

Son muy poco flexibles. La modificación o ampliación es difícil.

Solo permiten funciones lógicas simples. No sirven para implementar
funciones de control o de comunicación complejas.
Las ventajas de los automatismos cableados son:

Pueden ser muy robustos.

Bajo coste para sistemas muy sencillos.

Es una tecnología muy fácil de entender por cualquier operario.

En general se puede afirmar que los automatismos cableados solo
tienen utilidad para resolver problemas muy sencillos (por ejemplo un
arranque estrella-triángulo de un motor de inducción).
 Automatismos programados.
Se implementan por medio de un programa que se ejecuta en un
microprocesador.
Las instrucciones de este programa determinan la función lógica que relaciona
las entradas y las salidas. Se pueden distinguir 3 formas de implementación
 Autómata programable industrial. Hoy por hoy es el que más se utiliza en la
industria. Es un equipo electrónico programable en un lenguaje especifico,
diseñado para controlar en tiempo real y en ambiente de tipo industrial
procesos secuenciales. Se utilizan para el control de máquinas y procesos
(Peñin, Carrera, & Barrientos, 1999). En el Capítulo 2.1 se abordará en
profundidad sobre el mismo ya que representa uno de los dos ejes
principales, junto a los diagramas GRAFCET, del Proceso de automatización
y en particular del presente proyecto.
 Ordenador (PC industrial). Cada vez se utilizan más. Son ordenadores
compatibles con los PC de sobremesa en cuanto a software, pero cuyo
hardware está especialmente diseñado para ser robusto en entornos
industriales.
 Microcontrolador. Son circuitos integrados (“chips”) programables, que
incluyen en su interior un microprocesador y la memoria y los periféricos
necesarios. Para utilizarlos, normalmente se diseña una tarjeta electrónica
específica para la aplicación, que incluye el propio microcontrolador y los
circuitos electrónicos de interfaz necesarios para poder conectarse a los
sensores y actuadores. Se utilizan sobre todo para sistemas de control de
máquinas de las que se van a fabricar muchas unidades, de forma que la
14
Introducción
reducción de coste por el número de unidades fabricadas justifica la mayor
dificultad (y mayor coste) del diseño.
Las ventajas más importantes de los automatismos programados son:
 Permiten una gran flexibilidad para realizar modificaciones o
ampliaciones.
 Permiten implementar funciones de control y de comunicación
complejas.
 Ocupan poco espacio.
Los inconvenientes respecto de los sistemas cableados son fundamentalmente el
mayor coste (solo si el sistema es muy sencillo), la menor robustez y la mayor complejidad
de la tecnología. Sin embargo estos inconvenientes cada vez lo son menos, pues el coste se
reduce continuamente, cada vez se diseñan equipos más robustos, y los sistemas de
programación son cada vez más sencillos.
En resumen, se puede afirmar que la tecnología programada (y en especial los
autómatas programables) es superior a la tecnología cableada, salvo en automatismos que
sean extremadamente simples.
La naturaleza física de las señales de entrada y salida depende de la tecnología del
automatismo. Por ejemplo, un automatismo puramente neumático tiene como entradas
señales de presión de aire, y dan como salida señales depresión de aire. Lo más habitual en
la industria son los automatismos de naturaleza eléctrica (cableados o programados). En
este caso las señales de entrada de salida son señales eléctricas. Los sensores se encargaran
de convertir las magnitudes físicas en señales eléctricas, mientras los actuadores
transforman las señales eléctricas en acciones físicas sobre el proceso.
1.3 Motivación
La automatización de los procesos productivos se establece como una herramienta
fundamental que permite a las empresas un desarrollo propio, dinámico y competitivo,
facilitando la relación entre las diferentes áreas de la organización o empresa. Por lo que es
muy importante encontrar una buena metodología o procedimiento adecuado y eficaz, que
permita a la industria regional, automatizar bienes de producción particularmente con el uso
de PLC´s.
El diseño, la programación y la operación de los sistemas requieren en la mayoría de
los casos de especialistas.
Sin embargo, cuando nos hallamos ante la tarea de automatizar un proceso, nos
encontramos con que la naturaleza de este proceso es, en la mayoría práctica de las
situaciones, secuencial. Una serie de actividades y operaciones a realizar conforme a una
determinada secuencia, que determinan el proceso productivo en sí. A pesar de la elevada
diversidad de tecnologías y dispositivos que puedan estar implicados en la realización de
estas operaciones, desde el punto de vista de automatizar su operación, es esta ordenación
secuencial lo que es importante. De esta forma, se tratará de tener claro, en cada caso, que
es lo que determina que haya terminado una operación (en el fondo, una condición lógica),
así como la actividad a realizar durante esta operación. De hecho, nos estamos refiriendo a
un sistema secuencial, y la automatización de un sistema de este tipo la llevaremos a cabo
15
Introducción
mediante un automatismo que será una combinación de sistema secuencial y combinacional
–secuencia de acciones/operaciones de control reguladas por expresiones lógicas.
Representación de los Automatismos
La función lógica implementada por un automatismo se puede representar de
diversas formas. Las 2 formas tradicionales son la lógica de contactos y las puertas lógicas,
que permiten representar funciones lógicas sencillas. Hay otras formas de representación
del automatismo que están a un nivel superior. Sirven para definir funcionalmente un
automatismo secuencial completo. Entre ellas se pueden destacar los diagramas de flujo y el
GRAFCET (García Higuera, 2005).
Lógica de contactos (de relés)
Las variables binarias se representan mediante contactos que están cerrados o
abiertos según esté activa (1) o inactiva (0) la variable en cuestión. La combinación
(conexión) de contactos en serie y paralelo permite representar una función lógica. Por
ejemplo, la Figura 1.2 representa la función lógica y = a·b+c. (Garzón Vásquez, 2013)
Figura 1.2: Función lógica y = a . b + c.
La línea vertical izquierda representa tensión (por ejemplo 24 V) mientras la línea
vertical derecha representa la masa (0 V). Si a y b están activas los contactos están cerrados,
y la salida (bobina) y queda sometida a 24 V, con lo que se activa. Lo mismo sucede si c está
activa.
El origen de esta representación está en la implementación física mediante
contactores, que fue la primera forma que se utilizó para implementar los automatismos. De
hecho la representación del diagrama de contactos es directamente el cableado de los
contactores. Hoy en día la mayoría de automatismos son programados, sin embargo ésta
sigue siendo la forma más habitual de representar las ecuaciones lógicas de los
automatismos.
La representación de contactos suele utilizar los símbolos de la Figura 1.3, en lugar de
los interruptores.
16
Introducción
Figura 1.3: Representación en diagrama de contactos de y = a . b + c.
Puertas lógicas
La función lógica se representa mediante compuertas lógicas (puertas AND,NAND, OR
y NOR). Por ejemplo, la Figura 1.4 representa la función lógica y = a · b + c.
Es la representación utilizada cuando el automatismo se implementa con circuitos
electrónicos digitales (Hill & Peterson, 1979).
Figura 1.4: Representación mediante puertas lógicas y = a . b + c.
Diagrama de flujo
Es una forma de representación de más alto nivel que las dos anteriores. Consiste en
un diagrama con dos tipos de elementos, los nodos de decisión y los nodos de actuación o
tratamiento. Por ejemplo, el diagrama de flujo de un arrancador estrella-triángulo se puede
representar mediante diagrama de flujo tal y como muestra la Figura 1.5.
Figura 1.5: Diagrama de Flujo de un arrancador estrella/triángulo
17
Introducción
Esta forma de representación de alto nivel explica el funcionamiento del
automatismo. Sin embargo, para la implementación final en el equipo de control(autómata
programable por ejemplo) es necesario traducir el diagrama de flujo a una representación de
bajo nivel (como el diagrama de contactos, por ejemplo)
Grafcet
También se trata de una representación de alto nivel de los automatismos (Boix
Aragonés, Sudía Andreu, & Bergas Jané, 1997). Se llama también diagrama de etapatransición. En esta representación se tienen cuadrados que representan las etapas del
automatismo, y transiciones entre ellas. El ejemplo del arrancador anterior se puede
representar como se muestra en la Figura 1.6:
Figura 1.6: Diagrama Grafcet del arrancador estrella/triángulo
Estas formas de representación del automatismo de alto nivel son muy útiles para
explicar el funcionamiento del proceso y facilitar el diseño. La implementación final, sin
embargo, se hace generalmente con la representación de contactos, por lo que es necesario
traducir estos diagramas a esa forma de representación de bajo nivel. Algunos autómatas
programables industriales permiten ser programados utilizando diagramas GRAFCET de alto
nivel, realizándose de forma automática la traducción al lenguaje de bajo nivel de forma
transparente para el usuario.
En el Capítulo 2.2 Grafcet se abordará esta metodología con nivel de detalle
exhaustivo ya que representa la herramienta más apropiada que nos permita vincular en un
grado de alto nivel el sistema a automatizar con el lenguaje de bajo nivel interpretado por el
Controlador Lógico Programable (PLC).
1.4 - Trabajo realizado
Dada la complejidad que conlleva el diseño de sistemas de Automatización Industrial,
se llevó a cabo una solución que ayude a usuarios inexpertos en el desarrollo de proyectos
que involucren procesos secuenciales, tomando como referencia la representación Grafcet
antes mencionada y aportando herramientas de alto nivel que permitan abstraerse de los
lenguajes propios, de bajo Nivel, de los Autómatas Programables.
18
Introducción
Como resultado del trabajo se generó una herramienta que se integra a un entorno
de desarrollo, la cual permite brindar asistencia para la correcta implementación de los
conceptos analizados.
La aplicación desarrollada permite definir como entrada una lista de elementos
intervinientes en el proceso automático, las variables de proceso, incluyendo una
descripción simbólica de dichos elementos.
Una vez definida la lista anteriormente mencionada, el usuario cuenta con una
interfaz flexible e intuitiva que le permite trasladar el esquema del ciclo del proceso, a una
representación estándar compatible con el funcionamiento del autómata Programable,
basándose en la metodología Grafcet. La herramienta brinda al usuario ciertas
particularidades adicionales en cuanto al concepto de diagramar las condiciones lógicas de
cada punto del ciclo, lo que serían las transiciones entre dos etapas consecutivas del
diagrama Grafcet.
Al finalizar el diseño del proceso mediante la representación Grafcet, el usuario
cuenta con la posibilidad de efectuar la simulación del comportamiento del sistema, a través
de la interacción de forzado de valores de variables, lo que brinda la ventaja de permitir
efectuar todos los cambios necesarios en el desarrollo, antes de implementarse el
automatismo en el propio Autómata programable, evitando así potenciales riesgos de
incidentes que presentaría la prueba real y física.
Una vez efectuadas todas las pruebas de simulación y correcciones/ajustes del
sistema, la herramienta provee la posibilidad de traducir el diseño del diagrama Grafcet al
lenguaje propio del Autómata Programable. En el presente proyecto se ha tomado como
base de lenguaje de programación un idioma específico, correspondiente a un fabricante
particular de Autómatas Programables tal es el caso de Siemens, pero quedará planteado
como posible trabajo futuro, ampliar el espectro a un mayor número de lenguajes
específicos de acuerdo a los distintos fabricantes aprovechando la flexibilidad del diseño e
implementación de la herramienta.
En la Figura 1.7 se observa la representación de la herramienta, compuesta de tres
módulos bien definidos, y cómo los usuarios acceden a la misma a través de una interfaz
intuitiva que permitirá desarrollar un sistema de automatización Industrial sin requerir
conocimientos expertos de la lógica de bajo nivel utilizada por un Autómata Programable.
19
Introducción
Figura 1.7: Diagrama general del trabajo realizado
20
Introducción
1.5 - Organización del trabajo
A continuación se detalla la estructura general del presente trabajo dando una breve
descripción de los temas que se abordarán en cada capítulo.
En el capítulo 2 se van a describir varios conceptos importantes, tales como la
descripción de los sistemas de dispositivos intervinientes para llevar a cabo las tareas de
automatización de procesos industriales, tal el caso de Autómatas Programables (PLCs) con
algún ejemplo concreto de equipos de existencia en el mercado actual. También se
describirá la herramienta de representación de Automatismos (GRAFCET) con las ventajas
pertinentes que ofrece en el modelado de un sistema de proceso secuencial. Estos
apartados serán necesarios para poder comprender el alcance de la aplicación y los
beneficios que brinda para atacar los problemas de diseño en el desarrollo de un sistema de
aplicación de automatismos industriales. También se mostrarán algunos sistemas
comerciales relacionados al área con sus respectivas ventajas y limitaciones.
Luego, en el Capítulo 3 se explicará cuál es la solución propuesta, describiendo el
diseño arquitectónico de la herramienta desarrollada, el entorno sobre el cual se ejecuta y
las principales características de la misma. También, en dicho capítulo, se presentará la
estructura del sistema, incluyendo su funcionamiento general.
A lo largo del Capítulo 4 se va a detallar el diseño de la aplicación desarrollada, para
ello se mostrará el esquema general de la misma y luego se explicarán en detalle cada uno
de sus módulos.
En el Capítulo 5 se exhibirá el aspecto práctico del asistente a través de casos de
estudio realizados, los cuales permitirán demostrar el funcionamiento del mismo. Se
presentarán dos casos de estudio, donde se mostrará la ejecución de la aplicación en
ambientes simulados. En uno de ellos se describirá un caso concreto y real, realizado en una
Planta Industrial, y el cual se encuentra operativo
Finalmente en el Capítulo 6 se realizará un resumen de la elaboración del trabajo, a
partir de la misma se presentará una conclusión, exponiendo las principales ventajas y
marcando las limitaciones, de las cuales derivan posibles trabajos futuros.
21
Marco Teórico
Capítulo 2 - Marco Teórico
Este capítulo tiene por objetivo posicionar el trabajo en el contexto de los conceptos
y Nociones del área de Automatismos Industriales. Con este fin se presenta en primer lugar
una explicación acerca de los dispositivos Autómatas Programables Industriales en general.
Luego, se realiza una descripción de una de las herramientas de representación de
Automatismos, tal es el caso de Grafcet como representación de alto nivel de los mismos.
2.1 El Autómata Programable Industrial
A continuación nos enfocaremos en el análisis detallado de lo que es un Autómata
Programable Industrial (API), desde su arquitectura física hasta los lenguajes soportados
para la programación de los Automatismos.
2.1.1 Definición
Un autómata programable industrial (API) es un equipo electrónico, programable en
lenguaje no informático, diseñado para controlar en tiempo reala en ambiente de tipo
industrial procesos secuenciales (Clements-Jewery & Jeffcoat, 1996); (Karl-Heinz &
Tiegelkamp, 2001).
El autómata programable también se conoce como PLC, que es la sigla de
Programmable Logic Controller. Tal y como se resume en la definición, se trata de un
computador especial, tanto en el software como en el hardware. En el software, porque se
programa en un lenguaje especial diseñado específicamente para generar de forma sencilla
el programa que implementa el algoritmo de control de procesos secuenciales (de sistemas
de eventos discretos), y porque el algoritmo de control programado es ejecutado de forma
periódica en un ciclo temporal que es lo bastante breve como para poder controlar los
procesos entiempo real. En el hardware, porque utiliza componentes robustos que soportan
condiciones de trabajo adversas, como las que se dan en ambientes industriales (polvo,
temperatura, vibraciones, etc.), y porque su constitución física incluye los circuitos de
interfaz necesarios para conectarlo de forma directa a los sensores y actuadores del proceso.
2.1.2 Arquitectura del API
La Figura 2.1 muestra de forma esquemática la arquitectura interna de un autómata
programable industrial típico. Como computador que es, tiene un procesador que es el que
ejecuta el programa almacenado en la memoria de programa. La memoria de programa y la
de datos están físicamente separadas, constituyendo una arquitectura tipo Harvard.
Además, la memoria de datos está separada en dos tipos, que en la figura se denominan
memoria de datos y memoria interna. Esta última se utiliza para almacenar los valores de las
señales de entrada y salida, por lo que están conectadas con los módulos de entradas y
salidas, que son los elementos de interfaz donde se conectan los sensores y actuadores del
proceso. También dispone de periféricos para comunicar con otros dispositivos, como
pantallas táctiles, ordenadores u otros autómatas.
22
Marco Teórico
Figura 2.1: Arquitectura de un Autómata Programable Industrial
Tipos de memoria. Clasificación física
Antes de describir cómo es cada uno de los bloques de memoria que se pueden
encontrar en un autómata programable, presentamos un pequeño resúmen de los tipos de
memoria existentes desde el punto de vista de su constitución física:

Memoria RAM (Random Acces Memory ). Es una memoria volátil, es decir,
que se borra si se quita la alimentación. Se puede distinguir entre RAM
estática (que permanece mientras no se quite la alimentación) y RAM
dinámica, que se va borrando aunque se mantenga la alimentación, por lo que
requiere de un sistema que refresque (vuelva a grabar) los valores que
almacena cada cierto tiempo. La memoria RAM de los PC es de este tipo. La
memoria RAM utilizada en los autómatas programables suele ser estática.

Memoria RAM con batería. La batería mantiene los datos aunque se apague la
alimentación. Es bastante usual en los autómatas programables para
mantener el programa y algunos datos críticos aunque se quite la
alimentación. El inconveniente que tienen es que la batería se tiene que
cambiar cada cierto tiempo (varios años).

Memoria ROM (Read Only Memory ). Grabable sólo una vez en
fábrica(cuando se fabrica el chip). No se puede borrar.

Memoria PROM (Programmable Read Only Memory ). Grabable sólo una vez,
pero se graba después de fabricar el chip (la puede grabar el propio usuario).
Se llama también OTP (One Time Programmable) PROM. Una vez programada
no se puede borrar.

Memoria EPROM (Electrically Programmable Read Only Memory ). Es una
memoria no volátil (no se borra aunque se quite la alimentación),pero que,
además, se puede borrar con luz ultravioleta y volver a grabar eléctricamente.
23
Marco Teórico

Memoria EEPROM (Electrically Erasable and Programmable Read Only
Memory ). Es una memoria no volátil, es decir, que no se borra si sequita la
alimentación, pero que es grabable y borrable eléctricamente. La memoria
FLASH EEPROM es una memoria de este tipo. Cada vez se utiliza más,
sustituyendo a la RAM con batería, ya que no necesita batería para mantener
el programa, y éste se puede modificar.
Bloques de memoria en un API. Clasificación funcional
A continuación se describen los bloques de memoria que suelen tener los autómatas
programables industriales, incluyendo el tipo de memoria física y su función:
 Memoria de programa. Contiene el programa (instrucciones) que se ejecutan
en el procesador. Se puede dividir en dos partes:
 Una parte ROM que contiene el programa monitor (para comunicar el
autómata con los módulos de programación). Este programa monitor es fijo.
 Una parte RAM con batería (puede ser también FLASH EEPROM)en la que se
almacena el programa del usuario, que implementa el algoritmo de control
del proceso. Evidentemente, este programa se mantiene aunque se
desconecte el autómata.
 Memoria interna. Almacena los valores de entradas y salidas, además de otras
variables internas del autómata. En ella se almacenan variables de 1 solo bit,
es decir, variables que, aunque estén organizadas en bytes(grupos de 8 bits),
se puede acceder a cada uno de los bits de forma independiente para leer o
escribir. En esta zona de memoria se leen los valores de las entradas (donde
están conectados los sensores), y se escriben los valores de las salidas (donde
están conectados los actuadores).
 Memoria de datos. Contiene datos de configuración o parámetros de
funcionamiento del autómata y del proceso, o datos de propósito general. En
ella se almacenan variables tipo byte (8 bits) o word (16 bits).
Tanto la memoria interna como la de datos suelen tener una parte de RAM normal
(volátil) y una parte de RAM con batería o EEPROM para almacenar datos que no se deben
perder cuando se desconecta el autómata.
2.1.3 Constitución Física
La mayoría de autómatas programables del mercado son modulares, es decir, están
formados por módulos que pueden conectarse entre sí, permitiendo una gran flexibilidad en
la configuración. Las Figura 2.2, Figura 2.3 y Figura 2.4 muestran algunos de los autómatas
modulares comerciales.
Figura 2.2: Autómata modular CS1 de Omron Electronics (Omron Industrial Automation)
24
Marco Teórico
Figura 2.3: Autómata modular M340 de Schneider Electric (Schneider Electric)
Figura 2.4: Autómata modular S7-300 de Siemens (Siemens, 2001)
El módulo principal es el de CPU, que contiene el procesador, la memoriay algunos
controladoresde periféricos (puerto serie, por ejemplo). En algunosmodelos, el módulo de
CPU contiene además algunas entradas y/o salidasdigitales.
El módulo de fuente de alimentación da la tensión (normalmente 24 V) para
alimentar a todos los módulos del equipo. Junto con el módulo de CPU forman la estructura
mínima necesaria. A veces hay módulos que requieren una fuente de alimentación especial,
además de la general del equipo. En la Figura 2.5 se aprecian todos los elementos que
constituyen un autómata modular.
Figura 2.5: Elementos constitutivos de un autómata modular
Los módulos adicionales se conectan al módulo de CPU por medio del bus. Respecto
de los módulos entre los que se puede elegir para definir la configuración necesaria para
controlar un proceso, se pueden distinguir:
 Módulos de entradas digitales.
 Módulos de salidas digitales.
 Módulos de entradas analógicas.
 Módulos de salidas analógicas.
 Módulos de comunicación (RS232, RS485, Devicenet, Profibus, Ethernet,etc.).
25
Marco Teórico


Módulos de control PID.
Módulos de control de posición de ejes.
También hay autómatas que se denominan compactos, que incluyen en un único
elemento, la fuente de alimentación, la CPU y algunas entradas y salidas digitales y/o
analógicas, además de algún puerto de comunicación. Estos no son tan flexibles, aunque en
algunos casos también admiten la ampliación de entradas o salidas digitales, pero en cambio
son más baratos y pueden ser la mejor solución para aplicaciones sencillas. Las Figura 2.6,
Figura 2.7 y Figura 2.8 muestran algunos autómatas compactos comerciales.
Figura 2.6: Autómata compacto SP1E de Omron Electronics (Omron Industrial Automation)
Figura 2.7: Autómata programable compacto M238 de Schneider (Schneider Electric)
Figura 2.8: Autómata programable compacto S7-200 de Siemens (Siemens.com)
26
Marco Teórico
2.1.4 Descripción Funcional
El API es un computador, y por lo tanto, su funcionamiento consiste en la ejecución
de un determinado programa almacenado en la memoria de programa. Se puede distinguir
dos modos de funcionamiento: modo de programación y modo de ejecución.
 Modo de programación. En este modo de funcionamiento el programa
monitor que reside en la parte ROM de la memoria de programa comunica el
API con el elemento de programación (normalmente un PC), para que desde
éste se le trasvase el programa que implementa el algoritmo de control que
se desea ejecutar. En este modo, el API no está controlando el proceso.

Modo de ejecución (modo RUN). En este modo, se ejecuta el programa del
usuario que implementa al algoritmo de control, con lo que el autómata
controla el proceso. En este modo, cuando se inicializa el autómata, el
programa monitor salta a la dirección donde está el programa de control, y se
empieza a ejecutar éste. La ejecución del programa de control se lleva a cabo
de forma cíclica, ejecutando ciclos de scan de forma indefinida
Ciclo de trabajo o de Scan
Se llama ciclo de trabajo (o de scan) al conjunto de tareas que el autómata lleva a
cabo (instrucciones que se ejecutan) de forma cíclica cuando está controlando un proceso. El
ciclo de trabajo más habitual tiene la estructura de la Figura 2.9.
Figura 2.9: Ciclo de trabajo de un API


La inicialización se lleva a cabo una sola vez siempre que se pone en marcha el
Autómata.
Los procesos comunes son funciones de autodiagnóstico y de programación del
WatchDog (perro guardián). No dependen del proceso que se esté controlando. El
perro guardián es un temporizador de seguridad que se utiliza para detectar bucles
infinitos en el programa de control. Cada ciclo de scan, ese temporizador se borra,
por lo que vuelve a empezar a contar desde cero. Si pasa demasiado tiempo y el
temporizador no es borrado, éste llega al final de cuenta, y produce un error de bucle
infinito. Tiempos típicos del periodo máximo del perro guardián están del orden de
los 100 ms.
27
Marco Teórico

La gestión de periféricos gestiona los puertos de comunicaciones (comunicación con
un ordenador, con un terminal HMI, con otro autómata, etc.)

El programa de usuario se ejecuta instrucción a instrucción, de forma secuencial. Las
instrucciones (líneas) del programa de usuario son las que implementan la lógica de
control del proceso. Todas estas instrucciones se ejecutan utilizando los valores
almacenados en la memoria interna de entradas, y dan como resultado un cambio en
la memoria interna de salidas.

El refresco de E/S significa la actualización de la memoria interna de entradas con los
valores actuales de las entradas (de los sensores), y la actualización de las salidas
(actuadores) con los valores almacenados en la memoria interna de salidas. Esto
quiere decir que si en medio de un ciclo de scan cambia el estado de un sensor, ese
cambio no tendrá ningún efecto en el programa hasta que se ejecute este bloque de
refresco de entradas y salidas. De la misma forma, aunque el programa de usuario
modifique el valor de una salida, ese cambio no llegará al actuador correspondiente
hasta que se ejecute el bloque de refresco de E/S.
El tiempo de scan es el tiempo que tarda el autómata en realizar un ciclo completo.
Este depende de la velocidad de la CPU, que se puede medir mediante el tiempo de
ejecución de una instrucción de la CPU (que depende del tipo de instrucción) o por el tiempo
que tarda en ejecutar 1024instrucciones, y de la longitud del programa de usuario. Valores
típicos del tiempo de scan están en el orden de varios milisegundos.
El tiempo total de un ciclo de trabajo para un autómata determinado es variable, en
función del tamaño (número de instrucciones) del programa de usuario. Incluso para un
mismo programa de usuario, el tiempo de scan puede variar en función de las instrucciones
que se ejecuten, pues puede haber instrucciones de salto o instrucciones condicionadas que
no siempre se ejecutan.
Se define el tiempo de respuesta como el tiempo que tarda en cambiar una salida en
relación al cambio de una entrada. Este tiempo es importante, pues determina la rapidez
con que el autómata reacciona ante cambios del proceso. El tiempo de respuesta es variable
y depende del tiempo de scan, del tiempo de retraso de activación/desactivación de los
dispositivos físicos de entradas y salidas, y del momento en que se produce el cambio de la
entrada.
El peor caso es aquel en el que la entrada cambia justo después de que se haya
refrescado la memoria interna de entradas. En ese caso, se ejecuta un ciclo de programa
completo en el que el nuevo valor de esa entrada no es tenido en cuenta. Después se
actualiza la memoria de entradas, con lo que se lee el valor de la entrada. A continuación, se
ejecuta otro ciclo de programa en el que el nuevo valor de la entrada sí se tiene en cuenta,
para después actualizar las salidas. El tiempo de respuesta máximo es, pues:
Trespmax = 2Tciclo + Tout
28
Marco Teórico
dondeTout es el tiempo que tarda el dispositivo físico de salida en activar realmente la salida,
y que depende del tipo de salida (relé, transistor o triac).
2.1.5 Unidades De Programación
Las unidades de programación son los periféricos más comunes que se utilizan al
trabajar con los API. Estas unidades son las que permiten introducir en la memoria del
autómata el programa de usuario que servirá para controlar el proceso. Las más utilizadas
son: la consola de programación y el PC.
Consola de programación
La consola de programación es un dispositivo específico para programar el autómata.
Consta de un incómodo teclado y una pequeña pantalla. Se comunica con el autómata por
medio del puerto serie o de un puerto especial de periféricos (situados en el módulo de
CPU). Introducir programas mediante la consola resulta engorroso y lento. Normalmente
tienen utilidad para realizar pequeñas modificaciones en los programas de autómatas que ya
están instalados en planta, debido a que son de pequeño tamaño (cómodos de transportar)y
se alimentan directamente del autómata.
Ordenador personal
El elemento más utilizado para programar los API es el ordenador personal. Se
conecta al autómata mediante el puerto serie RS232 o un puerto USB (normalmente). Cada
fabricante de autómatas dispone de un software que permite la edición de programas, la
depuración, la compilación y la carga del mismo en el autómata. También permite ejecutar
el programa en el autómata y tener acceso al mismo tiempo a las distintas variables, lo que
permite la depuración y detección de errores.
Unidades HMI
Además de las unidades de programación, podemos destacar otros periféricos muy
utilizados que son las unidades HMI (Human Machine Interface). Son unidades que disponen
de un teclado y una pantalla (que puede ser bastante grande), o bien únicamente de una
pantalla táctil. Se utilizan para mostrar al operador el estado del proceso y permitir la
introducción de consignas (órdenes de marcha, de paro, cambio de parámetros de
funcionamiento, etc.). Estas unidades contienen un procesador y una memoria no volátil en
la que se programa la aplicación de interfaz con el usuario. Se programan por medio de un
ordenador por el puerto serie o un puerto USB con el software adecuado, y una vez
programadas se comunican con el autómata por el puerto serie o por el puerto de
periféricos (aunque también se pueden comunicar por medio de una red de mayor nivel,
como Ethernet). En la Figura 2.10 se muestra un terminal táctil comercial.
29
Marco Teórico
Figura 2.10: Terminal táctil programable KTP 1000 Basic de Siemens
2.1.6 Programación de los Autómatas Programables Industriales
La forma más común de programar un autómata es mediante un ordenador personal
con el software adecuado. En primer lugar se debe configurar el equipo (seleccionar el tipo
de autómata y los módulos de entradas/salidas que se tiene). Después se introduce el
programa de control (en el lenguaje adecuado), y por último, se carga este programa en el
autómata para proceder a su verificación (se ejecuta el programa comprobando la evolución
de las distintas variables).
Antes de introducir el programa es conveniente hacer una lista de las variables de
entrada y salida del proceso, y su asignación a variables internas en la memoria del
autómata. Algunos software de programación permiten simularla ejecución del programa sin
necesidad de cargarlo en un autómata, por lo que se puede hacer la depuración de forma
más sencilla.
2.1.7 Estándar de programación IEC 61131-3
En este apartado desarrollaremos la norma que estandariza los lenguajes de
programación independientemente del fabricante, ya sea en el manejo de datos, variables y
programas.
2.1.7.1 Introducción
IEC 61131-3 es la base real para estandarizar los lenguajes de programación en la
Automatización industrial, haciendo el trabajo independiente de cualquier compañía (KarlHeinz & Tiegelkamp, 2001).
30
Marco Teórico
Hay muchas maneras de describir el trabajo desarrollado en la tercera parte de esta
norma, algunas de ellas son:
 IEC 61131-3 es el resultado del gran esfuerzo realizado por 7 multinacionales con
muchos años de experiencia en el campo de la automatización industrial.
 Incluye 200 páginas de texto aproximadamente, con más de 60 tablas.
 IEC 61131-3 define las especificaciones de la sintaxis y semántica de los lenguajes de
programación de PLCs, incluyendo el modelo de software y la estructura del lenguaje.
La parte 3 del estándar presenta dos grandes bloques temáticos (ver Figura 2.11):


Elementos comunes.
Lenguajes de programación.
Figura 2.11: Partes de IEC 61131-3
2.1.7.2 Elementos comunes
Tipos de datos
Dentro de los elementos comunes, se definen los tipos de datos. Los tipos de datos
previenen de errores en una fase inicial, como por ejemplo la división de un dato tipo fecha
por un número entero.
Los tipos comunes de datos son: variables booleanas, número entero, número real,
byte y palabra, pero también fechas, horas del día y cadenas (strings).
Basado en estos tipos de datos, el usuario puede definir sus propios tipos de datos,
conocidos como tipos de datos derivados. De este modo, se puede definir por ejemplo un
tipo de dato denominado “canal de entrada analógica”.
Variables
Las variables permiten identificar los objetos de datos cuyos contenidos pueden
cambiar, por ejemplo, los datos asociados a entradas, salidas o a la memoria del autómata
programable. Una variable se puede declarar como uno de los tipos de datos elementales
31
Marco Teórico
definidos o como uno de los tipos de datos derivados. De este modo se crea un alto nivel de
independencia con el hardware, favoreciendo la reusabilidad del software.
El ámbito de “vida” de una variable está normalmente limitado a la unidad de
organización en la cual ha sido declarada (variable local). Esto significa que sus nombres
pueden ser reutilizados en otras partes sin conflictos, eliminando una frecuente fuente de
errores. Si las variables deben tener un ámbito de “validez” superior, han de ser declaradas
como globales utilizando la palabra reservada VAR_GLOBAL.
Pueden ser asignados parámetros y valores iniciales que se restablecen al inicio, para
obtener la configuración inicial correcta.
Configuración, recursos y tareas
La norma IEC 61131-3 define un modelo software representado en la Figura 2.12.
Figura 2.12: Modelo de Software
Al más alto nivel, el elemento software requerido para solucionar un problema de
control particular puede ser formulado como una configuración. Una configuración es
específica para un tipo de sistema de control e incluye las características del hardware:
procesadores, direccionamiento de la memoria para los canales de I/O y otras capacidades
del sistema. El concepto abstracto “configuración” puede ser asimilado a un tipo de PLC
dado.
Dentro de una configuración, se pueden definir uno o más recursos. Se puede
entender el recurso como un procesador capaz de ejecutar programas de control escritos en
los lenguajes que define la norma. Dado que una configuración puede tener tantos recursos
como se desee, se puede decir que la norma permite definir PLCs con tantas CPUs como se
quiera.
En el seno de un recurso pueden ser definidas una o más tareas. Las tareas controlan
la ejecución de un conjunto de programas y/o bloques funcionales. Cada una de ellos puede
32
Marco Teórico
ser ejecutada periódicamente o por una señal de disparo especificada, como el cambio de
estado de una variable.
Comparado este modelo con un PLC convencional, éste último contiene un solo
recurso, ejecutando una única tarea que controla un único programa de manera cíclica. IEC
61131-3 brinda la posibilidad de disponer de estructuras más complejas. Así sería posible
soportar multi-procesamiento, gestión de programas por eventos sistemas de control
distribuido o en tiempo real con este estándar.
Unidades de Organización de Programa
La norma define tres formas distintas de “presentar” o crear programas de control
para PLCs, a saber:
♦ Programas.
♦ Funciones.
♦ Bloques funcionales.
Estas presentaciones reciben el nombre de “POUs (Unidades de Organización de
Programa). Los POUs serán diseñados a partir de un diferente número de elementos de
software, escritos en alguno de los distintos lenguajes definidos en la norma. Típicamente,
un programa es una interacción de Funciones y Bloques Funcionales, con capacidad para
intercambiar datos. Funciones y bloques funcionales son las partes básicas de construcción
de un programa, que contienen una declaración de datos y variables y un conjunto de
instrucciones.
Programas
La norma define un programa como el “conjunto lógico de todos los elementos y
construcciones que son necesarios para el tratamiento de señales que se requiere para el
control de una máquina o proceso mediante un PLC”.
Es decir, que un programa puede contener la declaración de tipos de datos, variables
e instancias de bloques funcionales junto con el conjunto de instrucciones (código o
programa propiamente dicho) necesario para llevar a cabo el control deseado del proceso o
máquina.
Funciones
IEC 61131-3 especifica funciones estándar y funciones definidas por el usuario. Las
funciones estándar son por ejemplo ADD (suma), ABS (valor absoluto), SQRT (raíz cuadrada),
SIN (seno), y COS (coseno). Las funciones definidas por el usuario, una vez implementadas
pueden ser usadas indefinidamente en cualquier POU (Karl-Heinz & Tiegelkamp, 2001).
Las funciones no pueden contener ninguna información de estado interno, es decir,
que la invocación de una función varias veces con los mismos argumentos (parámetros de
entrada) debe suministrar siempre el mismo resultado (salida).
33
Marco Teórico
Bloques Funcionales, FB´s
Los bloques funcionales son los equivalentes de los circuitos integrados usados en
electrónica, IC´s, que representan funciones de control especializadas. Los FB´s contienen
tanto datos como instrucciones, pudiendo guardar los valores de dichas variables entre
sucesivas ejecuciones (que es una de las diferencias con las funciones). Se dice por tanto que
los FBs tienen “memoria”, característica que les confiere un gran potencial de uso.
Presentan una interfaz de entradas y salidas bien definida y un código interno oculto,
como un circuito integrado o una caja negra. De este modo, establecen una clara separación
entre los diferentes niveles de programadores, o el personal de mantenimiento. Un lazo de
control de temperatura, PID, es un excelente ejemplo de bloque funcional. Una vez definido,
puede ser usado una y otra vez, en el mismo programa, en diferentes programas o en
distintos proyectos. Esto lo hace altamente reutilizable.
Los bloques funcionales pueden ser definidos por el usuario empleando alguno de los
lenguajes de la norma, pero también existen FB´s estándar (biestables, detección de flancos,
contadores, temporizadores, etc.).
Otra de las diferencias fundamentales con respecto a las funciones y que les confiere
gran potencia de uso, es la posibilidad de crear tantas copias como se desee de un mismo
FB. A cada copia se le llama instancia. Cada instancia llevará asociado un identificador y una
estructura de datos que contenga sus variables de entrada, de salida e internas separada del
resto de instancias.
Gráfico Funcional Secuencial (Secuential Function Chart, SFC)
Figura 2.13: Ejemplo de SFC
Como muestra la Figura 2.13 SFC describe gráficamente el comportamiento
secuencial de un programa de control. Esta definición deriva de las Redes de Petri y
GRAFCET (IEC 60848), con las modificaciones adecuadas para convertir las representaciones
de una norma de documentación (o de un lenguaje de modelado) en un conjunto de
elementos de control de ejecución para una POU de un autómata programable (o sea, en un
lenguaje de programación).
SFC ayuda a estructurar la organización interna de un programa, y a descomponer un
problema en partes manejables, manteniendo simultáneamente una visión global. Los
elementos de SFC proporcionan un medio para subdividir una POU de un autómata
programable en un conjunto de etapas y transiciones interconectadas. Cada etapa lleva
asociados un conjunto bloques de acción y cada transición va asociada con una condición
34
Marco Teórico
que cuando se cumple, causa la desactivación de la etapa anterior a la transición y la
activación de la siguiente. Los bloques de acción permiten realizar el control del proceso.
Cada elemento puede ser programado en alguno de los lenguajes de la norma, incluyéndose
el propio SFC. Dado que el modo de funcionamiento de SFC requiere que la información
almacenada acerca de cuál es la etapa activa se mantenga entre llamadas sucesivas, los
únicos POUs que se pueden programar utilizando SFC son los bloques funcionales y los
programas.
Se pueden usar secuencias alternativas y paralelas, comúnmente utilizadas en
muchas aplicaciones. Debido a su estructura general, de sencilla comprensión, SFC permite
la transmisión de información entre distintas personas con distintos niveles de preparación y
responsabilidad dentro de la empresa de manera sencilla e intuitiva.
2.1.7.3 Lenguajes de programación
Cada fabricante de autómatas programables tiene su propia versión del lenguaje de
diagrama de contactos y del de lista de instrucciones. En general, un programa escrito para
un autómata determinado no sirve para un autómata de otra marca. Las diferencias más
importantes están en las instrucciones y funciones especiales, que cada fabricante
implementa a su manera (especialmente temporizadores y contadores), aunque también
hay diferencias en elementos más simples, como bobinas de enclavamiento.
La norma IEC 61131-3 surgió con el objetivo de establecer una sintaxis de
programación estándar que permitiera programar un automatismo sin necesidad de recurrir
a la sintaxis específica de ningún fabricante. El objetivo último es, evidentemente, que el
programa escrito según la norma IEC 1131-3se pueda utilizar directamente en cualquier
autómata.
Cada vez son más los fabricantes cuyos sistemas de programación se acogen a este
estándar. Además, recientemente han aparecido paquetes de software de programación de
autómatas basados en este estándar, cuyo objetivo es poder realizar programas
independientemente de la marca del autómata que se vaya a utilizar.
El estándar IEC 61131-3 contempla seis lenguajes diferentes, tres basados en gráfico
y tres basados en texto. Los lenguajes basados en gráfico son:

Diagrama de contactos o de escalera. Es muy similar al de cualquier autómata,
aunque hay diferencias. Por ejemplo el lenguaje de Omron utiliza solo contactos NA o
NC, mientras la norma IEC 61131-3 admite además contactos de flanco de subida o
de bajada que se activan solo durante un ciclo de scan cuando la variable asociada
cambia de 0 a 1 o de 1 a 0.

Diagrama de bloque de funciones. Dispone de cuatro tipos de elementos gráficos que
se combinan para la creación de un programa. Estos elementos son: conexiones,
elementos de control de ejecución, elementos para llamada a funciones y los
conectores. No se incluyen otros elementos gráficos como contactos y bobinas que sí
aparecen en los diagramas de contactos.
35
Marco Teórico

Diagrama secuencial de funciones (modo gráfico). Permite descomponer programas
complejos en unidades más simples y definir la forma en que se realizan las
transiciones entre estas unidades. Su apariencia es similar a la de los diagramas de
Grafcet, pues cuenta con dos tipos de elementos: las etapas (o pasos), representadas
por cuadrados, y las transiciones, representadas por líneas horizontales, a las que se
le asocia una condición de activación. Dentro de cada paso o etapa se incluye el
código de programa(usando cualquiera de los lenguajes definidos en la norma) que
se ejecutará cuando se active dicha etapa.
Los lenguajes basados en texto son:

Lista de instrucciones. Es similar a un lenguaje ensamblador. En general, los
programas creados con otros lenguajes, gráficos o de texto, son traducidos a listas de
instrucciones en el proceso de compilación.

Texto estructurado. Es un lenguaje de programación de alto nivel que ofrece un
amplio rango de instrucciones que simplifican la realización de operaciones
complejas.

Diagrama secuencial de funciones (modo texto).
En este apartado se explicarán solo algunos lenguajes (de mayor uso frecuente)
dentro de los cuales están los basados en gráficos como Diagrama de contactos o de
escalera, y Diagrama de bloques de funciones, y dentro del grupo de lenguajes basados en
texto, la Lista de Instrucciones. Asimismo es importante aclarar que solo nos limitaremos a
explicar las distintas metodologías de representación de lenguajes de los Autómatas
Programables, sin hacer referencia al detalle de direccionamiento y sintaxis de las variables
ya que no representa el objetivo principal del presente documento.
Diagrama de contactos (Ladder Diagram o diagrama de escalera)
Es el lenguaje de programación más utilizado en los autómatas programables. Está
basado en los automatismos cableados por medio de contactores, que fueron los primeros
en implementarse. Gráficamente se representan dos líneas verticales largas separadas, de
forma que la de la izquierda representa tensión y la de la derecha, masa. Entre esas líneas
verticales, se representan las ecuaciones lógicas por medio de contactos. Hay 3 tipos de
elementos fundamentales:

Contacto normalmente abierto (NA): Representa un contacto que está abierto si la
variable asociada vale 0, y que se cierra si la variable asociada vale 1. Se representa
con dos líneas verticales paralelas.
36
Marco Teórico

Contacto normalmente cerrado (NC): Representa un contacto que está cerrado si la
variable asociada vale 0, y que se abre si la variable asociada vale 1. Se representa
con dos líneas verticales paralelas cruzadas por una línea oblicua.

Bobina. Representa el valor de una variable. Cada salida tiene asociada una bobina. Si
esta bobina tiene corriente (el diagrama de contactos la activa), la salida está a 1, y si
no tiene corriente, la salida está a cero. Además puede haber bobinas asociadas a
variables internas (por ejemplo, las que representan cada etapa del proceso). Se
representa mediante un círculo.
Figura 2.14: Ejemplo de programa en diagrama de contactos (ladder diagram)
Cada línea o red (que normalmente contiene una sola bobina, aunque puede
contener varias) representa una línea del programa. El autómata ejecuta las líneas de arriba
abajo. En el caso del ejemplo de la Figura 2.14, calcularía y *¬b+ay el resultado (1 ó 0) lo
asignaría a la variable y. Después calcularía a*¬y, y el resultado lo asignaría a la variable x.
Esta sería la fase de ejecución del programa de usuario, que se repetiría de forma cíclica
según se ha visto.
La función lógica implementada por los contactos de una red se suele denominar
condición de activación, ya que cuando esta condición es 1, la variable de salida (bobina)
asociada se activa.
Hay una serie de reglas que se debe seguir para dibujar correctamente un diagrama
de contactos. Algunas de ellas son:
 A la derecha de la bobina no puede haber contactos.
 En una red puede haber varias bobinas en paralelo.
 La conducción a través de los contactos solo se produce de izquierda a
derecha.
Además de la bobina simple puede haber otros dos tipos de bobinas:

Bobina normalmente cerrada. Se representa mediante un círculo con una
línea transversal (en el caso de Autómatas Omron). Su valor es el inverso del
que resulta de la ecuación lógica de los contactos.

Bobina de enclavamiento. En algunos autómatas se representa mediante un
círculo que en el interior tiene una letra L, de Latch (o S de Set ) o una letra U,
de Unlatch (o R, de Reset ). Si es una letra L (Latch) o S(Set ) indica que la
37
Marco Teórico
variable correspondiente se activa, quedando activa aunque después se haga
cero la condición de activación. Para desactivarla variable tiene que utilizarse
una bobina de desenclavamiento con la letra U (Unlatch) o R (Reset ).
Esos elementos básicos solo permiten programar relaciones lógicas simples.
Evidentemente esto no es suficiente para controlar un proceso complejo. Además de estos
elementos hay otros que permiten implementar funciones más elaboradas. Se colocan en
lugar de las bobinas simples, tal como se muestra en la Figura 2.15.
Figura 2.15: Uso de funciones complejas en diagramas de contactos
El significado es que cuando el autómata llega a la línea correspondiente, ejecuta la
instrucción o función compleja en función de que los contactos den un valor 1 ´o 0, es decir,
en función de que la condición de activación sea 1 ó 0. En algunos casos, si dan un valor 0 la
función no se ejecuta, en otros, la ejecución es diferente en función de que se tenga un 1 o
un 0. Entre estas funciones se puede destacar:









Instrucción END. Indica el final del programa.
Temporizadores.
Contadores.
Instrucciones de salto.
Operaciones binarias (mover bytes, sumar, multiplicar, comparar, etc.).
Refresco de E/S. Permite refrescar las E/S cuando se desee,
independientemente del refresco automático que se produce cada ciclo de
scan.
Funciones matemáticas complejas (senos, cosenos, exponenciales).
Control de interrupciones.
Funciones especiales de comunicaciones (transmisión o recepción de datos).
Lista de Instrucciones
Es otro lenguaje muy utilizado. Este es un lenguaje de aspecto similar al
ensamblador, aunque no se codifican instrucciones de código máquina del procesador. El
programa se expresa en una lista de instrucciones muy básicas.
Cada instrucción contiene un nemónico (el nombre de la instrucción) y uno o varios
datos con los que opera. Estos datos pueden ser un bit o una palabra (registro de 8 ó 16
bits). El conjunto de instrucciones disponible y la nomenclatura utilizada depende del
fabricante del autómata.
38
Marco Teórico
Hay una serie de instrucciones básicas que permiten implementar las ecuaciones
lógicas equivalentes al diagrama de relés. Citaremos como ejemplo las operaciones lógicas
con bits.
Las operaciones lógicas con bits operan con dos dígitos, 1 y 0. Estos dos dígitos
constituyen la base de un sistema numérico denominado sistema binario. Los dos dígitos 1 y
0 se denominan dígitos binarios o bits. En el ámbito de los contactos y bobinas, un 1 significa
activado (”conductor”) y un 0 significa desactivado (”no conductor”).
Las operaciones lógicas con bits interpretan los estados de señal 1 y 0, y los combinan
de acuerdo con la lógica de Boole. Estas combinaciones producen un 1 ó un 0 como
resultado y se denominan ”resultado lógico” (RLO). Las operaciones lógicas con bits
permiten ejecutar las más diversas funciones.
Las operaciones básicas para las operaciones lógicas con bits, en Autómatas Siemens
de la Línea S7-300 son (Siemens, 2001):
•U
• UN
•O
• ON
•X
• XN
Y
Y-No
O
O-No
O-exclusiva
O-exclusiva-No
Las siguientes operaciones permiten ejecutar una cadena lógica encerrada entre
paréntesis:
• U(
Y con abrir paréntesis
• UN(
Y-No con abrir paréntesis
• O(
O con abrir paréntesis
• ON(
O-No con abrir paréntesis
• X(
O-exclusiva con abrir paréntesis
• XN(
O-exclusiva-NO con abrir paréntesis
•)
Cerrar paréntesis
Para terminar una cadena lógica se puede utilizar una de las tres operaciones:
•=
Asignar
•R
Desactivar
•S
Activar
Las operaciones siguientes permiten modificar el resultado lógico (RLO):
• NOT Negar el RLO
• SET Activar el RLO (=1)
• CLR Desactivar RLO (=0)
• SAVE Memorizar el RLO en el registro RB
Otras operaciones detectan cambios en el resultado lógico y reaccionan
correspondientemente:
• FN Flanco negativo
• FP Flanco positivo
39
Marco Teórico
Con estas instrucciones se puede escribir la ecuación lógica de una red. Por ejemplo,
tomando como partida el diagrama ladder de la Figura 2.16:
Figura 2.16: Representación de instrucciones en Diagrama de contactos (Ladder)
La lista de instrucciones de Siemens equivalente se muestra en la Figura 2.17
UN
E 0.0
U
E 0.1
O
U
E 0.0
UN
E 0.1
=
A 4.0
Figura 2.17: Representación en lenguaje de lista de instrucciones
La salida A 4.0 es "1" si (E 0.0 es 0 Y E 0.1 es 1) O (E 0.0 es 1 Y E 0.1 es 0).
Del mismo modo se puede representar la equivalencia entre el Lenguaje de listas de
instrucciones (AWL de Siemens) y la representación en lógica de relés.
Figura 2.18: Representación de instrucciones en listas de instrucciones y lógica de relés
De acuerdo a la Figura 2.18 se puede determinar que la corriente puede fluir si:
el estado en la entrada E 1.0 es "1" Y el estado en la entrada E 1.1 es "0".
Diagrama de bloque de funciones
Dispone de cuatro tipos de elementos Gráficos que se combinan para la creación de
un programa. Estos elementos son: conexiones, elementos de control de ejecución,
elementos para llamada a funciones y los conectores. No se incluyen otros elementos
gráficos como contactos y bobinas que sí aparecen en los diagramas de contactos.
Se dispone de las operaciones lógicas con bits siguientes:
40
Marco Teórico
•#
• XOR
• >=1
•&
•=
: Conector
: Operación lógica O-exclusiva
: Operación lógica O
: Operación lógica Y
: Asignación
Las siguientes operaciones reaccionan ante un RLO de 1:
•R
: Desactivar salida
•S
: Activar salida
• RS : Flipflop de desactivación/activación
• SR : Flipflop de activación/desactivación
Otras operaciones reaccionan ante un cambio de flanco positivo o negativo para ejecutar las
siguientes funciones:
•N
: Detectar flanco negativo (1 -> 0)
•P
: Detectar flanco positivo (0 -> 1)
• NEG : Detectar flanco de señal 1 -> 0
• POS : Detectar flanco de señal 0 -> 1
Las restantes operaciones afectan directamente al RLO:
• Insertar una entrada binaria
• Invertir una entrada binaria
• SAVE : Cargar resultado lógico (RLO) en el registro RB
Con estas instrucciones se puede escribir la ecuación lógica de una red. Por ejemplo,
tomando como partida el segmento de programa en lista de instrucciones de Siemens de la
Figura 2.19 el equivalente en diagrama de bloques de funciones se muestra en la Figura 2.20
U
E 1.0
U
E 1.1
O
U
E 1.2
U
E 1.3
=
A 3.1
Figura 2.19: Representación en lista de instrucciones
Figura 2.20: Representación en diagrama de bloques de funciones
41
Marco Teórico
2.1.7.4 Top-down vs. Bottom-Up-
Figura 2.21: Desarrollo de aplicaciones IEC 61131-3
La norma define dos formas de desarrollar los programas de control, tal como se
puede apreciar en la Figura 2.21: de arriba abajo (Top-down) y de abajo a arriba (bottom-up).
Se puede especificar inicialmente la aplicación completa y dividirla en partes, declarar las
variables y demás. O también se puede comenzar la programación desde abajo, por ejemplo,
por medio de funciones y bloque funcionales que resuelvan problemas concretos. Estas
funciones y bloques funcionales adecuadamente combinados podrán ser encapsulados en
funciones o bloques funcionales que a su vez podrán ser empleados para resolver problemas
más complejos, y así hasta resolver el problema en su totalidad.
2.1.7.5 Implementaciones
Cumplir todos los requerimientos de la norma IEC 61131-3 no es fácil, por eso se
permiten implementaciones parciales en varios aspectos. Esto hace referencia al número de
lenguajes que soportan las herramientas de desarrollo disponibles, y al número de funciones
y de bloques funcionales. Con ello se deja libertad al suministrador, pero el usuario debe
tener cuidado durante el proceso de selección de la herramienta adecuada. Incluso una
actualización del software puede dar lugar a una carga de trabajo mayo durante la
implementación.
Muchos entornos de programación IEC actuales ofrecen aquello que se espera a nivel
de interface de usuario: uso de ratón, menús desplegables, pantallas de programación
gráfica, múltiples ventanas, ayuda en línea, verificación durante el diseño, etc. Debe hacerse
notar que estos detalles no están especificados en la norma por lo que es una de las partes
donde los proveedores pueden diferenciarse, por citar el caso de la Figura 2.22.
42
Marco Teórico
Figura 2.22: Ejemplos de herramienta de desarrollo IEC 61131.3
2.1.7.6 Conclusiones
Las implicaciones técnicas de la norma IEC 61131-3 son altas, dejando bastante
espacio para el crecimiento y la diferenciación. Esto la hace adecuada para el mercado
futuro.
La norma IEC 61131-3 tendrá un gran impacto en el mundo del control industrial y
éste no se restringe al mercado convencional de los PLC´s. Ahora mismo, se puede ver
adoptada en aplicaciones para control de movimiento, sistemas distribuidos y sistemas de
control basados en PC (SoftPLC), incluyendo los paquetes SCADA. Y las áreas de su utilización
siguen creciendo.
El uso de IEC 61131-3 proporciona numerosos beneficios para
usuarios/programadores. Los beneficios de la adopción de este estándar son varios,
dependiendo de las áreas de aplicación: control de procesos, integrador de sistemas,
educación, programación, mantenimiento, instalación, etc. Entre estos beneficios cabe
destacar:
1. Se reduce el gasto en recursos humanos, formación, mantenimiento y consultoría.
2. Evita las fuentes habituales de problemas por el alto nivel de flexibilidad y
reusabilidad del software.
3. Las técnicas de programación son utilizables en amplios sectores (control industrial
en general).
4. Combinan adecuadamente diferentes elementos que pueden provenir de diferentes
fabricantes, programas, proyectos...
5. Incrementa la conectividad y comunicación entre los distintos departamentos y
compañías.
43
Marco Teórico
2.2 Grafcet
La creciente complejidad de los automatismos industriales se traduce en una mayor
dificultad para definir de una manera clara y sin ambigüedades las especificaciones
funcionales a las que debe responder. Esta dificultad se ve agravada por la utilización de un
gran número de informaciones de entrada y salida.
Las distintas formas de descripción de un proceso podrían ser clasificadas en los
distintos grupos:
 Una descripción literal únicamente resulta larga, incomoda, a veces imprecisa
y, a menudo incompleta.

Una descripción lógica (logigrama) está casi exclusivamente enfocado a una
tecnología determinada, y no es apropiada a la realización mediante
programa.

Una representación por organigrama, más general, se adapta bien a las
realizaciones mediante programa, pero resulta pobre en el caso de los
secuenciales y no muestra los funcionamientos simultáneos, caso de que los
haya.
Los trabajos realizados en los últimos años, han conducido a representaciones
gráficas de las especificaciones funcionales que son totalmente independientes de la
realización tecnológica, pudiendo ésta ser cableada (módulos neumáticos, relés
electromecánicos o módulos electrónicos) o programada (PLC, ordenador o
microprocesador).
Estas nuevas formas de representación se basan en los conceptos de etapa y de
receptividad que simplifica en gran medida la síntesis de los automatismos secuenciales, al
considerar el hecho de que, entre el gran número de informaciones disponibles, pocas son
significativas en un determinado momento.
A partir de estas ideas, los trabajos efectuados por las comisiones de AFCET
(Association Française pour la Cybernétique Economique et Technique, Asociación Francesa
para la cibernética económica y técnica) y de ADEPA, (Agence Nationale pour le
Developpment de la Production Automatisée, Agencia nacional para el desarrollo de la
producción automatizada) han dado como resultado la definición de un diagrama funcional:
el GRAFCET, (Graphe de Comands Etape/Transition, gráfico de mando etapa/transición)
(Boix Aragonés, Sudía Andreu, & Bergas Jané, 1997).
Este diagrama funcional permite describir los comportamientos del automatismo en
relación a las informaciones que recibe, imponiendo un funcionamiento riguroso, evitando
de esta forma incoherencias, bloqueos o conflictos en el funcionamiento. En cada nivel de
descripción, este diagrama puede ser modificado o corregido, sin necesidad de volver a
partes ya estudiadas.
Inicialmente fue propuesto para documentar la etapa secuencial de los sistemas de
control de procesos a eventos discretos. No fue concebido como un lenguaje de
programación de autómatas, sino un tipo de Grafo para elaborar el modelo pensando en la
ejecución directa del automatismo o programa de autómata. Varios fabricantes en sus
44
Marco Teórico
autómatas de gama alta hacen este paso directo, lo que lo ha convertido en un potente
lenguaje gráfico de programación para autómatas, adaptado a la resolución de sistemas
secuenciales. En la actualidad no tiene una amplia difusión como lenguaje, puesto que la
mayoría de los autómatas no pueden programarse directamente en este lenguaje, a
diferencia del Lenguaje Diagrama de contactos (ladder). Pero se ha universalizado como
herramienta de modelado que permite el paso directo a programación, también con Ladder.
2.2.1 Metodología Grafcet: Conceptos Básicos
Como se muestra en la Figura 2.23, el Grafcet se compone de un conjunto de (Gómez
Crespo, 1999) :
 Etapas o Estados a las que van asociadas acciones.
 Transiciones a las que van asociadas receptividades.
 Uniones Orientadas que unen las etapas a las transiciones y las transiciones a
las etapas.
Figura 2.23: Componentes de un GRAFCET
2.2.2 Etapas
Una etapa se caracteriza por un comportamiento invariable en una parte o en la
totalidad de la parte de mando.
En un momento determinado, y según sea la evolución del sistema:
 Una etapa puede estar activa o inactiva.
 El conjunto de las etapas activas definen la situación de la parte de mando.
Las etapas se representan por un cuadrado con un número en su parte superior
como identificación. La entrada y salida de una etapa aparece en la parte superior e inferior,
respectivamente, de cada símbolo. El conjunto formado por el cuadrado y la extensión de las
entradas y salidas constituye el símbolo completo de la etapa (Figura 2.24)
Figura 2.24: Componentes de una Etapa
45
Marco Teórico
Cuando varias transiciones van unidas a una misma etapa, las uniones orientadas
correspondientes se reagrupan antes o después de la etapa tal como se muestra en la
Figura 2.25
Figura 2.25: Bifurcación de transiciones
Acciones asociadas a las etapas
Las acciones están descritas, literal o simbólicamente, en el interior de uno o varios
rectángulos unidos al símbolo de la etapa a la que van asociados.
Tanto las acciones asociadas a las etapas como las receptividades asociadas a las
transiciones se pueden describir a dos niveles:
 Nivel 1: no tienen en cuenta los elementos tecnológicos que implementan el
órgano operativo y sólo se atienden a las especificaciones de tipo funcional.
Se trata de describir las funciones del sistema tal como se muestra en el
ejemplo de la Figura 2.26
Figura 2.26: Acción asociada a la etapa 1 (nivel 1):
Avance del carro 1
 Nivel 2: se especifican los aspectos tecnológicos del órgano operativo y de lo
que le rodea y de las especificaciones operacionales del órgano de control
como se representa en la Figura 2.27.
Figura 2.27: Acción asociada a la etapa 1 (nivel 2): AC1
46
Marco Teórico
Cuando las acciones están descritas en forma simbólica, debe haber una tabla con la
relación entre cada símbolo utilizado y la acción a ejecutar. Para el ejemplo anterior debería
existir algo como:
AC1: Avance del Carro 1
2.2.3 Transición
Una transición indica la posibilidad de evolución entre etapas. Esta evolución se
consuma al producirse el franqueo de la transición. El franqueo de una transición provoca el
paso en la parte de mando de una situación a otra situación.
Una transición puede estar validada o no validada. Se dice que está validada cuando
todas las etapas inmediatamente unidas a esta transición están activas.
Una transición entre dos etapas se representa mediante una línea perpendicular a las
uniones orientadas, también puede llevar una línea paralela a las uniones orientadas. Para
facilitar la comprensión del Grafcet cada transición puede ir numerada a la izquierda de la
línea perpendicular, como se muestra en la Figura 2.28.
Figura 2.28: Transición que une la etapa 1 con la etapa 2
Receptividad asociada a la transición
A cada transición va asociada una proposición lógica llamada receptividad que puede
evaluada a verdadero o falso. Entre todas las informaciones disponibles en un momento
determinado, la receptividad agrupa solamente aquellas que son necesarias para el
franqueo de la transición. La receptividad es función de informaciones externas (entradas) o
internas (estado de contadores, temporizadores, estados activos o inactivos de otras
etapas).
Las entradas de la parte de mando corresponden a las informaciones externas
provenientes de la parte operativa, de consignas dadas por el operador, o de informaciones
de otros sistemas.
La receptividad va escrita literal o simbólicamente, preferentemente a la derecha del
símbolo de la transición, como se puede graficar en la Figura 2.29
47
Marco Teórico
Figura 2.29: Representación literal de la receptividad
Figura 2.30: Representación simbólica de la receptividad
Cuando la receptividad está escrita en forma simbólica, una tabla debe dar la
correspondencia entre cada símbolo utilizado y la información correspondiente. En el
ejemplo anterior de la Figura 2.30:
Aci: Señal Arranque
Cuando no hay condición asociada a una transición, se dice que la receptividad es
verdadera siempre y se escribe =1.
2.2.4 Uniones Orientadas
Las uniones orientadas unen las etapas a las transiciones y las transiciones a las
etapas. Señalan el camino de las evoluciones.
Las uniones orientadas se representan mediante líneas horizontales o verticales. Las
líneas oblicuas pueden ser empleadas excepcionalmente siempre que añadan claridad al
diagrama. Por convenio, el sentido de las evoluciones en un Grafcet es de arriba hacia abajo.
Las flechas se utilizan para señalar la orientación de las uniones:
 Cuando no se respeta el convenio.
 En casos especiales, siempre que su presencia aporte claridad y facilite la
comprensión de las evoluciones del Grafcet.
48
Marco Teórico
2.2.5 Reglas de Evolución
Cuando se dibuja un GRAFCET, se pretende describir un automatismo o cualquier
otro conjunto de sucesos condicionales y secuenciales. Al hacer trabajar este GRAFCET (es
decir, al llevarlo a la práctica) se deben respetar unas reglas (reglas de evolución) ya que, en
caso contrario, el funcionamiento del automatismo o del conjunto de sucesos no sería el que
cabría esperar a la vista del GRAFCET representado.
2.2.5.1 Situación Inicial
La situación inicial del Grafcet caracteriza el comportamiento inicial de la parte de
mando en relación a la parte operativa, y corresponde a las etapas activas al comienzo del
funcionamiento. Si esta situación es siempre la misma, caso de los automatismos cíclicos,
estará caracterizada por las etapas iniciales. Este caso corresponde a un comportamiento
reposo.
En el caso de automatismos no cíclicos, la situación de partida depende del estado
del proceso en el momento de la puesta en marcha de la parte de mando. La forma de
establecer la situación inicial debe ser definida en el Grafcet o en documentación adjunta.
2.2.5.2 Franqueo de una Transición
La evolución de la situación del Grafcet correspondiente al franqueo de una transición no
puede producirse más que:


Cuando esta transición está validada y
Cuando la receptividad asociada a esa transición es cierta.
Cuando estas dos condiciones se cumplen, la transición es franqueable y entonces es
franqueada obligatoriamente.
2.2.5.3 Evolución de las Etapas activas
El franqueo de una transición trae como consecuencia la activación simultánea de
todas las etapas inmediatamente posteriores y la desactivación de todas las etapas
inmediatamente anteriores. Esto se puede apreciar en el diagrama de la Figura 2.31:
49
Marco Teórico
Figura 2.31: Estados posibles de la Etapa Ei y sus transiciones
2.2.5.4 Reglas de estructuras de uso frecuente
 Divergencia en O:
Figura 2.32: Divergencia en O
Cuando la etapa 1 está activa, según se cumpla la receptividad asociada a la
transición a o la receptividad asociada a la transición b, pasará a ser activa la
etapa 2 o bien la etapa 3 respectivamente (Figura 2.32).

Convergencia en O:
Figura 2.33: Convergencia en O
Si la etapa activa es la 2 debe cumplirse la receptividad asociada a la
transición a para pasar a la etapa 4 a activa. Si la etapa activa es la 3 debe
cumplirse la receptividad asociada a la transición b, para que la etapa 4 pase a
estar activa (Figura 2.33).
50
Marco Teórico

Divergencia en Y:
Figura 2.34: Divergencia en Y
Estando activa la etapa 1 y si se cumple la receptividad asociada a la transición
C, pasan a estar activas las etapas 2 y 3 (Figura 2.34).
 Convergencia en Y:
Figura 2.35: Convergencia en Y
Para que se activa la etapa 4 deben estar activas las etapas 2 y 3 y cumplirse la
receptividad asociada a la transición D (Figura 2.35).
2.2.5.5 Evoluciones Simultáneas
Varias transiciones que son franqueables simultáneamente, son simultáneamente
franqueadas. Esta regla de franqueo simultáneo permite descomponer el Grafcet en varios
diagramas, especificando claramente sus interconexiones. En este caso, es indispensable
hacer intervenir, en las receptividades los estados activos de las etapas.
2.2.5.6 Activación y Desactivación Simultánea
Si en el curso del funcionamiento de un automatismo una etapa debe ser desactivada
y activada simultáneamente, ésta seguirá activa.
2.2.6 Estructuras Principales
Las estructuras de base más utilizadas se describen a continuación. Pueden
combinarse entre ellas, siendo esta enumeración no limitativa.
51
Marco Teórico
2.2.6.1 Secuencia Única
Una secuencia única se compone de una sucesión de etapas que son activadas una a
continuación de otra. A cada Etapa le sigue solamente una transición y cada transición es
validada por una sola etapa, tal como se puede apreciar en la Figura 2.36.
Figura 2.36: Representación de secuencia única
Se dice que la secuencia está activa si al menos lo está una etapa. Por el contrario se
dice que está inactiva si todas las etapas están inactivas.
2.2.6.2 Secuencias Simultáneas: paralelismo estructural
Cuando el franqueo de una transición conduce a la activación de varias secuencias al
mismo tiempo, se dice que son secuencias simultáneas. Después de la activación de estas
secuencias, las evoluciones de las etapas activas en cada una de las secuencias son
independientes. Para asegurar la sincronización de la desactivación de varias secuencias al
mismo tiempo, generalmente se ponen etapas de espera recíproca. Un ejemplo de esta
secuencia es representada en la Figura 2.37.
Figura 2.37: Representación de secuencia simultánea
Las activaciones o desactivaciones simultáneas de estas secuencias pueden
efectuarse en una o varias veces.
52
Marco Teórico
2.2.6.3 Selección de Secuencia
Una selección de secuencia, o una elección de evolución entre varias etapas o
secuencias se presenta a partir de una o varias etapas, mediante tantas transiciones
validadas como evoluciones posibles haya, es el caso de la divergencias en O.

Secuencias exclusivas. Para obtener una selección exclusiva entre varias
evoluciones posibles a partir de una misma etapa, es necesario asegurar que
todas las receptividades asociadas a las transiciones son exclusivas es decir,
no pueden ser verdaderas simultáneamente. Este exclusión puede ser de
orden físico (incompatibilidad mecánica o temporal), o de orden lógico (en la
escritura de las receptividades). En la Figura 2.38 se muestra un ejemplo de
este caso
Figura 2.38: Representación de secuencia exclusiva

Salto de etapas y repetición de secuencia. El salto de etapas permite saltar
una o varias etapas, por ejemplo, cuando las acciones a efectuar por estas
etapas, lleguen a ser inútiles o no tengan objeto. Por el contrario, la
repetición de secuencia, permite volver a comenzar la misma secuencia
mientras que una condición establecida no sea cumplida. Un claro ejemplo se
puede apreciar en la Figura 2.39.
Figura 2.39: Representación de salto de secuencia
53
Marco Teórico

Paralelismo Interpretado. Cuando las receptividades asociadas a las
transiciones validadas por una o varias etapas no son exclusivas, pueden
producirse evaluaciones simultáneas que activan varias etapas a la vez. Este
segundo tipo de paralelismo se llama paralelismo interpretado, tal como se
ejemplifica en la Figura 2.40.
·
Figura 2.40: Representación de paralelismo interpretado
2.2.7 Implementación del Grafcet
Una vez realizado el Grafcet del proceso que deseamos controlar, el paso siguiente es
la obtención de las condiciones de activación de las etapas, así como de las acciones
asociadas a las mismas. Para ello se utilizará un proceso de normalización en el cual, y
partiendo del Grafcet realizado, vamos obteniendo las condiciones de activación para cada
una de las etapas y acciones. La obtención de estas condiciones booleanas se basará en la
utilización de dos hechos:
 Una etapa se activará cuando estando activa la etapa inmediatamente
anterior a ella, se evalúe a cierto la receptividad existente entre estas dos
etapas, desactivándose la etapa anterior y activándose la nueva etapa.
 Una acción se deberá ejecutar, si la etapa a la que está asociada está activa.
Una vez obtenidas estas condiciones booleanas, el paso siguiente es la
implementación en el lenguaje apropiado para el controlador que se haya escogido como
unidad de control del proceso. Un ejemplo de normalización de etapas y acciones es
representado en la Figura 2.41.
54
Marco Teórico
Figura 2.41: Normalización de Etapas
La etapa 2 se activará cuando estando activa la etapa 1 se verifique la receptividad a
y dejará de estar activa cuando se active la etapa 3, la cual se activará cuando estando activa
la etapa 2 se verifique b. Basándonos en esto, y mediante un proceso de normalización
podemos llegar a la condición booleana que debe verificarse para la etapa 2. Esta condición
es la siguiente (X es nombre de la etapa):
X2 = /X3.(X1.a+X2)
Accion B = X2
La representación gráfica de este proceso de normalización mediante la técnica
“asociación etapa-biestable” sería la que se muestra en la Figura 2.42.
Figura 2.42: Proceso de normalización mediante la técnica "asociación etapa-biestable"
En el bloque and (&), que está conectado al set de la etapa, se representan las
condiciones de activación de la etapa, mientas, que al reset de la etapa, se conectan las
condiciones de desactivación de la etapa. En el bloque correspondiente a la acción se
conectan las etapas en las cuales se estaría ejecutando la acción, en nuestro caso la etapa 2.
A continuación se expondrá como realizar la implementación de estas condiciones,
como ejemplo, con los controladores Simatic S7-200 de Siemens.
Para controlar el proceso mediante Simatic S7-200, basándose en el Grafcet
construido, lo que se hace es asociar a cada etapa un elemento de memoria que permita
55
Marco Teórico
saber si la etapa está activada o no. En el caso del presente trabajo, a cada etapa del Grafcet
se le ha asociado una marca interna del autómata, de tal manera que la marca estará puesta
a un 1 lógico si la etapa que tiene asociada está activa, y un 0 lógico en otro caso.
Para controlar el proceso se realiza un programa escrito en cualquiera de los dos
lenguajes de programación del S7-200 (esquema de contactos, lista de instrucciones), que se
ejecuta constantemente en el autómata. El programa a construir no es más que la
implementación de la secuencia de condiciones booleanas que definen la activacióndesactivación de las etapas así como de las condiciones asociadas a estas, halladas durante
el proceso de normalización posterior a la construcción del Grafcet.
El programa examina en cada ciclo de ejecución las entradas al autómata (entradas
del proceso), y en función de las condiciones de activación-desactivación de las etapas activa
estas. En el programa también están implementadas las condiciones de ejecución de las
acciones, y en función de la etapa o etapas que estén activadas produce salidas dirigidas al
proceso a controlar.
Las condiciones de activación de las etapas obtenidas en el proceso de normalización
son condiciones que se basan principalmente en operaciones booleanas AND y OR, por lo
que la implementación de este tipo de condiciones en cualquiera de los lenguajes de
programación del S7-200 es bastante fácil.
En el ejemplo visto anteriormente la implementación de las condiciones de activación
de la etapa 2, y de la acción asociada a esta etapa resultaría de la forma representada en la
Figura 2.43, si utilizamos la técnica relé-memoria.
Figura 2.43: Condiciones de activación en lenguaje S7-200 con técnica relé de memoria
Si por el contrario utilizamos la técnica etapa-biestable la implementación resultante
sería la que se representa en la Figura 2.44.
56
Marco Teórico
Figura 2.44: Condiciones de activación en lenguaje S7-200 con técnica biestable
2.3 Programación Orientada a Objetos
La Programación orientada a objetos (POO) es un paradigma de programación que
utiliza como elemento base a los objetos (Wirfs-Brock & McKean, 2003). Los objetos son
entidades que poseen propiedades específicas propias, un estado, tienen un determinado
comportamiento y pueden interactuar con otros objetos. Una combinación de estas
entidades resulta en el desarrollo de un programa informático.
La idea de este paradigma surge en la década del 60, con la intención de poder
diseñar sistemas de software de manera similar a lo que uno hace en la vida real. Es decir,
todas las personas utilizan objetos con un propósito específico, dependiendo de la
circunstancia, sabiendo que tienen determinadas propiedades. De esta manera, el desarrollo
de aplicaciones resulta más intuitivo y, además, POO provee características que son muy
deseadas en una aplicación (Korson & McGregor, 1990).
Antes de mencionar las características más importantes, es necesario revisar
conceptos que son esenciales a POO:
 Clase: es un elemento de software que define un tipo de dato abstracto, es decir,
describe todas las propiedades (atributos) y funcionalidad (métodos) que va a tener
un objeto de esa clase.

Objeto: es una instanciación de una clase. Es decir, asume todas las funcionalidades
definidas por una clase, y les otorga valores a cada una de las propiedades,
definiendo así su propio estado. A su vez, todos los objetos tienen identidad (un
nombre que los representa) y se relaciona con otros objetos.
57
Marco Teórico

Atributo: es un elemento de software que define una propiedad de una clase y el
estado de un objeto. Cada atributo, a su vez, tiene sus propias características como
cualquier objeto.

Método: es una porción de código que implementa cierta funcionalidad de una clase.
Los objetos se comunican entre sí a través de llamados o invocaciones a métodos,
para delegarse cierta responsabilidad o tarea.

Interfaz: este componente define el comportamiento con el que tiene que cumplir
una clase. Es un elemento aún más abstracto que una clase, que exige que estas
tengan definido cierto comportamiento. Este concepto está muy relacionado con el
concepto de herencia, y le da mayor estructuración al código ya que se obliga a
cumplir con un determinado formato.

Métodos de acceso (Accessor Method): son aquellos métodos que se encargan de
acceder a los atributos de una clase, o sea, que permiten leerlos o modificarlos. Esto
está muy relacionado con el principio de encapsulamiento (ver más abajo).

Acoplamiento: se refiere a la dependencia que tiene una clase sobre otra. Si una
clase tiene que comunicarse mucho con otra para poder resolver una determinada
funcionalidad, se entiende que depende mucho de dicha clase y que tiene un alto
nivel de acoplamiento. Si, por el contrario, la funcionalidad se resuelve a nivel
interno, y no se realizan muchas invocaciones de métodos externos, el acoplamiento
es bajo.

Cohesión: se entiende por cohesión al nivel de calidad que tiene la relación entre dos
clases. Es decir, si una clase delega sólo aquella responsabilidad que corresponde a
otra, la calidad resulta ser muy buena y, entonces, la cohesión es muy alta. Si, caso
contrario, se delega mucha responsabilidad a otras clases cuando lo correcto es que
la propia clase se encargue de hacerlo, se entiende que la relación no es de buena
calidad, y la cohesión es baja.
Si bien son muchos los términos que se manejan en un entorno de POO, ésos son los
conceptos fundamentales y más utilizados. Por otro lado, es sabido que POO cuenta con
muchas características que lo distinguen del resto de los paradigmas de programación, como
la programación estructurada. Las siguientes son las características más importantes de
POO:

Encapsulamiento: si bien en el entorno de la programación estructurada ya se
manejaba este término, con el uso de variables locales o globales, en POO toma una
mayor importancia. La idea principal que reside en POO es el diseño de un conjunto
58
Marco Teórico
de objetos que se relacionen entre sí para poder realizar una determinada tarea. De
esta manera, todas las propiedades o atributos de un objeto van a poder ser
accedidas por el mismo objeto, y sólo se puede acceder a ellos externamente a
través de los, ya mencionados, métodos de acceso. Luego, la manera en que se
comunican los objetos es a través de los métodos definidos por cada uno.

Abstracción: este concepto es una de las bases de POO, dado que la idea original es
que todos los objetos abstraigan un determinado comportamiento. Es decir, como ya
se mencionó, un objeto tiene un determinado estado, cumple con una determinada
funcionalidad y se comunica con otros objetos sin revelar la manera en cumple con
todas esas propiedades. Resumiendo, cada entidad en un sistema POO tiene un
determinado comportamiento y se relaciona con otras entidades sin dilucidar cómo
lo hace.

Herencia: es un tipo de relación entre clases introducido por este paradigma. La
abstracción es una de las bases de POO, y la idea es abstraer tanto comportamiento
como sea necesario, definiendo clases que se encarguen de realizar tareas muy
genéricas o abarcativas, y luego clases que especifiquen de manera puntual cada uno
de esos comportamientos. A esa relación de especificación de comportamiento se la
llama “herencia”, es decir, una clase hereda todo el comportamiento y propiedades
de otra clase, y lo redefine haciendo que sea más específico.

Polimorfismo: este término es sumamente importante para que las otras
características mencionadas tengan sentido. Polimorfismo significa que puede tomar
distintas formas, y eso es, precisamente, lo que se hace en POO. Específicamente,
dado que en POO se busca tener mucha abstracción, el polimorfismo permite que los
objetos se comuniquen con clases específicas (aquellas que heredan un
comportamiento muy genérico y lo hacen más específico) como si fueran genéricas
(las clases de las que heredan). De esta manera, se logra que las relaciones también
sean genéricas.
A la hora de desarrollar un sistema POO, se busca que este tenga una buena calidad.
Esto no sólo implica que el sistema cumpla con los requisitos iniciales (su funcionalidad), que
sea sencillo de utilizar y entender o que sea robusto ante fallas, por ejemplo. A todas estas
propiedades se las denominan cualidades externas, dado que son las que el usuario final
puede percibir (Meyer, 1988) . Sin embargo, para que una aplicación perdure en el tiempo y
se adapte a los distintos cambios que pueden surgir, es necesario tener una buena calidad
en las propiedades internas. Si se sigue un buen diseño de POO, se logra obtener un sistema
que cumple con esas propiedades, dentro de las cuales se pueden mencionar:

Extensibilidad: se denomina extensibilidad a la facilidad con la que se puede agregar
una nueva funcionalidad a un sistema. Concretamente, si se realiza un diseño bien
59
Marco Teórico
abstracto del problema, resulta más sencillo agregar nuevos componentes (clases,
por ejemplo) que cumplan con la nueva funcionalidad, sin alterar el resto de la
aplicación.

Reusabilidad: como su nombre lo indica, esta característica está relacionada con el
reuso de los componentes de un sistema. Esto ayuda a que aquellas problemáticas
que sean similares tengan soluciones en común, ahorrando mucho tiempo de
trabajo.

Flexibilidad: se refiere a la capacidad del sistema de adaptarse a cambios en el
funcionamiento. Es muy similar a la extensibilidad, pero este no sólo se refiere a
nueva funcionalidad sino a la capacidad de cambio de una funcionalidad ya existente.

Mantenibilidad: esta propiedad está muy relacionada con las anteriores
mencionadas, ya que se refiere a la capacidad del sistema de mantenerse
cumpliendo los pedidos y deseos del usuario. Esto implica, también, una buena
legibilidad del código y facilidad para corroborar fallas.
Existen muchos leguajes que sirven para implementar sistemas siguiendo este
paradigma. El primero fue Simula67 surgido en 1967 (Dahl, Myhrhaug, & Nygaard, 1967) y
fue el primero en introducir el concepto de clase. Luego, en 1980, surge la primera versión
de Smalltalk (Glodberg & Robson, 1983) que toma los conceptos introducidos por Simuls67
y, además, permite la creación de objetos dinámicamente. Viendo la gran popularidad y
virtudes que tenía POO, surgen varios lenguajes que se adaptan a sus propiedades, entre los
que se destacan C++ y Java (Eckel, 1998), (Oracle, 1995). A partir de entonces la
programación orientada a objetos es el paradigma más utilizado en el desarrollo de sistemas
de software.
2.4. Trabajos relacionados
Una amplia búsqueda de artículos de investigación e informes fue llevada a cabo con
el objetivo de explorar el estado del arte en el campo de la asistencia en el diseño de
procesos de automatización secuencial basados en representación Grafcet.
Dicha búsqueda ha dado resultados negativos en cuanto a la existencia de
herramientas del estilo con la posibilidad de extender a las necesidades del presente
proyecto.
Se puede citar como caso del mismo ámbito, una aplicación comercial desarrollada
por uno de los más importantes fabricantes de sistemas de automatización y líder en el
mercado, como es Siemens. Esta aplicación es denominada S7-GRAPH V5.3 para S7-300/400
Programación de controles secuenciales.
60
Marco Teórico
2.4.1 Ámbito de aplicación de S7-GRAPH
Se utiliza para describir los procedimientos con secuencias alternativas o paralelas.
Los procedimientos se configuran y se programan de forma clara y rápida en un tipo de
representación estandarizado (IEC 61131-3, DIN EN 61131). El proceso se describe de forma
gráfica, y se divide en pasos individuales con un alcance de fácil comprensión de las
funciones.
2.4.2 Características generales de S7-GRAPH
Con el lenguaje de programación S7-GRAPH se amplían las prestaciones de STEP 7
con la posibilidad de programar controles secuenciales gráficamente (AG, 2004).
Dado que S7-GRAPH opera en el entorno del software básico de programación de
PLCs STEP 7 de Siemens exclusivamente, se requiere tener instalado el paquete de
programación STEP 7 V5.x, además de conocimientos expertos sobre este software,
obviamente.
Con S7-GRAPH se pueden programar las secuencias que se desee controlar con un
sistema de automatización SIMATIC de forma clara y rápida. Para ello se deberá dividir el
proceso en distintas etapas con un volumen de funciones no demasiado extenso. Dicho
proceso se representará gráficamente y puede documentarse tanto con figuras como con
texto.
En las etapas se determinan las acciones que se van a ejecutar. El paso de una etapa
a otra se regula mediante transiciones (condiciones de transición). Estas condiciones se
definen con ayuda de los lenguajes de programación KOP (esquema de contactos) y FUP
(diagrama de funciones).
PLCopen Basis Level
S7-GRAPH cumple, a partir de la versión 5.1, el PLCopen Basis Level para controles
secuenciales de la norma DIN EN 61131-3.
Si dispone de un control secuencial que no cumple la norma, puede importarlo a la
gestión de datos de STEP 7 como archivo ASCII desde el Administrador SIMATIC y tratarlo
posteriormente con S7-GRAPH.
Para crear controles secuenciales conforme a la norma, elija el cuadro de diálogo
"Preferencias de la aplicación" y en la ficha "General" active la opción "Comportamiento
según IEC".
61
Marco Teórico
Bloques del control secuencial
Un control secuencial controla el proceso en un orden preestablecido y en función de
determinadas condiciones.
La complejidad del control secuencial depende de la tarea de automatización que se
desea ejecutar, pero un control tendrá siempre - como mínimo - los 3 bloques siguientes,
representados en la Figura 2.45:
 Un bloque STEP 7 (1) desde el que se llamará al FB de S7-GRAPH. Este bloque puede
ser un OB, una FC u otro FB.
 Un FB de S7-GRAPH (2) para describir las tareas parciales del control secuencial y de
qué dependen. Estas tareas parciales (etapas) y dependencias (transiciones) pueden
organizarse en una o varias cadenas secuenciales.
 Un DB de instancia (3) que contiene los datos y parámetros del control secuencial.
Este DB de instancia se asigna al FB de S7-GRAPH y puede ser generado
automáticamente por el sistema.
Figura 2.45: Bloques de Control Secuencial
Extracto de una cadena secuencial con etapas y transiciones
Las cadenas secuenciales se programan en el FB de S7-GRAPH. Se componen de una
serie de etapas, las cuales se activan en un orden determinado dependiendo de las
transiciones (condiciones de transición) programadas, tal como se muestra en el ejemplo de
la Figura 2.46.
62
Marco Teórico
Figura 2.46: Ejemplo de una cadena secuencial en S7-GRAPH
2.4.3 Análisis de la Herramienta S7-GRAPH
Tal como se ha mencionado anteriormente, esta herramienta corresponde a un
ámbito de programación específico para la línea de equipos propios del fabricante, en este
caso Siemens.
Del mismo modo, como opera en el entorno del software básico de programación de
PLCs STEP 7 de Siemens exclusivamente, se requiere tener instalado previamente el paquete
de programación STEP 7 V5.x.
Dentro de las ventajas principales que podemos destacar se detallan:
 Es un sistema comercial confiable y robusto.
 La interfaz es intuitiva y con alto nivel de ayuda.
 Contempla todos los tipos de datos y operaciones lógicas, ya sean básicas y
aritméticas de coma flotante.
En cuanto a las limitaciones y desventajas podemos enumerar las siguientes:
 Requisitos para la instalación: Sistema operativo Microsoft Windows 2000/XP, es
decir muy limitado en cuanto a las plataformas.
 Requiere Instalación previa del Paquete básico SIMATIC STEP 7 para la programación
de PLC.
 Para la utilización del software de programación S7-GRAPH se requiere una clave de
licencia (autorización de utilización) específica para el producto, cuya instalación se
ejecuta a partir de la versión 5.3 de S7-GRAPH con el Automation License Manager.
 Una licencia se otorga a modo de derecho de la utilización del producto solamente a
1 usuario. En el caso de la utilización del paquete por parte de varios usuarios
simultáneos requiere la instalación de la misma cantidad de licencias.
63
Marco Teórico



Al tratarse de un paquete cerrado, no es posible la extensibilidad a un ámbito
genérico de lenguajes de programación utilizable para distintas marcas y normas
aplicadas por otros fabricantes.
Se requiere conocimiento experto en el desarrollo de programas de automatización
basados en PLC además del propio conocimiento de la representación Grafcet.
No es posible realizar simulaciones del sistema Off Line, con lo que representa el
riesgo de puesta en marcha del sistema real. Solo es posible simular el
comportamiento vía comunicación física con el PLC mediante protocolo MPI.
64
Solución Propuesta
Capítulo 3 - Solución Propuesta
Luego de la investigación realizada y de las ideas analizadas en el marco teórico
presentamos en este capítulo la propuesta que radica en brindar una herramienta que
permita a usuarios con mínimo conocimientos en materia de automatización industrial,
desarrollar proyectos a través de una interfaz amigable y módulos de funcionalidad bien
definida.
Actualmente el desarrollo de un sistema de Automatización Industrial requiere de un
conocimiento específico de los conceptos mencionados en el capítulo anterior. En este
trabajo se propone el desarrollo de una herramienta que permita simplificar la tarea de
implementación de automatismos de procesos.
Aprovechando la potencialidad de los diagramas Grafcet (Siemens, 2004); (Boix
Aragonés, 1997); (Siemens, 1998); (Bossy, Brard, Faugère, & Merlaud, 1995) se propone una
herramienta gráfica amigable para la creación de la secuencia del proceso a automatizar, la
posibilidad de simulación del comportamiento del sistema mediante herramientas gráficas
de interacción con el usuario.
3.1 Descripción de la Solución Propuesta
El proceso de un automatismo requiere de varios recursos organizados por
especialistas en cada uno de los ítems planteados:
 Conocimientos en relevamientos de procesos
 Conocimientos en herramientas de diseño gráfico
 Conocimientos en materia de desarrollo de programación secuencial
 Conocimientos de programación de Autómatas Industriales en cada una de las
variantes que el mercado ofrece.
Con el avance de nuevas tecnologías de desarrollo de Sistemas resultaría de suma
utilidad contar con una herramienta integral que permita englobar cada una de las etapas
del proceso de manera que con el único requerimiento del proceso a Automatizar se pueda
arribar a la solución definitiva.
Esta herramienta integral debería contemplar:

Una interface gráfica amigable (Gálvez Rojas, Alcaide García, & Mora Mata, 2007);
(Knudsen, 1999); (Gilbert, 2002) para diseñar el diagrama funcional del proceso con
todos los componentes intervinientes. Esta interface debería contar con la
posibilidad de incluir atributos propios a cada elemento (por ejemplo nombre
simbólico, detalle del componente, dirección en la estructura física futura, etc.), de
modo que se pudiera generar un formato de salida imprimible que servirá para el
proceso del montaje físico de los elementos.
65
Solución Propuesta

Posibilidad de que una vez diseñado el diagrama anterior se pueda generar un
diagrama secuencial Grafcet (Siemens, 2004) interactuando gráficamente cada
componente físico del proceso con el diseño de Etapas y transiciones.

Una vez realizado el diagrama secuencial poder simular el proceso abstrayéndose
completamente de la estructura física que alojará el sistema (Direccionamiento del
PLC), sino tan solo con la generación de eventos basados en la interrelación del
diagrama funcional, por ejemplo el uso del mouse que active cada uno de los
compontes intervinientes y reflejando la ejecución en un Runtime del Grafcet
señalizando el circuito.
Al finalizar la Simulación del proceso contar con una herramienta que genere el
código de programa de bajo Nivel con la posibilidad de que sea abierto a cualquier
implementación de autómatas disponibles en el mercado (Marcos, Estévez, Gangoiti,
& Portillo, 2001); (Siemens A. , 2011).

De esta manera se podría pensar en prescindir, en un alto porcentaje, de
conocimientos profundos en programación en lenguajes basados en Controladores lógicos
programables que si bien están encuadrados en una norma universal estándar IEC 61131,
cada fabricante ofrece diferentes metodologías y enfoques de programación (Tratamientos
de direccionamiento, ámbito y denominaciones de variable, operandos, módulos de
organización, funciones, etc.)
3.2 Objetivos de la Solución Propuesta
Esta herramienta permite diseñar programas de Automatismos de control Industrial y
probar los mismos mediante simulador, evitando los riesgos y dificultades que se podrían
presentar al probarlos en un sistema real, roturas físicas de maquinarias como punto
fundamental.
Los objetivos que se han seguido a la hora de desarrollar la herramienta han sido:
• Permitir un diseño al mayor alto nivel posible
• Permitir portabilidad, flexibilidad, y extensibilidad a futuros desarrollos.
Para ello la herramienta dispone de un Editor Grafcet que permite:

Dibujar: Diseñar un programa de control utilizando
diagramas estandarizados por la norma IEC 848

Generar código automáticamente: Generar código
automáticamente a partir del diagrama grafcet.
Además, permite generar código que combine varios
grafcets en un mismo PLC, facilitando aún más la
creación de programas de control.
66
Solución Propuesta

Depurar diseño: Permite la depuración tanto a nivel de
grafcet como a nivel de lista de instrucciones.

Simular ejecución del proceso: Mediante una interfaz
gráfica interactiva para activación de variables y
visualización del punto de ejecución del proceso a
través de coloreo de etapas activas.
3.3 Representación General de la solución Propuesta
Como se ha mencionado a lo largo del presente Capítulo, y como se puede apreciar
en la Figura 3.1, la Herramienta propuesta consta de 4 módulos bien definidos, con los
cuales, a través de una interfaz flexible, el usuario puede interactuar y desarrollar el
proyecto de automatización de un proceso secuencial.
Figura 3.1: Representación General de la Solución Propuesta
67
Solución Propuesta
Las fases de desarrollo del Proyecto de automatización está contemplado en cada
uno de los módulos funcionales, a través de los cuales el usuario tendrá la posibilidad de la
edición de un diagrama Grafcet, programación del proceso automático mediante
condiciones y acciones, testeo del proceso a través de la interacción con las variables
intervinientes y finalmente la generación del código de programa en lenguaje de PLC.
3.4 Diseño del Diagrama Grafcet
Como se puede apreciar en la Figura 3.2, el usuario estará en condiciones de diseñar
el diagrama secuencial Grafcet, basándose en las herramientas de edición contempladas
para cada elemento interviniente, de modo que al finalizar esta etapa, el resultado será la
transcripción gráfica de un proceso secuencial en una representación estándar normalizada.
Figura 3.2: Edición del diagrama Grafcet
68
Solución Propuesta
Símbolos Gráficos del Grafcet
A continuación describiremos los símbolos utilizados en los diagramas Grafcet, y cuya
funcionalidad fue abordada en profundidad en la sección 2.2:
Cuadrado: Simboliza una etapa. La etapa inicial RESET se
representa con doble línea.
Líneas de evolución: Unen entre sí las etapas que representan
actividades consecutivas.
Transiciones entre las líneas de evolución: Representan las
condiciones lógicas necesarias para que finalice la actividad de una
etapa y se inicie la etapa/s inmediatamente consecutiva.
Divergencia en Y: Subprocesos simultáneos. Si se cumple la
condición y si la etapa inicial está activada, se activan todos los
caminos simultáneos.
Convergencia en Y: Cuando dos o más caminos en Y convergen en
un estado, para que ese estado se active, se deben haber
ejecutado completamente dichos caminos.
69
Solución Propuesta
3.5 Programación del Proceso
Mediante este módulo el usuario podrá configurar las condiciones lógicas que
definen el ciclo de avance del proceso, las cuales conforman las Transiciones entre dos
etapas consecutivas.
Del mismo modo se podrán definir la/s acción/es que serán llevadas a cabo en cada
una de las Etapas.
En la Figura 3.3 podemos apreciar la representación gráfica de la interfaz, que permite
al usuario programar el ciclo del proceso.
Figura 3.3: Programación del proceso automático secuencial
70
Solución Propuesta
3.5.1 Condiciones
Como se mencionó previamente, el objetivo principal que persigue la herramienta
desarrollada es facilitar el desarrollo y codificación de sistemas de PLC. Uno de los pasos
fundamentales que tiene dicho proceso es la definición de condiciones, cuya notación puede
resultar poco intuitiva, con una notación poco amigable para un desarrollador inexperto en
la tarea de programación de automatismos industriales, como lo puede ser un alumno.
Operaciones Lógicas
Como se ha adelantado en la sección 2.1.7, las operaciones lógicas con bits operan
con dos dígitos, 1 y 0. Estos dos dígitos constituyen la base de un sistema numérico
denominado sistema binario. Los dos dígitos 1 y 0 se denominan dígitos binarios o bits. En el
ámbito de los contactos y bobinas, un 1 significa activado (”conductor”) y un 0 significa
desactivado (”no conductor”).
Las operaciones lógicas con bits interpretan los estados de señal 1 y 0, y los combinan
de acuerdo con la lógica de Boole. Estas combinaciones producen un 1 ó un 0 como
resultado y se denomina ”resultado lógico” (RLO). Las operaciones lógicas con bits permiten
ejecutar las más diversas funciones.
En la Tabla 3.1 se puede apreciar las diferentes sintaxis de representación de las
operaciones lógicas con bits son, en este caso tomando como ejemplo la implementación en
un sistema S7-300/400 de Siemens y la correspondiente equivalencia en el sistema PL7 de
Schneider:
Función
Operación lógica 'Y'
Operación lógica 'O'
Operación lógica 'Y' negada
Operación lógica 'O' negado
Operación lógica 'O-exclusiva'
Operación lógica 'O-exclusiva' negada.
Negación del resultado lógico.
Flanco ascendente
Flanco descendente
Asignación de un bit
Puesta a 1
Puesta a 0
Sintaxis S7-300/400
Siemens
U
O
UN
ON
X
XN
NOT
P
N
=
S
R
Sintaxis PL7
Schneider
AND
OR
ANDN
ORN
XOR
XORN
NOT
RE
FE
:=
SET
RESET
Tabla 3.1: Sintaxis de operaciones lógicas con bits
Como se puede apreciar, cada fabricante de autómatas programables tiene su propia
versión del lenguaje de diagrama de contactos y de lista de instrucciones. En general, un
programa escrito para un autómata determinado no sirve para un autómata de otra marca.
Las diferencias más importantes están en las instrucciones y funciones especiales, que cada
71
Solución Propuesta
fabricante implementa a su manera (especialmente temporizadores y contadores), aunque
también hay diferencias en elementos más simples, como son las especificadas.
La norma IEC 61131-3 surgió con el objetivo de establecer una sintaxis de
programación estándar que permitiera programar un automatismo sin necesidad de recurrir
a la sintaxis específica de ningún fabricante. El objetivo último es, evidentemente, que el
programa escrito según la norma IEC 1131-3 se pueda utilizar directamente en cualquier
autómata aunque como podemos notar no es completamente aplicable.
Para la implementación del presente proyecto, y dado que uno de los objetivos
principales es la generación de código automático a partir del diseño del diagrama Grafcet,
se utilizará como base de programación el lenguaje desarrollado por Siemens, más
precisamente el modelo S7-300/400. Si bien es cierto que el objetivo secundario del
proyecto es ampliarlo para la generalidad de sistemas de automatización, quedará como
propuesta trabajos futuros, la ampliación a la generalidad de sistemas justamente
aprovechando la potencialidad de la POO en lo que se refiere a flexibilidad y reusabilidad.
También es posible definir operaciones con una cadena lógica encerrada entre
paréntesis. La lista de instrucciones es más extensa, en la que se incluyen funciones de
contaje, temporización y operaciones matemáticas en coma flotante, pero en este caso sólo
nos centraremos en las operaciones básicas: Y, O y NOT.
A continuación se muestra en el ejemplo de la Figura 3.4 un fragmento de programa
en el que se involucra una combinación de las operaciones lógicas mencionadas. Como se
puede ver, el programa citado es sumamente verborrágico, con muchas sentencias para
explicar poca funcionalidad.
Es un lenguaje de muy bajo nivel que hace que sea sumamente difícil de comprender,
así como también resulta muy complejo utilizarlo para agregar nueva funcionalidad como se
podría brindar si se representara en formar gráfica.
U(
O
O
)
U(
O
O
)
=
E 1.0
E 1.1
E 1.2
E 1.3
A 3.1
Figura 3.4: Estructura de Programa con lista de instrucciones
Este fragmento de programa describe la siguiente combinación:
o El estado de señal de la salida A 3.1 es “1" cuando al menos una operación Y
es verdadera.
o El estado de señal de la salida A 3.1 es “0" cuando ninguna operación Y es
verdadera
72
Solución Propuesta
En la Figura 3.5 por su parte, se muestra una representación gráfica que detalla de
manera más amena el resultado del fragmento de programa anterior. En la misma se puede
notar que es mucho más sencillo de comprender el significado de la combinación lógica
Y
O
Y
Figura 3.5: Representación gráfica de la estructura de programa
Aprovechando la potencialidad de la herramienta proporcionada por los diagramas
Grafcet, la cual es tomada como eje central del presente proyecto, podríamos representar el
citado fragmento de programa en un Nivel superior de abstracción para un usuario
inexperto. En la Figura 3.6 se puede apreciar una mayor ventaja en cuanto a la comprensión
de la combinación lógica.
Como se ha mencionado con anterioridad, el Grafcet es una herramienta estándar
según IEC 848 y permite la descripción gráfica del control del proceso.
Y
O
Y
Figura 3.6: Representación gráfica en Nivel Grafcet
En términos de definición de Grafcet se puede transcribir dicho fragmento de
condición lógica como condición de franqueabilidad de la transición B3 y por consiguiente la
activación de la etapa 2, que es quién tiene la funcionalidad de habilitar la salida A 3.1 Esta
salida se podría ejemplificar como la simple marcha de un motor o la apertura de una
Electroválvula.
73
Solución Propuesta
3.5.2 Lenguaje del Editor
Grafcet, es una metodología clara para la descripción y diseño de control
independiente de la tecnología a utilizar. El Editor Grafcet como tal, es también
independiente de la tecnología; sin embargo, sería muy útil que dicho diagrama pudiese ser
depurado con un PLC. Además, resulta muy interesante la posibilidad que el Editor Grafcet
generase código automáticamente
Como se ha explicado anteriormente, el código generado automáticamente por el
Editor Grafcet será implementado siguiendo una versión reducida del lenguaje de
programación de los autómatas Simatic de Siemens, siguiendo la línea S7-300/400.
El PLC resuelve la lógica programada como una lista de instrucciones o sentencias.
Cada sentencia es un objeto que consiste en uno o dos campos.
El primero de estos campos, siempre presente, representa el comando de una de las
instrucciones de la lista de funciones del PLC.
El segundo de los campos es el operando sobre el que se ejecuta la instrucción. El
operando suele ser una dirección de memoria, temporizadores o acumuladores.
Ciertas instrucciones, como la carga de una constante de temporización, permiten
que el operando sea una constante numérica u hay otras instrucciones, como la apertura de
paréntesis que no tienen operando.
La ejecución del PLC va a leer el estado del operando a modificar su contenido como
resultado de la ejecución de la instrucción sobre la que opera.
La descripción de cómo se forman las direcciones de memoria y el juego de
instrucciones se detallan a continuación.
3.5.3 Direcciones de memoria
El direccionamiento de la memoria del PLC, es sólo directa (sin uso de punteros). Con
el direccionamiento directo, las posiciones de memoria se denominan directamente por su
posición en la tabla de datos. Cada variable se representa por una letra, un modificador
(opcional), una posición de memoria o número de elemento y un número de bit.
Un ejemplo es: TMe.b donde
T= Designación del tipo de memoria
M= Modificación de la variable
e= Número de elemento
b= Número de bit (cuando sea aplicable)
Los tipos de memoria soportados son los descriptos en la Tabla 3.2:
74
Solución Propuesta
Código de Area
Descripción
E
Entradas
A
Salidas
M
Memoria interna de flag/bit
T
Temporizadores
Z
Acumuladores
Tabla 3.2: Tipos de área de memoria
Los modificadores de memoria sólo son aplicables para las áreas de memoria E, A y
M. Los modificadores de dichas áreas de memoria de detallan en la Tabla 3.3:
Modificador
(ninguno)
B
W
L
Descripción
Bit
Byte
Word
Long Word
Número de bits
1
8
16
32
Tabla 3.3: Modificadores de memoria
Por lo tanto, son direccionamientos válidos:
 E 124.0
 AB0
 ML21
 T31
 Z124
3.5.4 Constantes
Los operandos además de ser posiciones de memoria (variables) pueden ser
constantes. Las constantes pueden ser de dos tipos:
- Literales: un número, como por ejemplo 3.
- De temporización: empiezan por S5T# seguido por un tiempo con el formato
XXhXXmXXsXXms, donde h=horas, m=minutos, s=segundos, ms=milisegundos y X son
números. Por ejemplo:
S5T#123h12m3ms.
3.5.5 Juego de instrucciones
La lista completa de instrucciones en un API, en este caso Siemens, se describe en la
Tabla 3.4:
75
Solución Propuesta
Operador
L
Mod
(
Operando
Cualquiera
Descripción
T
Cualquiera
S
Cualquiera
R
Cualquiera
Carga el valor del operando en el
acumulador.
Guarda el contenido del acumulador en
el operando actual.
Pone el operando a true (1).Trabajando
con acumuladores, carga el valor del
ACU1 de la CPU en el acumulador.
Pone el operando a false(0)
U
(
Bit
AND lógico
O
(
Bit
OR lógico
X
(
Bit
OR lógico exclusivo (XOR)
>I
Cualquiera
>=I
Cualquiera
Compara el contenido del acumulador
con el del operando y pone a 1 el
resultado lógico si es mayor
Mayor o igual que(ver >I)
==I
Cualquiera
Igual que (ver >I)
<I
Cualquiera
Menor que(ver >I)
<=I
Cualquiera
Igual o menor que (ver >I)
<>I
Cualquiera
No igual (ver >I)
UN
(
Bit
AND lógico negado
ON
(
Bit
OR lógico negado
XN
(
Bit
OR exclusivo lógico negado
SET
Pone el resultado lógico a true (1)
SE
Timer
FP
Bit
FN
Bit
Activa la cuenta del temporizador si
resultado lógico es 1
Detecta un flanco positivo en el
operando
Detecta un flanco negativo en el
operando
Tabla 3.4: Juego de instrucciones básicas de un API Siemens
76
Solución Propuesta
En este caso nos centraremos en el conjunto de instrucciones básicas de operaciones
con bits, ya que representan la mayoría de las aplicaciones de automatizaciones de procesos
secuenciales, y por ende donde la herramienta Grafcet interviene en todo su potencial.
Este conjunto acotado de instrucciones lógicas son los que se detallan en la Tabla 3.5:
Operador
Mod
Operando
Descripción
U
(
Bit
AND lógico
O
(
Bit
OR lógico
UN
(
Bit
AND lógico negado
ON
(
Bit
OR lógico negado
Tabla 3.5: Juego de instrucciones acotadas del proyecto
77
Solución Propuesta
3.6 Simulación del Proceso
Tal como se representa en la Figura 3.7, el usuario tendrá la posibilidad de efectuar la
simulación del proceso anteriormente creado y programado. Mediante una interfaz gráfica
interactiva, la herramienta permitirá la activación o forzado de variables del proceso y de
esta manera visualizar el punto de ejecución del proceso a través de coloreo de etapas
activas. En este punto el usuario tendrá la posibilidad de depurar la ejecución del
automatismo, corrigiendo las condiciones programadas.
Figura 3.7: Simulación del proceso automático secuencial
78
Solución Propuesta
3.7 Generación Automática de Código PLC
Una vez que el Proceso ha sido depurado, la herramienta brindará la posibilidad al
usuario, de generar en forma automática código de bajo Nivel, interpretado por un
Autómata programable Industrial (PLC). Como se ha planteado dentro de los objetivos, en el
presente trabajo se ha acotado la traducción a un lenguaje específico, en este caso de la
línea S7-300 de Siemens.
En la Figura 3.8 podemos apreciar representada la funcionalidad del módulo de
generación de código, con la correspondiente sintaxis en el lenguaje anteriormente
especificado.
Figura 3.8: Generación automática de código de bajo nivel
79
Diseño e Implementación
Capítulo 4 - Diseño e Implementación
En el presente capítulo se detallan aspectos correspondientes al diseño e
implementación de la herramienta que materializa el enfoque estudiado en el capítulo
anterior.
4.1 Arquitectura general
Grafcet es una aplicación compleja que cuenta con una gran variedad de clases que
cumplen con distintas funcionalidades específicas. La aplicación en sí basa su arquitectura en
el estilo arquitectónico Modelo Vista Controlador (MVC).
MVC es un patrón de arquitectura de software que separa los datos y la lógica de
negocio de una aplicación, de la interfaz de usuario y el módulo encargado de gestionar los
eventos y las comunicaciones. Para ello MVC propone la construcción de tres componentes
distintos que son el modelo, la vista y el controlador, es decir, por un lado define
componentes para la representación de la información, y por otro lado para la interacción
del usuario. En la Figura 4.1 se observa la relación entre los módulos.
Figura 4.1: Arquitectura basado en Modelo Vista Controlador (MVC)
Básicamente, el modelo es el encargado de manejar los datos, así como también la
lógica del programa. La Vista, por su parte, es el componente encargado de administrar la
interfaz gráfica y de recibir la información y actualización de los datos por parte del Modelo.
Finalmente, el Controlador es el que interactúa con el usuario para traducir sus entradas en
comando para la Vista o el Modelo.
80
Diseño e Implementación
Las siguientes subsecciones detallarán aún más cada uno de dichos componentes.
Más específicamente, la Sección 4.1.1 explicará el modelo que tiene la aplicación Grafcet,
con cada una de las partes más importantes del sistema. La Sección 4.1.2 por su parte
detallará los distintos gestores que conforman el controlador del sistema. Finalmente, la
Sección 4.1.3 muestra la vista y algunas capturas de pantalla de la interfaz gráfica.
4.1.1 Modelo
El componente Modelo contiene el núcleo funcional de la aplicación. Éste encapsula
los datos apropiados, y el procesamiento específico. El Modelo desconoce las interfaces
asociadas a él, ya que lo que se busca es la independencia de éste con cualquier Vista o
Controlador, en cambio, las Vistas y Controladores sí conocen su modelo. Los Controladores
invocan a los módulos del Modelo. El Modelo además provee las funciones para acceder a
sus datos que son usadas por las Vistas para obtener la información a ser mostrada.
En particular, el diagrama de clases correspondiente al Modelo se puede ver de
manera general en la Figura 4.2. Más específicamente, en la figura se muestra las clases que
representan cada una de las figuras y de los componentes que conforman la edición de los
programas codificados para el PLC.
Figura 4.2: Diagrama de clases del componente Modelo
En primer lugar, se puede ver la interfaz Figura, que representa cada una de las
posibles figuras que pueden ser graficadas en un panel.
Si bien no se define funcionalidad en esta clase, especifica los métodos que deben ser
implementados por las sucesivas figuras que componen la jerarquía. En este caso los
81
Diseño e Implementación
métodos a implementar están más relacionados con la posición que ocupan en el panel en el
que van a ser graficados.
Luego, se pueden ver las clases Linea, Condicion y la interfaz Enlace. Una línea
representa la línea que conecta a dos instancias de la clase Enlace. Esta clase se encarga,
entre otras cosas, de encontrar un camino entre dos enlaces de manera de que la línea en sí
no pase por encima de otro enlace. Además, una Linea tiene una Relación definida, que se
encarga de indicar cuáles son los enlaces que tiene de un lado de la línea y cuáles los de la
otra. Finalmente, la clase Condicion se encarga de representar las condiciones que hay entre
los enlaces. Dado que las condiciones también son mostradas gráficamente, es necesario
saber en la posición en la que van a ser mostradas, es por eso que también es considerada
una Figura.
La interfaz Enlace agrega un nuevo conjunto de métodos a una Figura. Estos métodos
son los encargados de determinar cómo agregar, borrar u obtener relaciones con otros
enlaces. Se considera un Enlace a todas las figuras que pueden ser conectadas con líneas:
una etapa, una etapa inicial, una línea simultánea o de bifurcación, y una línea de conjunto o
de unión. Cada una de ellas puede recibir como entrada un conjunto de relaciones, y puede
tener un conjunto de relaciones como salida.
En primera instancia, la línea simultánea o de bifurcación tiene la función de activar a
más de un enlace de manera simultánea. Es decir, cuando una línea simultánea es activada
todas las relaciones que tiene como salida serán así mismo activadas al mismo tiempo. La
parte de simulación en la que se puede ver detalladamente dicho funcionamiento se
explicará en la Sección 4.3.
Por otro lado, una línea de conjunto o unión tiene una funcionalidad opuesta. Esto es
así porque la tarea de una línea de conjunto es esperar a que todas las relaciones que tiene
como entradas sean activadas, para poder activar a las relaciones que tiene como salida.
Entonces, una etapa que tenga como predecesor a una línea de conjunto sólo será activada
cuando todas las etapas que precedan a dicha línea sean activadas. Al igual que con las
líneas de bifurcación, toda esta funcionalidad se detalla en mayor profundidad en la Sección
4.3.
Otra de las clases que es considerada un Enlace es una Etapa. Una etapa representa
un estado en el que se está ejecutando una determinada acción en el proceso del programa
de PLC. Estas son los componentes principales del diseño, dado que todo un programa se
basa en el pasaje de una etapa a la otra dadas unas determinadas condiciones. Una etapa
cumple con diversas funciones además de saber administrar sus relaciones. Cumple un rol
muy importante en la simulación (ver Sección 4.3) y además en la traducción al código.
Cuenta con un conjunto de acciones que representan las actividades que se ejecutan
durante dicha etapa, y que además son las que se traducen luego al código general. Una
etapa inicial cumple con la definición de una etapa, aunque tiene una manera de graficarse
distinta, así como también la manera de administrar las relaciones de entrada.
4.1.2 Controlador
El componente Controlador toma las interacciones del usuario como eventos. Cómo
estos eventos son enviados al controlador, depende de la plataforma de la interfaz de
usuario. Por simplicidad, se asume que cada controlador implementa un proceso manejador
de eventos por cada evento relevante. Los eventos son traducidos en peticiones para el
modelo o las vistas asociadas.
82
Diseño e Implementación
Si el comportamiento de un controlador depende del estado del modelo, el
controlador se registra así mismo al mecanismo change-propagation e implementa los
procedimientos de actualización (Buschmann, Meunier, Rohnert, Sommerlad, & Stal, 1996).
Este componente está dividido en varias clases denominadas gestores. Son las
encargadas de administrar cada una de las distintas partes del programa: gestor de paneles,
gestor de código, gestor de símbolos definidos, gestor de simulación, entre otros. Cada uno
de estos gestores está conectado con la Vista para poder procesar las entradas del usuario y
así notificar de los cambios efectuados al Modelo.
En primer lugar, el gestor de paneles se encarga de administrar los distintos paneles
de dibujo. Lleva registro del panel que está siendo utilizado en un momento determinado, y
a su vez guarda en memoria cada uno de los restantes paneles para ser utilizados en caso de
que el usuario así lo desee. También provee la funcionalidad para agregar nuevos paneles de
diseño o eliminar alguno. Este es el componente que le envía los paneles así como cada una
de sus etapas al gestor de simulación, para que el mismo los pueda administrar.
El gestor de simulación, por su parte, se encarga de tener un registro de las etapas
que están activadas en cada paso de la simulación. Además, permite administrar los valores
de las variables previamente definidos en la tabla de símbolos. Cuando el usuario desea
avanzar un paso de simulación, es este gestor el encargado de avisarles a las figuras
correspondientes para que las mismas se actualicen. Lo mismo sucede en caso de que el
usuario desee resetear la simulación, o cambiar un valor de las variables.
Otro gestor importante en el programa es el gestor de símbolos definidos. Este
permite agregar, editar o eliminar símbolos en cualquier momento de la etapa de diseño.
Otra de sus responsabilidades es generar los símbolos predefinidos a la hora de
comenzar con un diseño. También le envía al gestor de código la tabla de símbolos para que
el mismo pueda imprimirla en el programa.
En conclusión, cada parte del controlador interactúa con una parte de la vista para
poder informar al modelo de los cambios que el usuario introduzca. A su vez, el controlador
se encuentra dividido en varios gestores, cada uno de los cuales se encarga de una parte
específica del programa.
4.1.3 Vista
El componente Vista presenta la información al usuario. Las diferentes vistas
presentan la información del modelo de diversas maneras. Cada una define un
procedimiento de actualización que es activado por el mecanismo change-propagation.
Cuando el procedimiento de actualización es llamado, la vista recupera los valores actuales
de los datos a ser mostrados desde el modelo, y los presenta en pantalla.
Durante la inicialización todas las vistas son asociadas con el modelo, y registradas en
el mecanismo change-propagation. Hay una relación uno a uno entre la vista y el
controlador, esta relación es un ejemplo del patrón de diseño Strategy. Las vistas, a menudo,
ofrecen funcionalidad a los controladores para manipular el despliegue en pantalla. Esto es
útil para operaciones activadas por el usuario y que no afectan al modelo (Buschmann,
Meunier, Rohnert, Sommerlad, & Stal, 1996)
Para esta parte del sistema, se hizo uso de la librería Swing1 que provee un conjunto
de métodos para diseñar e implementar una interfaz gráfica de usuario. En particular, Swing
1
Sitio web de Swing
83
Diseño e Implementación
fue diseñado con el fin de proveer un conjunto más sofisticado de componentes para la
interfaz que su antecesor Abstract Window Toolkit (AWT). Esta biblioteca está diseñada de
manera tal que su integración con sistemas MVC sea muy intuitiva. Además cuenta con
diversos componentes predefinidos que agilizan el diseño de una interfaz gráfica.
Uno de los componentes principales que provee esta librería es el JPanel. Esta clase
representa un panel en el que se pueden agregar otros componentes como botones, campos
de texto, etiquetas o, así mismo, otros paneles. Todos estos componentes pueden ser
usados como clases para heredar y así poder personalizarlos, cambiando parte de su
comportamiento interno. Esto brinda una gran flexibilidad a la hora de desarrollar.
Adicionalmente, estos componentes cuentan con una gran variedad de métodos para
poder modificar el tamaño, la posición, el ancho o alto, entre otras propiedades.
Por otro lado, los componentes que se consideran contenedores de otros, como un
JPanel, tienen definidos Layouts internamente. Un Layout es una forma de esquematizar los
componentes dentro del contenedor, que sirve para diseñar la vista. Por ejemplo,
RelativeLayout es un layout en el cual cada componente se define de acuerdo al resto de los
componentes; BoxLayout permite definir los componentes de manera vertical u horizontal;
etc.
Todos los componentes que manejan información internamente, como lo son las
tablas, cuentan con la posibilidad de definir modelos. Esos modelos son los que sirven para
representar el modelo del sistema, es decir, el modelo explicado en la Sección 4.1.1 se
plasma en los modelos de dichos componentes. Además, cada componente cuenta con
Listeners que son clases que avisan de cada interacción del usuario con la interfaz.
Estos sirven para poder avisar a los diferentes gestores las entradas del usuario,
como se mencionó en la Sección 4.1.2. Es por todo esto que se considera que Swing tiene
una gran compatibilidad con sistemas MVC.
A sabiendas de todos los beneficios otorgados por esta librería, se decidió realizar la
implementación con la misma. En la Figura 4.3 se muestra una captura de pantalla de
Grafcet. Allí se pueden ver los distintos componentes: un panel donde se realiza el diseño de
las etapas, los botones para agregar etapas o líneas, barras de menú en la parte superior y
en la parte izquierda. Cada uno de dichos componentes tiene definidos sus Listeners para
informarle a los distintos gestores, y tienen definidos distintos tipos de Layouts.
84
Diseño e Implementación
Figura 4.3: Captura de pantalla de la vista de Grafcet
4.2 Condiciones
Como se mencionó previamente, el objetivo principal que persigue le herramienta
desarrollada es facilitar el desarrollo y codificación de sistemas de PLC. Ya se mencionó la
gran dificultad que presenta desarrollar sistemas de este tipo, y el tiempo de desarrollo que
puede implicar. Dentro del desarrollo en sí mismo, uno de los pasos fundamentales es la
definición de condiciones, cuya notación puede resultar anti-intuitiva, con una notación
poco amigable para un desarrollador inexperto, como puede ser un alumno.
En la Sección 4.2.2 se detalla el diseño y los requerimientos para la representación de
condiciones en Grafcet.
La Sección 4.2.3, por su parte, detalla los pormenores de la implementación del
diseño previamente mencionado.
Luego, en la Sección 4.3 se especifica el diseño e implementación de los módulos
correspondientes a la simulación.
4.2.1 Operaciones Lógicas
Las operaciones lógicas con bits operan con dos dígitos, 1 y 0. Estos dos dígitos
constituyen la base de un sistema numérico denominado sistema binario. Los dos dígitos 1 y
0 se denominan dígitos binarios o bits. En el ámbito de los contactos y bobinas, un 1 significa
activado (“conductor”) y un 0 significa desactivado (“no conductor”).
85
Diseño e Implementación
Las operaciones lógicas con bits interpretan los estados de señal 1 y 0, y los combinan
de acuerdo con la lógica de Boole. Estas combinaciones producen un 1 ó un 0 como
resultado y se denominan “resultado lógico” (RLO). Las operaciones lógicas con bits
permiten ejecutar las más diversas funciones.
Las operaciones básicas para las operaciones lógicas con bits son:







U: Operación lógica AND.
UN: Operación lógica AND negado.
O: Operación lógica OR.
ON: Operación lógica OR negado.
X: Operación lógica OR-exclusivo.
XN: Operación lógica OR-exclusivo negada.
NOT: Niega el resultado lógico.
También es posible definir operaciones con una cadena lógica encerrada entre
paréntesis. La lista de instrucciones es más extensa, pero en este caso sólo nos centraremos
en las operaciones básicas: AND, OR y NOT.
A continuación se muestra un ejemplo de un fragmento de programa en el que se
involucra alguna combinación de las operaciones lógicas mencionadas.
O(
U var1
U var2
)
O(
U var3
U var4
)
Figura 4.4: Ejemplo de código representando una condición simple
En la Figura 4.4 se muestra un breve ejemplo que involucra solo dos operaciones: AND
y OR; y cuatro variables: var1 , var2 , var3, y var4 . Como se puede ver, el programa citado es
sumamente verborrágico, con muchas sentencias para explicar poca funcionalidad.
Es un lenguaje de muy bajo nivel que hace que sea sumamente difícil comprender su
funcionalidad, así como también resulta muy complejo utilizarlo para agregar nueva
funcionalidad.
86
Diseño e Implementación
El mismo funcionamiento se puede ver gráficamente en la Figura 4.5 y se puede notar
que es mucho más sencillo de comprender. Cada uno de los operadores está representado
por una nueva caja en el diagrama, así como también las variables. Resulta mucho más
ameno y entendible este lenguaje gráfico, sobre todo para aquellos usuarios que no tienen
previa experiencia para su uso.
4.2.2 Diseño para la representación de condiciones
Una vez analizada la problemática, se puede ver que hay una correspondencia directa
entre la representación gráfica y el código necesario para representar las condiciones en un
PLC. Este análisis resulta de gran utilidad a la hora de realizar un primer diseño para que la
aplicación realice el pasaje automáticamente.
Figura 4.5: Representación gráfica una condición simple
Puntos a considerar a la hora de realizar el diseño:
 Puede haber cualquier combinación de operadores. Es decir, un operador AND,
por ejemplo, puede estar precedido por cualquier operador (AND, OR, NOT) así
como también por una variable. Lo mismo sucede con cualquier operador.

La letra U se corresponde con el operador AND, la letra O con el operador OR y
la letra N se corresponde con el operador NOT.

Cuando un operador está precedido por una variable, solo se agrega la letra
que corresponda para ese operador delante de la variable. Por ejemplo, el
operador AND de la Figura 4.5 sólo está precedido por dos variables: var1 y
var2. Su representación es la siguiente:
87
Diseño e Implementación
U var1
U var2

Cuando un operador está precedido por un operador, se agrega la letra que
corresponda a dicho operador y un paréntesis. Debajo de esa línea, se listan las
condiciones que involucre el operador por el cual está precedido. Finalmente,
se agrega una línea con el paréntesis para cerrar el paréntesis abierto
previamente.

Cuando un operador tiene más de una entrada, estas se listan una debajo del
otro con la letra que corresponda a dicho operador. Es decir, si en el código se
ven dos líneas con una 'U' que preceda, estos se corresponden al mismo
operador, que en este caso es un AND.

Para separar líneas que se correspondan con distintos operadores se usan los
paréntesis.

Las variables pueden ser vistas como operadores que sólo devuelven su valor
de verdad.
Teniendo en cuenta dicha especificación, se procede a realizar un primer diseño
general que ataque cada uno de los puntos mencionados. Teniendo en cuenta el primer
punto en particular, se puede notar la gran flexibilidad que existe a la hora de realizar una
condición. Es decir, cualquier operador puede ser precedido por otro operador, y todos
tienen un comportamiento en común: retornar las líneas de código correspondientes al
operador. De esta forma, está claro que un operador tiene que tener completa
independencia de lo que lo preceda.
Luego de realizar una búsqueda por los patrones de diseño que puedan proveer una
solución para esta problemática, se encontró el patrón que mejor se ajusta a dichos
requerimientos es el patrón Composite. Según (Gamma, 1995), el patrón Composite permite:
“Componer objetos en árboles para representar jerarquías todo-parte. Composite
permite a los clientes tratar objetos individuales y objetos compuestos de una
manera uniforme”.
Esa definición es muy similar a lo que se había especificado previamente, un operador
debe tratar a sus precedentes de la misma forma obteniendo el mismo formato de entrada,
sin importar si estos eran objetos individuales (variables en nuestro caso) u operadores
compuesto (operadores). Es por eso que para el diseño inicial se decidió utilizar este patrón.
En la Figura 4.6, se muestra el diagrama de clases resultante luego de aplicar el patrón
Composite. Como se puede ver, se define una clase abstracta Operador en la que se definen
los métodos comunes a todos los tipos de operadores.
88
Diseño e Implementación
Figura 4.6: Diseño para representar las condiciones usando el patrón Composite
Como se mencionó en el último punto de las especificaciones, una variable también es
un operador, que sólo retorna su propio valor. Es por eso que también está en el diagrama
de clases.
Dentro de los métodos definidos en el diagrama de clases, se distingue solo
getCondicion(). Dicho método devuelve la traducción del gráfico a su formato PLC. Es decir,
el operador AND, del ejemplo mencionado en la Figura 4.5, retornaría:
U var1
U var2
De esta manera queda el diseño para la representación de condiciones terminado. El
resto de los puntos mencionados en la especificación se desarrollarán con la
implementación misma, dado que son más puntuales.
4.2.3 Implementación
Una vez presentado el diseño, se pasa a mostrar los pasos que se siguieron para
implementar el sistema de condiciones en el programa. Para la implementación se deben
considerar las dos partes que esta involucra, por un lado, la lógica necesaria y, por el otro, la
interfaz gráfica requerida para mostrar al usuario un editor con el que pueda establecer las
condiciones.
En principio, se puede plantear un diseño como el que se puede ver en la Figura 4.7
donde cada operador tiene la responsabilidad de dibujarse a sí mismo. Es decir, el método
pintar, que proviene de la interfaz Figura, se encarga de generar el gráfico correspondiente
para cada operador. En este caso, el operador AND graficaría una caja con la palabra 'AND'
en su interior, el operador OR haría lo mismo para su caso pero con la palabra 'OR', las
variables graficarían una caja con su nombre en el interior, y de manera análoga con el
operador NOT.
89
Diseño e Implementación
Figura 4.7: Diseño de operadores que pueden graficarse a sí mismos
Es posible distinguir que existe una gran repetición de código con el caso anterior. Es
decir, todos los operadores se representan con cajas, de la misma manera. La única
diferencia que hay en cada caso es el texto que muestran en su interior. Entonces, una
posible solución es delegar el funcionamiento de dibujar la caja a la clase abstracta, y definir
un método que le permita a cada operador devolver el texto que deben dibujar en el interior
de la caja. El diseño para este caso se puede ver en la Figura 4.8.
Existe un patrón de diseño que especifica esta estrategia para delegar funcionamiento
en común a la clase abstracta (en nuestro caso, graficar la caja que representa el operador),
y solo heredar una pequeña parte de dicha funcionalidad (obtener el texto para escribir en la
caja) en las clases hijo. Este patrón se conoce con el nombre de Template (Gamma, 1995).
90
Diseño e Implementación
Figura 4.8: Diseño de operadores usando el patrón Template para graficar
Si bien el diseño presentado parece correcto, todavía restan definir todos los métodos
para poder establecer relaciones entre los distintos operadores, tanto sean de entrada como
de salida. Analizando el código ya definido para poder graficar etapas y relaciones entre
etapas, se puede distinguir una gran similitud con lo que se precisa para graficar operadores.
Por lo cual, se decidió reutilizar dicha funcionalidad.
Para lograr dicho objetivo, se procedió a realizar el diseño presentado en la Figura 4.9.
91
Diseño e Implementación
Figura 4.9: Diseño de operadores reutilizando la funcionalidad para graficar una etapa
Aquí se puede ver que toda la funcionalidad para graficar un elemento y para definir
relaciones con otros elementos está definida en la interfaz Enlace. Luego, la clase abstracta
Caja se encarga de implementar todos esos métodos para poder graficar una caja con un
texto en su interior, siguiendo también el patrón Template.
Finalmente, la clase Etapa implementa todos los métodos específicos de una etapa así
como también el método para retornar el texto a escribir dentro de la caja. Lo mismo sucede
con los operadores, que implementan su propia funcionalidad y la necesaria para obtener el
texto a escribir.
Con este diseño final, los únicos métodos que deben ser implementados son los
correspondientes a la funcionalidad de los operadores. Es decir, los métodos getCondicion(),
y getTexto(). Para el caso de getTexto(), cada operador retornará el texto que lo representa
('AND', 'OR', 'NOT', o el nombre de la variable, dependiendo del operador).
Finalmente, para la implementación del método getCondicion() se precisa un poco más
de lógica. En la Figura 4.10 se muestra la implementación para el operador compuesto.
92
Diseño e Implementación
Figura 4.10: Implementación del método getCondicion() para el operador compuesto
Allí se puede ver que cuando se trata de una variable, sólo se agrega la letra “U” por
delante. Mientras que cuando se trata de un operador, se agrega una línea por encima de la
condición devuelta por el operador que lo precede, en la que se abren los paréntesis. Luego
se agrega otra línea al final de la condición en la que se cierran los paréntesis. El resto de los
operadores siguen una implementación muy similar a la mostrada para el operador
compuesto.
Una vez que se agregan todos los operadores al editor, el usuario puede definir
cualquier combinación de los mismos. Sin embargo, para determinar cuál es el operador
final, el que devuelve el resultado de toda la condición que se quiere definir, se debe agregar
un nuevo operador. Es decir, dado que pueden existir varios operadores usados a la hora de
definir una condición, se debe determinar cuál de todos ellos es el que entrega el resultado
final. Por este motivo, se agregó el operador IGUAL. Este operador sólo puede ser definido
una vez en el editor, y su implementación del método getCondicion() va a retornar la
condición que obtiene como entrada simplemente.
Una vez definidos todos los operadores y su implementación, se procede a mostrar un
breve ejemplo en el que se aplican todos los conceptos mencionados. La Figura 4.11 muestra
la representación del ejemplo mostrado en la Figura 4.5, esta vez usando el editor Grafcet.
Como se puede ver, se definieron todas las variables, se las conectó con los operadores AND.
Estos, a su vez, pudieron ser posteriormente conectados con el operador OR. Finalmente, el
operador OR es conectado con el mencionado operador IGUAL, que se encarga de retornar
el resultado final una vez que se pulsa el botón Aceptar en la parte inferior. Como resultado
se obtiene su representación en lenguaje de PLC, mostrado con anterioridad en la Figura 4.4.
93
Diseño e Implementación
Figura 4.11: Ejemplo de la definición de una condición usando Grafcet
94
Diseño e Implementación
4.3 Simulación
Una significativa potencialidad agregada como herramienta para el usuario resulta la
posibilidad de depuración de código. Esto es, una vez definido el diagrama con sus
respectivas etapas y transiciones, contar con la ventaja de simular el funcionamiento,
mediante una interfaz interactiva en donde tenga la posibilidad de operar manualmente en
el valor de cada variable interviniente. De esta forma, una vez que se han realizado todas las
pruebas y correcciones en la programación, efectuar la traducción a lenguaje de PLC con un
grado de certeza elevado en cuanto a funcionamiento y respuesta.
En esta sección se detallará el diseño e implementación requeridos para poder agregar
un soporte de simulación, en el cual se pueda probar el diagrama realizado, dándole la
oportunidad al usuario de cambiar los valores de estado de cada una de las variables
definidas y ver, paso a paso, el comportamiento del sistema.
4.3.1 Diseño
Antes de poder realizar un diseño para poder implementar el módulo que soporte la
simulación del sistema, es necesario realizar un análisis del estado actual de la aplicación. De
esta forma, se detectará qué características se deben agregar y en qué punto es necesario
agregar la nueva funcionalidad para poder brindar el mencionado soporte.
En principio, se cuenta con una representación de Etapas y de enlaces. Las Etapas
representan un estado en el diagrama, mientras que los enlaces representan las conexiones
entre dichos estados.
Básicamente, la simulación consta de tres características esenciales:
1. Activar etapas según corresponda.
2. Cambiar el estado de las variables previamente definidas.
3. Determinar si una condición se cumple o no.
A continuación se detallará los puntos fundamentales a cubrir para poder brindar las
mencionadas características. En primer lugar, el hecho de activar etapas implica que cada
etapa debe saber si está o no activada. Es decir, debe mantener su propio estado.
Por otro lado, para que una etapa pueda activarse se deben cumplir dos condiciones:
las etapas inmediatamente anteriores (o sea, aquellas que solo están separados por un
enlace) deben estar activadas; y que las condiciones definidas en los enlaces emergentes de
dicha etapa sean franqueadas. La única excepción a este caso es la etapa inicial, dado que la
misma se activa siempre por defecto al comenzar con la simulación.
La Figura 4.12 muestra un ejemplo en el cual se explica mejor el proceso mediante el
cual se activa una etapa. En principio, ninguna etapa se encuentra activada dado que la
simulación todavía no comenzó. Una vez que la simulación comienza, automáticamente la
etapa inicial es activada. Luego, dadas las circunstancias, la condición es cumplida. Así,
debido a que ambas la condición y la etapa inmediatamente anterior están activadas, la
etapa 2 es activada.
95
Diseño e Implementación
Figura 4.12: Ejemplo de transición de etapas en una simulación
Cuando se trata de una bifurcación o Divergencia en Y (ver Sección 3.4), el
comportamiento difiere un poco de lo que se viene explicando hasta ahora. Una vez que la
etapa inmediatamente anterior a la bifurcación es activada, y la condición de la relación se
cumple, la bifurcación se activa. Al activarse la bifurcación, automáticamente se activan
todas las etapas inmediatamente siguientes a la bifurcación.
En la Figura 4.13 se muestra un ejemplo de una transición de etapas en una
simulación, involucrando una bifurcación.
La bifurcación, en este caso, es precedida por la etapa inicial, y está conectada a las
etapas 2 y 3. La etapa inicial es activada al comenzar la simulación. Cuando la condición
definida en la relación que conecta la etapa inicial con la bifurcación es cumplida, la
bifurcación activa a las etapas 2 y 3 automáticamente.
96
Diseño e Implementación
Figura 4.13: Ejemplo de transición de etapas con una bifurcación
Solo resta por detallar el comportamiento de la simulación cuando se involucra una
unión (ver Sección 3.4). Al contrario que en el caso de la bifurcación, una unión sólo es
activada cuando todas las etapas que la preceden son activadas. Una vez cumplida la
receptividad asociada a la transición emergente, la unión es activa y pasa a la etapa
siguiente.
La Figura 4.14 muestra un ejemplo de una simulación donde se involucra una transición
de etapas con una unión.
97
Diseño e Implementación
Figura 4.14: Ejemplo de transición de etapas con una unión
En el primer estado las etapas 3 y 4 se encuentran activadas. Además, las condiciones
definidas en la relación que las conecta con la unión también se cumplen. Por ende, la unión
se activa y pasará automáticamente a la etapa 5.
De todo el proceso previamente explicado, se pueden distinguir varios puntos a
considerar en el diseño de esta sección del programa. A continuación se listan algunos de
dichos puntos:

Todas las figuras (etapas, enlaces, uniones y bifurcaciones) deben proveer la
funcionalidad para informar si está activado o no. De esta forma, otras etapas van a
poder determinar si deben o no ser activados, considerando que las etapas
anteriores cumplen con los requisitos.

Todas las figuras deben poder ser reseteadas. Como se mostró en los ejemplos de
transición, cuando una etapa se activa, las etapas anteriores deben ser desactivadas.

Todas las figuras deben proveer la funcionalidad para determinar si deben o no ser
activadas. Por ejemplo, una tapa debe corroborar que las etapas y enlaces anteriores
estén activados. A su vez, una relación va a estar activada si la condición definida en
su interior se cumple.
98
Diseño e Implementación

Todas las figuras deben poder actualizarse, en caso de que deban ser activadas (esto
se determina usando la funcionalidad definida anteriormente). Aquí es donde se
debe informar a las etapas y enlaces anteriores que deben ser reseteados.
Por otro lado, al igual que sucedió con las condiciones, todas las figuras pueden ser
combinadas de cualquier forma. Es decir, antes de un estado puede haber una unión, una
bifurcación u otro estado. Lo mismo sucede con el resto de las figuras. Por lo tanto, se puede
ver que estamos en condiciones de reutilizar el patrón de diseño Composite. Esto es así
porque nos brinda la flexibilidad para independizarse de lo que esté definido previa o
posteriormente.
En la Figura 4.15 se muestra el diagrama de clases que representa los componentes
necesarios para implementar la simulación en Grafcet.
Figura 4.15: Diseño para la simulación utilizando el patrón Composite
Como se puede apreciar, se aplicó nuevamente el patrón Composite siguiendo la
estrategia previamente mencionada. También se puede notar que una etapa, una
bifurcación y una unión sólo pueden conectarse con líneas. Una línea, en cambio, puede
relacionarse con cualquier figura.
Los métodos surgen de las especificaciones listadas anteriormente.

activa()
Este método se encarga de determinar si la etapa debe o no ser
activada. Es decir, retornará un valor de verdad positivo en caso de
que se cumplan las condiciones ya nombradas. En caso de que la etapa
ya se encuentre activada, este también retornará un valor de verdad
positivo. Caso contrario, devolverá FALSO como resultado, indicando
que no se encuentra activada y que no se cumplen las condiciones
necesarias para ser activado.
99
Diseño e Implementación

actualizar()
Este método se encarga de actualizar cada figura. Utiliza el método
activa() para saber si debe ser activado. En cuyo caso, actualiza las
variables necesarias para futuras invocaciones. Y resetea las figuras
que la precedan.

reset()
Resetea la etapa, indicando que ya no se encuentra activado.
Con esto se da por terminado el diseño para representar las figuras en la simulación.
Resta por definir el diseño del componente del sistema que se encargue de procesar las
condiciones (ver Sección 4.2) para determinar si las mismas son cumplidas o no.
Para el análisis y procesamiento de las condiciones se puede pensar un diseño
muy similar al desarrollado para la definición de las condiciones. Es decir, cada operación
(AND, OR, NOT) debe poder determinar si esta se cumple o no. Por ejemplo, para
determinar si una operación AND, el operador debe consultar a sus entradas si las mismas se
cumplen. En caso de que se cumplan todas ellas, la operación AND retornará un valor de
verdad positivo.
Entonces, la estructura a plantear es muy similar a la mostrada en la Figura 4.9,
solo que esta jerarquía no precisa ser representada gráficamente, con lo cual es necesario
definir una nueva estructura. En este caso, el método a definir es CumpleCondicion() que se
encarga de realizar la tarea previamente mencionada.
Así, el resultado final de la estructura se puede apreciar en la Figura 4.16.
Figura 4.16: Diagrama de Clases que representan las condiciones para la simulación
Además de dicha funcionalidad, se debe realizar un módulo que se encargue de
interpretar el texto en el que se definen las condiciones. Básicamente la tarea de este
módulo es interpretar cada una de los caracteres definidos en la especificación de las
condiciones, y, en base a ello, hacer una representación en memoria usando la jerarquía
previamente mencionado. Siguiendo con el ejemplo mostrado en la Sección 4.2.1, dada una
especificación de una condición como la que se pudo ver en la Figura 4.4, este módulo lo
interpretaría para generar el modelo mostrado en la Figura 4.5.
Una vez explicado todo el diseño que concierne al proceso de simulación, se procede a
detallar la implementación de cada uno de los módulos previamente explicados.
100
Diseño e Implementación
4.3.2 Implementación
Al igual que en el caso de la definición de condiciones, una vez definida la estructura a
utilizar, la implementación es directa y sencilla. A continuación se mostrarán extractos de la
implementación de cada uno de los componentes mencionados en el diseño mostrado en la
Figura 4.15. Luego, se mostrará la implementación correspondiente a los módulos que
interpretan las condiciones para determinar si las mismas se cumplen o no.
En primer lugar, en la Figura 4.17 se muestra el código correspondiente a la
implementación de la clase Etapa. Como se puede apreciar, los métodos son cortos y
sencillos de entender. Vale aclarar que el método activa() es recursivo, es decir, invoca al
mismo método pero de la Figura que lo antecede. Entonces, para determinar si una Figura
debe ser activada o no, se llama recursivamente hasta llegar a la etapa inicial. Esto se puede
agilizar en caso de que una etapa ya se encuentre activada.
Figura 4.17: Código de la clase Etapa para implementar la simulación
Para el caso de la Línea, tal como se presenta en la ¡Error! No se encuentra el origen de la
eferencia., el código resultante es muy similar, solo se genera una ligera variación en cada
método. Siguiendo la misma línea, se pueden definir el resto de los módulos a implementar.
101
Diseño e Implementación
Figura 4.18: Código de la clase Linea para implementar la simulación
En segundo lugar, el intérprete de condiciones es un poco más complejo de
implementar, dado que se deben considerar diversas posibilidades. Básicamente, si se trata
de una línea que contenga un paréntesis, entonces se trata de un operador lógico. Si no
posee paréntesis, entonces pueden existir dos opciones: operador lógico con variable ó
variable sola. Una vez identificada cada una de las alternativas, se puede proceder a generar
la estructura en memoria, usando la jerarquía de clases mostrada en la Figura 4.16.
Con lo cual, solo resta por presentar la implementación de la reciente mencionada
jerarquía de clases que representa las condiciones. En la Figura 4.19 se muestra la
implementación del método getCondicion() para la clase Variable. Se puede notar que la
implementación es muy sencilla.
Figura 4.19: Código de la clase Variable para implementar la interpretación de condiciones
102
Diseño e Implementación
En la Figura 4.20, por su parte, se muestra la implementación del método en la clase
And. Esta difiere un poco de la anterior presentada, dado que tiene que corroborar que cada
una de las entradas sea verdadera para poder retornar un valor verdadero. El resto de los
operadores se implementan siguiendo la misma línea:
Figura 4.20: Código de la clase And para implementar la interpretación de condiciones
103
Casos de Estudio
Capítulo 5 - Casos de Estudio
Para poder evaluar la respuesta y el comportamiento de la herramienta desarrollada,
se realizaron dos casos de estudio. Cada uno de ellos se ideó con el fin de plasmar de
manera adecuada y concisa el funcionamiento de la herramienta en los puntos de mayor
importancia.
En el Apéndice A se muestra cómo es el funcionamiento de la herramienta, con
información de la interfaz y los distintos elementos que la componen, junto con ejemplos
sencillos que permitan facilidad de comprensión en la modalidad de trabajo.
En el primer caso de estudio se plantea un ejemplo simple y didáctico a modo de
introducción en el desarrollo de un automatismo de control, que permitirá analizar la
sencillez que brinda la herramienta en el caso de que el usuario no posea amplios
conocimientos en el ámbito de la programación de Autómatas Industriales.
En el segundo caso de estudio se abordará un Proceso real de Automatismo de
Control, el cual se encuentra implementado y en actual funcionamiento en una Planta Fabril,
que permitirá analizar el funcionamiento de la herramienta en su máxima capacidad. En este
punto se trazará una analogía con el comportamiento de la instalación física y las ventajas
concretas ofrecidas en cada etapa del ciclo de trabajo, acompañado de ilustraciones
fotográficas para una mayor comprensión del mismo. Se plantearán, además, posibles
situaciones reales a modo de ilustración de las ventajas de la herramienta en el nivel de
simulación virtual, resaltando la importancia que significa minimizar los riesgos de la puesta
en marcha física del sistema.
104
Casos de Estudio
5.1 Caso de Estudio N° 1
En este apartado desarrollaremos la aplicación de la herramienta en un caso práctico
y sencillo como es el funcionamiento de una taladradora.
La taladradora es una máquina herramienta donde se mecanizan la mayoría de los
agujeros que se hacen a las piezas en los talleres mecánicos. Estas máquinas de manejo
sencillo, tienen dos movimientos: El de rotación de la broca que le imprime el motor
eléctrico de la máquina a través de una transmisión por poleas y engranajes, y el de avance
de penetración de la broca, que puede realizarse de forma manual sensitiva o de forma
automática, si incorpora transmisión para hacerlo.
Mando de una taladradora
Consola Móvil
Broca
Bastidor Fijo
Figura 5.1: Vista simbólica de la taladradora
5.1.1 Descripción
Como se puede apreciar en la Figura 5.1, la taladradora se compone de un bastidor
fijo y de una consola móvil respecto al bastidor.
La consola soporta la broca y el motor de accionamiento de la taladradora. Las piezas
a taladrar son puestas y fijadas manualmente en un montaje solidario del bastidor.
5.1.2 Ciclo de funcionamiento
-
La broca da vueltas permanentemente.
El operario fija la pieza y da información al automatismo para el inicio de ciclo:
105
Casos de Estudio
-
Después de una aproximación a gran velocidad de la taladradora hacia la pieza, el
taladrado se efectúa a pequeña velocidad.
Cuando el taladro se ha efectuado, la broca vuelve a ascender a gran velocidad hasta
la posición de reposo.
Nótese que, cuando el recorrido de la broca, en sentido ascendente, llega de nuevo
al captador b1 "aproximación terminada", la etapa 4 activa hasta este momento, no
es receptiva a esta información y por lo tanto el comportamiento del automatismo
permanecerá inactivo, por tanto la información facilitada por b1 será ignorada.
De acuerdo al ciclo de funcionamiento descripto, podemos representar el diagrama
Grafcet funcional de la aplicación, tal como se muestra en la Figura 5.2.
Figura 5.2: Grafcet funcional de la taladradora
5.1.3 Nivel tecnológico
Para construir efectivamente el automatismo de mando de la máquina, es necesario
definir su naturaleza.
 Los actuadores dentro de la parte de mando permiten obtener las acciones a
realizar.
 Los captadores entregarán las informaciones correspondientes o las señales de fin
de ejecución.
La toma en consideración de la naturaleza y en particular de la tecnología de los
captadores y actuadores utilizados pueden conducir a representaciones diferentes.
A título de ejemplo, consideramos la taladradora descripta anteriormente y
analizamos su parte tecnológica:
 Los movimientos de descenso y ascenso son obtenidos por un motor eléctrico.
 Las informaciones "posición alta" y "posición baja" son obtenidos por finales de
carrera electromecánicos.
 La información de "marcha" está facilitada por un pulsador eléctrico.
106
Casos de Estudio
5.1.4 Implementación con la Herramienta
Paso 1: Lo primero que debemos hacer es identificar cuáles son las variables, y definirlas en
la tabla de símbolos, en la pantalla de la Figura 5.3.
Figura 5.3: Vista de pantalla de la tabla de símbolos de la Taladradora
De esta manera quedan definidas todas las variables intervinientes en el proceso, que
en nuestro caso serían:



Pulsador de marcha de la máquina por parte del operario
Las señales leídas por los captadores de acuerdo a la altura de la consola móvil
Las acciones asociadas a los movimientos del cabezal, ascenso y descenso.
107
Casos de Estudio
Paso 2: Una vez definidas las variables, creamos el diagrama que controlará el automatismo
en cuestión. Dibujaremos las 4 etapas del diagrama en la pantalla de la Figura 5.4.
Figura 5.4: Vista de pantalla del diagrama de etapas de la Taladradora
El diagrama estará compuesto por 4 etapas, incluida la etapa inicial.
108
Casos de Estudio
Paso 3: Dibujar las líneas de conexión entre las etapas de acuerdo al ciclo de trabajo del
proceso tal como se observa en la pantalla de la Figura 5.5.
Figura 5.5: Vista de pantalla de conexiones de etapas del diagrama de la Taladradora
Por defecto, al crear la transición entre la etapa inicial y la próxima, el sistema asigna la
condición de RESET_0, por una cuestión de diferenciación de tipos de etapas, pero dicha
condición puede ser reemplazada por el usuario, tal como veremos más adelante.
109
Casos de Estudio
Paso 4: Pulsando con el botón derecho encima de una etapa, nos aparece el panel de la
Figura 5.6, que nos permite:
-
Cambiar la identificación de la etapa.
Crear/Modificar/Eliminar la etiqueta
asociada a la etapa.
Modificar/Crear/Eliminar la etiqueta
asociada a la etapa
El cambiar el bitEstado o el bitCopia de
la etapa
Añadir una acción a la etapa
Eliminar relaciones con otras etapas
Eliminar la etapa
Figura 5.6: Vista de pantalla del menú de edición de etapas
Como vemos, a las etapas se les puede añadir etiquetas, que aporten más
información al diagrama. En este caso, se despliega el menú de la Figura 5.7.
Figura 5.7: Vista de pantalla del menú de edición de etiquetas
En el cual podemos editar el texto de la etiqueta y la ubicación de la misma, a la
derecha o izquierda del diagrama.
Repetimos este proceso por cada una de las restantes etapas, y al finalizar la
operación el diagrama quedará editado tal como se observa en la Figura 5.8.
110
Casos de Estudio
Figura 5.8: Vista de pantalla del diagrama con edición de etiquetas
111
Casos de Estudio
Paso 5: Añadimos las acciones correspondientes a las etapas:
Pulsando con el botón derecho del ratón
encima de una etapa y seleccionando la
opción Acciones, nos aparece el panel de la
Figura 5.9. En él, podremos definir acciones
tipo S, R o = asociados a una posición
cualquiera o a un símbolo definido
previamente.
En este caso definimos la acción asociada a la
etapa 1.
Repetimos el mismo procedimiento para las
restantes etapas.
Figura 5.9: Vista de pantalla del menú acciones de la Taladradora
Paso 6: Añadimos las condiciones correspondientes a las transiciones:
Haciendo doble clic en una relación entre dos
etapas, nos aparece la ventana de la
Figura 5.10. En ella podemos definir el texto de
la etiqueta y todas las condiciones posibles
que nos permite el lenguaje.
Allí tenemos las alternativas de editar la
combinación de condiciones lógicas mediante
lenguaje de sentencias, o en forma gráfica
que es justamente la potencialidad que brinda
la herramienta, para abstraer al usuario del
lenguaje complejo y poco intuitivo del PLC.
Figura 5.10: Vista de pantalla del menú de condiciones de la Taladradora
Pulsando la opción Dibujo aparecerá la pantalla de la Figura 5.11, para editar gráfica e
intuitivamente la condición de una de las transacciones.
112
Casos de Estudio
Figura 5.11: Vista de pantalla de edición gráfica de una transición de la Taladradora
En el caso que el usuario optara por definir las condiciones en forma de sentencias,
por ejemplo un usuario experto y familiarizado con la programación de PLCs, para la
transición de la etapa 0 a 1, la condición estaría representada como se puede observar en la
pantalla de la Figura 5.12, la cual estaría conformada por la simultaneidad de que la broca
esté en rotación, en posición alta y pulsado el botón de marcha.
Figura 5.12: Vista de pantalla de condición de transición 0-1 en modo sentencias
Si por el contrario, optara por definir las condiciones en un lenguaje gráfico e
intuitivo, la condición descripta en el menú anterior quedaría definida como se observa en
la pantalla de la Figura 5.13.
113
Casos de Estudio
Figura 5.13: Vista de pantalla de condición de transición 0-1 en modo gráfico
Al pulsar el botón Aceptar, el sistema transcribirá en forma automática la cadena de
condiciones del modo gráfico al lenguaje de sentencias de PLC como se observa en la
pantalla de la Figura 5.14
La inclusión de paréntesis en la transcripción se da
por la concatenación de operadores pero esta
expresión es equivalente a la versión descripta
anteriormente donde la combinación lógica se
definía directamente en lenguaje de sentencias de
PLC.
Figura 5.14: Vista de pantalla transcripción de condiciones
114
Casos de Estudio
Repitiendo el mismo procedimiento para las restantes transiciones, de acuerdo a las
condiciones requeridas por el proceso en cada una de ellas, obtendremos como resultado el
diagrama de la Figura 5.15, completamente programado.
Figura 5.15: Vista de Pantalla del diagrama Grafcet completo de la Taladradora
Como podemos apreciar, hemos podido representar, de manera sencilla, el diagrama
funcional de la Figura 5.2, mediante la Herramienta desarrollada.
En este punto estaríamos en condiciones de descargar el código en lenguaje de PLC,
de forma automática mediante el botón Codigo.
115
Casos de Estudio
Simulación
En nuestro caso procederemos, antes de generar el código de programa, a efectuar
una prueba del proceso mediante la herramienta de simulación para depurar posibles
conflictos y de manera interactiva forzar variables del proceso que nos permitan visualizar la
ejecución del mismo.
Para ello, al pulsar el botón Simulacion aparecerá la pantalla de la Figura 5.16.
Figura 5.16: Vista de pantalla del estado inicial de Simulación
En este punto estamos en condiciones de interactuar con las variables del proceso.
Pulsando el botón Actualizar podemos observar que el ciclo de trabajo está en marcha
representado por el coloreo de la etapa inicial (Esperar). Es decir que el proceso está en
reposo tal como se muestra en la pantalla de la Figura 5.17
Figura 5.17: Vista de pantalla del proceso de simulación de la Taladradora en estado de reposo
116
Casos de Estudio
Para conocer cuáles son las variables que intervienen en una transición, en el caso de
tratarse de combinación múltiple, haciendo doble click en la transición se despliega la
visualización de cómo está conformada dicha transición, como se muestra en la pantalla de
la Figura 5.18
Figura 5.18: Vista de pantalla visualización de condiciones en simulación de la Taladradora
De esta forma, al clickear en el campo Valor de las variables de la transición 0-1
(PU_ON, Rot_Br y Pos_h) estamos forzando el valor lógico 1 a cada una de ellas, con lo cual
la transición es franqueada y el proceso pasará a la etapa 1. Esto lo veremos reflejado al
pulsar el botón Actualizar, con lo cual el cambio quedará visualizado en la pantalla de la
Figura 5.19.
Figura 5.19: Vista de pantalla franqueo de la transición 0-1 de la Taladradora
117
Casos de Estudio
De esta manera podemos proseguir con cada una de las transiciones, observando
cómo se comporta el sistema al efectuar los cambios de valores de variables.
Para comprender la robustez del sistema Grafcet vamos a ejemplificar una condición
real que puede ocurrir. En el estado de la Figura 5.19, es decir con el coloreo de la etapa 1,
veremos qué ocurre si forzamos el valor de la variable de la transición 2-3. Para esto
clickeamos en el valor de la variable correspondiente, que en este caso es solo una (Pos_b2).
El usuario podría pensar que al validarse la condición de esta transición, el sistema
debiera pasar a la etapa 3, sin embargo al pulsar el botón Actualizar ocurre lo observado en
la pantalla de la Figura 5.20.
Figura 5.20: Vista de pantalla del proceso con estado inalterable de salto de etapas
Es decir, el proceso no se modifica justamente porque se cumple el principio de la
regla de evolución del Grafcet, que especifica que para que sea franqueada una transición
debe estar activa la etapa inmediata anterior, en nuestro ejemplo se cumpliría si el sistema
se encontrara en la etapa 2. Para representar esto, forzamos la variable de la transición 1-2,
pulsamos el botón Actualizar y en este punto estaríamos recién en condiciones de validar la
condición de la transición 2-3.
De la misma manera el usuario puede comprobar cada uno de los estados del ciclo
del proceso y poder depurar el programa ante anomalías impensadas, ya sea por la falta de
condiciones necesarias o inclusive errores en la definición de las condiciones, por ejemplo
alguna de las variables que debieran tratarse como valores de verdad negados y se hubieran
definidas de forma inversa.
Si se pulsara el botón Reset, en cualquier punto del proceso, la ejecución pasará al
estado inactivo y se borran todos los valores forzados de las variables. En este caso
volveríamos al estado inicial de la simulación, en condiciones de ejecutar un nuevo ciclo de
Simulación.
118
Casos de Estudio
Generación de Código
Una vez realizadas todas las pruebas de Simulación que el usuario crea conveniente,
podríamos obtener el código final del programa a ser ejecutado por el PLC, en forma
automática. Para ello, si pulsamos el botón Codigo, obtendríamos el código del programa
correspondiente en la pantalla de la Figura 5.21.
Figura 5.21: Vista de pantalla con el código de programa generado automáticamente
Este código generado puede ser enviado a dispositivos de impresión, a través del menú
Archivo, con la opción Imprimir.
119
Casos de Estudio
5.2 Caso de Estudio N° 2
En esta Sección desarrollaremos un caso real aplicado sobre una línea de Producción
de Ladrillos cerámicos implementada en la Planta Industrial Loimar S.A., de la ciudad de
Tandil, cuyo automatismo se encuentra actualmente en funcionamiento.
Por una cuestión de simplificación, y como ya se ha explicado anteriormente el
funcionamiento de la herramienta, no nos detendremos en la construcción paso a paso del
diagrama, sino que resulta interesante mostrar las ventajas de la misma en el nivel de
Simulación, donde podremos observar las ventajas de realizar todas las pruebas pertinentes
del automatismo antes de su implementación práctica y prueba física del sistema.
Acopio de Pallets de ladrillos terminados
Se desea Automatizar una pinza de movimientos electromecánicos para el sector de
Empaquetado de ladrillos cocidos.
La funcionalidad radica en que permite crear un sector de Acopio de pallets
terminados, de manera de optimizar los movimientos de un Autoelevador (ver Figura 5.26),
guiada por operador, que en la actualidad es la que debe cargar cada grupo de 3 pallets
finalizados en la mesa (ver Figura 5.22) y transportarlos individualmente a la playa de Acopio
General de ladrillos, sitio desde donde son cargados en los camiones de transporte.
El sector creado estará constituido por 3 estaciones de almacenaje, llamados Boxes,
donde en cada estación se podrán almacenar hasta 3 filas de pallets compuestas por 3
pallets cada fila. Es decir que en cada estación de almacenaje se depositarán hasta 9 pallets
de ladrillos que serán cargados por el autoelevador una vez completado el Box
correspondiente, o todos los Boxes como se puede observar en la Figura 5.23.
Las ventajas analizadas a la hora de proyectar la obra fueron las siguientes:
•
Reducción significativa de los movimientos del autoelevador, ya que se reduciría
a solo un tercio la cantidad de movimientos, al pasar a trasportar 3 pallets en vez
de 1 como es en la actualidad.
•
Aumento considerable de la eficiencia de la línea de producción debido a que
brindaría la posibilidad de tener un pulmón de descarga sin riesgo, en un período
de tiempo razonable, de que la línea de empaquetado se vea imposibilitada de
continuar descargando si por alguna razón el autoelevador no llegase a cargar el
pallet terminado y en espera de liberación de la mesa, antes de que un próximo
pallet requiera arribar a la misma.
•
Funcionamiento absolutamente automático de manera que no requeriría contar
con nuevos puestos de trabajo para la operación funcional de la pinza. Además
contará con todos los elementos de seguridad de funcionamiento y con una tasa
de mantenimiento prácticamente nula, salvo lubricación y control de los
componentes mecánicos.
120
Casos de Estudio
Figura 5.22: Vista del Procedimiento aplicado anterior al Proyecto de Automatización
Figura 5.23: Vista del Procedimiento posterior al Proyecto de Automatización finalizado
121
Casos de Estudio
Vista General de la Instalación
Figura 5.24: Vista General de la Instalación
122
Casos de Estudio
Vista del Tablero Eléctrico General de Comando
Figura 5.25: Vista del Tablero de Comando General del Automatismo
Vista del Autoelevador Industrial
Figura 5.26: Vista de un Autoelevador para Transporte de Pallets
123
Casos de Estudio
5.2.1 Descripción
En la Figura 5.27 se representa el diagrama físico general de la instalación, en el cual
se ubican los elementos necesarios para efectuar el automatismo, tales como sensores
captadores de posición y actuadores electromecánicos que efectuarán los movimientos de
traslación e izaje de la pinza, en nuestro caso motores asincrónicos.
Figura 5.27 Diagrama general de la instalación
En la Figura 5.28 podemos observar la lista detallada de los componentes para
implementar el automatismo.
Símbolo
Función
Sensores de Detección de Traslación de Carro
Sensores de Detección de Presencia de Pallets en Boxes - Mesa
Sensores de Posicionamiento Final de Carro
Sensores de Detección de Niveles de Pinza
Sensor de Detección de Apoyo de Pallet
Motores Carro y Pinza
Figura 5.28: Componentes del Automatismo del Proceso
124
Casos de Estudio
En la Figura 5.29 podemos observar la descripción de la funcionalidad de los
componentes del ciclo del automatismo.
Símbolo
S1
S2
S3
S4
S5
S6
S7
S8
S9
S10
S11
S12
S13
S14
S15
S16
S17
S18
S19
S20
S21
S22
S23
S24
M1-A
M1-R
M1-V
M2-A
M2-D
M2-V
Descripción
Presencia Pallet para ser cargado
Presencia Pallet en Box 1 Fila 1
Presencia Pallet en Box 1 Fila 2
Presencia Pallet en Box 1 Fila 3
Presencia Pallet en Box 2 Fila 1
Presencia Pallet en Box 2 Fila 2
Presencia Pallet en Box 2 Fila 3
Presencia Pallet en Box 3 Fila 1
Presencia Pallet en Box 3 Fila 2
Presencia Pallet en Box 3 Fila 3
Posicionamiento Pinza Fuera de Operaciones
Posicionamiento Pinza en espera de carga
Posicionamiento Pinza Pallet cargado
Posicionamiento Pinza en Box 1
Posicionamiento Pinza en Box 2
Posicionamiento Pinza en Box 3
Posicionamiento Pinza Seguridad Traslación Adelante
Posicionamiento Pinza Retroceso Pallet descargado
Posicionamiento Pinza Ajuste Final de Parada
Posicionamiento Pinza en Nivel Inferior
Posicionamiento Pinza en Nivel de Carga
Posicionamiento Pinza en Nivel Superior
Posicionamiento Pinza Apoyo Pallet
Detección Pallet cargado en pinza
Avance Traslación Pinza
Retroceso Traslación Pinza
Movimiento Traslación Veloz
Movimiento Ascenso Pinza
Movimiento Descenso Pinza
Movimiento Izaje Veloz
Figura 5.29: Descripción de los componentes para la automatización de la pinza de acopio
125
Casos de Estudio
5.2.2 Ciclo de funcionamiento
1. La pinza permanecerá en reposo en posición de espera de carga de un nuevo grupo
de Pallets.
2. Cuando arriba un grupo a la mesa (S1) debe efectuar el movimiento de traslación de
avance hasta una posición fija de carga (S13) a Velocidad "Lenta" prefijada de
manera de enhebrar las uñas en los huecos de la tarima de madera sobre la cual se
deposita el pallet de ladrillos.
3. Una vez cargado el pallet debe efectuar el movimiento de ascenso a velocidad
"Veloz" prefijada hasta una posición fija de Nivel superior (S22).
4. La prioridad es siempre desde adelante hacia atrás, es decir que el orden de descarga
será Box 3 -> Box 2 -> Box 1, inalterable por ninguna razón.
5. Si se ha liberado un Box posterior se debe respetar el orden de descarga, es decir que
si se ha descargado un pallet en el Box 2, y en ese momento se liberase el Box 3, de
todas maneras se debe continuar a completar los 3 niveles del Box 2 y luego se
pasaría al Box 1. Este motivo se debe a que como la pinza, al descarga un pallet, debe
efectuar un movimiento de retroceso para liberar las uñas, no debería existir
obstáculo de pallet alguno que imposibilite esta operación.
6. Siempre que se haya depositado un pallet en uno de los niveles de un Box, debe
continuar operando con el mismo hasta completar los 3 Niveles.
7. En el momento que la pinza carga un pallet de la mesa, y asciende hasta la posición
fija para trasladarse, deben chequearse las condiciones de prioridad y espacio libre
para efectuar la descarga, caso contrario permanecerá en esta posición a la espera de
condiciones seguras.
8. Una vez comprobado el puesto de descarga, la pinza efectúa el movimiento de
traslación de avance hasta la posición fija del box correspondiente, a una velocidad
"Veloz" prefijada.
9. Al arribar al sensor de posicionamiento de traslación de box adecuado, el
movimiento de traslación continúa a una velocidad "Lenta" de aproximación
prefijada hasta la posición de ajuste final de parada de la traslación (S19).
10. En el Box correspondiente, la pinza efectúa el movimiento de descenso a una
velocidad "Veloz" prefijada.
11. Al llegar a obstruirse el sensor de Nivel de box correspondiente a la fila a descargar,
el movimiento de descenso continúa a una velocidad de aproximación "Lenta"
prefijada, hasta el posicionamiento de Pallet descargado (S23).
12. Una vez depositado el pallet, comienza el movimiento de traslación en retroceso a
velocidad "Lenta" prefijada, hasta una posición fija para liberar uñas (S18).
13. Una vez liberadas la uñas debe ascender a velocidad "Veloz" prefijada hasta la
posición fija de nivel superior (S22).
14. En posición de nivel superior, apta para traslación, debe efectuar el retroceso a
velocidad "Veloz" prefijada hasta posición de espera de carga en mesa (S12).
126
Casos de Estudio
15. Al arribar al sensor de posicionamiento de traslación en mesa de carga, el
movimiento de traslación continúa a una velocidad "Lenta" de aproximación
prefijada hasta la posición de ajuste final de parada de la traslación (S19).
16. En la posición de Debe efectuar el movimiento de descenso a velocidad "Veloz"
prefijada hasta posicionamiento en Nivel de carga (S21).
17. Fin del ciclo Automático.
En este punto es importante resaltar la importancia del objetivo principal del
presente trabajo debido a que, actualmente, a la hora de realizar la programación del
automatismo, el usuario programador debe confeccionar en forma manual, a mano alzada,
un diagrama propicio para el seguimiento del ciclo ya que no se cuenta con una herramienta
útil para crear el diseño del ciclo del proceso y posteriormente poder transcribirlo al lenguaje
de PLC.
Como se puede apreciar en la Figura 5.30, se cita a modo de ejemplo un fragmento
del ciclo del automatismo con el cual se creará posteriormente el programa de control en el
software propio del PLC.
Figura 5.30: Ejemplo del diseño del automatismo de la pinza
127
Casos de Estudio
Una vez finalizado el diagrama, con todos los componentes intervinientes en el
automatismo, el programador deberá transcribir el diagrama funcional en el lenguaje propio
del PLC, y mediante el software correspondiente al fabricante del mismo. En el caso de la
Figura 5.31, el programa está basado en la línea S7-300 de Siemens.
Figura 5.31: Fragmento de código de programa en lenguaje de PLC
Con esto queda evidenciado que el automatismo debe ser llevado a cabo por
usuarios expertos en programación de sistemas basados en PLCs, lo cual resalta la
importancia del objetivo principal del presente proyecto, que es justamente desarrollar una
herramienta que permita a un usuario inexperto abstraerse del mundo de los autómatas, ya
que solamente deberá focalizarse en diseñar un diagrama Grafcet del automatismo y la
herramienta posteriormente generará de manera automática el código del programa del
PLC.
128
Casos de Estudio
5.2.3 Implementación con la Herramienta
Por una cuestión de simplicidad y mejor comprensión del ejemplo optaremos por
acotar el ciclo de trabajo sólo para el acopio en el Box 3. De todas maneras será suficiente
para el caso que se desea mostrar en lo que respecta a funcionalidad de la Herramienta.
Paso 1: Una vez identificadas las variables, de acuerdo a la lista de la Figura 5.29 procedemos
a definir la tabla de símbolos en la pantalla de la Figura 5.32.
Figura 5.32: Vista de pantalla de la tabla de símbolos de la pinza de acopio
129
Casos de Estudio
Paso 2: De acuerdo a la descripción del automatismo, identificamos las etapas que van a
componer el diagrama funcional del mismo, tal como se representa en la Figura 5.33.
Figura 5.33: Diagrama Funcional de Ejecución del ciclo
130
Casos de Estudio
Basándonos en el esquema funcional de la Figura 5.33, crearemos el diagrama Grafcet
que controlará el automatismo en cuestión. Dibujaremos las etapas y conexiones como se
observa en la pantalla de la Figura 5.34.
Figura 5.34: Vista de pantalla con etapas y conexiones del Grafcet de la Pinza de Acopio
131
Casos de Estudio
Paso 3: Añadimos las etiquetas a cada una de las etapas, pulsando botón derecho encima de
la etapa y luego seleccionando la opción Añadir etiqueta del menú desplegable. Como resultante
obtendremos el diagrama de la pantalla de la Figura 5.35.
Figura 5.35: Vista de pantalla con etiquetas en etapas del Grafcet de la Pinza de Acopio
132
Casos de Estudio
Paso 4: Definimos las condiciones de transición entre las etapas. Por ejemplo, para la
transición entre las Etapas 0 (En Reposo) y 1 (Carga Pallets en Mesa), las condiciones que
deben validarse, en forma simultánea, son las siguientes:
-
Pinza en Posición de Carga (S12)
Posición Pinza en Nivel de Mesa (S21)
Selección Funcionamiento Automático (Auto)
Presencia de Pallet para ser cargado (S1)
Dibujamos la combinación lógica mediante el submenú Dibujo dentro de la ventana de
Condición - Relación 0 – 1 de la pantalla de la Figura 5.36.
Figura 5.36: Vista de pantalla edición gráfica de condición 0-1 del Grafcet de la Pinza de Acopio
Al finalizar la edición de la combinación
lógica, pulsando el botón Aceptar, quedarán
definidas las condiciones en formato de lista
de instrucciones tal como se observa en la
Figura 5.37
Figura 5.37: Vista de pantalla condiciones etapa 0-1 Grafcet de la Pinza de Acopio
133
Casos de Estudio
Paso 5: Aplicando el mismo procedimiento, definimos las etiquetas de todas las transiciones
del ciclo, así como también las combinaciones de condiciones lógicas que comprenden cada
una de ellas obteniendo en pantalla el diagrama de la Figura 5.38.
Figura 5.38: Vista de pantalla con etiquetas en transiciones Grafcet de la Pinza de Acopio
134
Casos de Estudio
Paso 6: Añadimos las acciones correspondientes a las etapas pulsando con el botón derecho
del ratón encima de una etapa y seleccionando la opción Acciones. Nos aparece el panel de
la Figura 5.39.
En este caso definimos la acción asociada a la etapa 1, que según el diagrama funcional
corresponde al movimiento de avance lento para efectuar la carga del pallet.
Figura 5.39: Vista de pantalla de edición de acciones Etapa 1 del Grafcet de la Pinza de Acopio
De la misma forma repetimos el procedimiento para las restantes etapas,
basándonos con el diagrama funcional y la tabla de símbolos.
De esta manera el ciclo del Automatismo estará plenamente programado, y en
condiciones de generar el código Automático de programa en lenguaje de PLC.
135
Casos de Estudio
Simulación
Procederemos, antes de generar el código de programa, a efectuar una prueba del
proceso mediante la herramienta de simulación, para depurar posibles conflictos y explicar
algunos casos concretos para una mejor comprensión de las ventajas de la Herramienta.
Tal como se ha mencionado en el caso de Estudio N° 1, al pulsar el botón Simulación
aparecerá la pantalla correspondiente y como primera instancia de ejecución, al pulsar el
botón Actualizar, el sistema permanecerá con la Etapa Inicial activada en condiciones de
ejecutar el ciclo, es decir a la espera de que sean franqueadas las condiciones de la
transición 0-1, lo cual puede visualizarse en la pantalla de la Figura 5.40.
Figura 5.40: Vista de pantalla simulación estado de reposo del Grafcet de la Pinza de Acopio
Desde el punto de vista de la realidad del proceso, podemos representar el estado
inicial del ciclo de simulación virtual con las imágenes de la Figura 5.41 , en las cuales se
puede apreciar el estado de la pinza en tal condición.
136
Casos de Estudio
Figura 5.41: Vista real de la Pinza de Acopio en estado inicial del ciclo
El siguiente paso del ciclo
seria forzar el estado de las
variables que intervienen en la
condición de la transición de paso
de la Etapa 0 a la Etapa 1.
En los casos en que dicha
condición esté conformada por
una combinación de variables, y
el usuario obviamente no tenga
la certeza acerca de cuáles son
dichas variables, haciendo doble
click sobre la transición en
cuestión, aparecerá la pantalla de
edición de las condiciones y de
esta manera se podrá constatar
qué valores se deben validar o
forzar para pasar a la próxima
etapa como podemos apreciar en
la Figura 5.42
Figura 5.42: Vista de pantalla consulta de condición Grafcet de la Pinza de Acopio
137
Casos de Estudio
De esta forma, al forzar los valores de las variables correspondientes sobre la tabla de
la derecha, y al pulsar el botón Actualizar el ciclo del proceso pasará a la Etapa 1 como se
puede apreciar en la pantalla de la Figura 5.43.
Figura 5.43: Vista de pantalla franqueo de transición 0-1 Grafcet de la Pinza de Acopio
Es decir que en este punto la pinza comenzará a efectuar el proceso de carga, el cual
consiste, de acuerdo a las acciones implementadas en tal etapa, en el movimiento en
sentido de avance, a velocidad lenta de manera de enhebrar las uñas en los huecos de las
tarimas de madera sobre las cuales están depositados los pallets tal como se representa en
la Figura 5.44.
Uñas de la Pinza
Figura 5.44: Enhebrado de Uñas de la pinza para carga de pallets
138
Casos de Estudio
Esta situación podemos representarla, en el estado real de la instalación, mediante
las fotografías de la Figura 5.45, donde podemos apreciar el proceso de carga de la pinza
sobre un nuevo grupo de pallets que han arribado.
Figura 5.45: Vista real de la Pinza en Estado de Carga de Pallet
De la misma manera podemos interactuar sobre la tabla de valores de variables de la
simulación, y visualizando el comportamiento del ciclo del automatismo, verificando que se
cumpla el funcionamiento del sistema en respuesta a los cambios de estado de las variables
implicadas en cada punto.
Este proceso nos permitirá constatar que no se produzcan cambios de etapas si no
están dadas las condiciones permitidas, o por el contrario chequear ante posibles casos en
que no se produzca el cambio de estado debido a condiciones faltantes o inclusive defectos
en la programación de las condiciones.
Así por ejemplo podemos representar la analogía del comportamiento del proceso
de Simulación con el estado real de la instalación física de acuerdo a las siguientes
ilustraciones:
139
Casos de Estudio
Estado del Sistema en Etapa 2: Ascenso Veloz en Mesa (Figura 5.46)
Figura 5.46: Vista real de la pinza con el Estado del Sistema en Etapa 2
Estado del Sistema en Etapa 3: Traslación Veloz a Boxes (Figura 5.47)
Figura 5.47: Vista real de la pinza con el Estado del Sistema en Etapa 3
140
Casos de Estudio
Estado del Sistema en Etapa 5: Descenso Veloz en Box 3 (Figura 5.48)
Figura 5.48: Vista real de la pinza con el Estado del Sistema en Etapa 3
Estado del Sistema en Etapa 6: Descenso Lento en Box 3 (Figura 5.49)
Figura 5.49: Vista real de la pinza con el Estado del Sistema en Etapa 6
141
Casos de Estudio
Estado del Sistema en Etapa 7: Retroceso Lento en Box 3 (Figura 5.50)
Figura 5.50: Vista real de la pinza con el Estado del Sistema en Etapa 7
De esta manera el usuario puede forzar distintas situaciones de eventos para
comprobar el comportamiento ante posibles anomalías y de esta manera depurar las
combinaciones lógicas de las distintas transiciones entre etapas o acciones dentro de cada
una de las mismas.
A continuación analizaremos 2 casos prácticos que pueden ocurrir perfectamente
durante el desarrollo de la implementación y comprobar la importancia que brinda la
herramienta en lo que respecta a poder solucionar conflictos antes de efectuar la puesta en
marcha física del sistema.
Primer Caso:
De acuerdo a la pantalla de la Figura 5.51, vemos que las condiciones de la transición
de la Etapa 1 a la Etapa 2 están definidas por un operador OR entre los Operandos:
 S12 (Posicionamiento Pinza en espera de carga)
 S24 (Detección Pallet cargado en pinza)
Esto significa que ante la validación de cualquiera de las dos variables, el sistema
franqueará la transición y pasará al estado de activación de la Etapa 2 (Ascenso de la Pinza),
es decir que la carga del pallet se ha cumplido.
Esta situación es válida y en la mayoría de los casos se cumple perfectamente con lo
cual la operación se efectúa sin inconvenientes.
142
Casos de Estudio
Figura 5.51: Vista de pantalla Condiciones de Transición 1-2 con Operador OR
Sin embargo, como hemos explicado con anterioridad, la forma de carga del pallet a
través de la pinza, con el enhebrado de las uñas en la tarima de madera, pueden ocurrir
casos como se representa en la Figura 5.52.
Figura 5.52: Vista de la situación con tarimas defectuosas
Con lo cual, por defecto en la tarima, las uñas no serán enhebradas, pero sin
embargo la posición de fin de carga de la pinza será validada ya que no hay impedimento
para efectuar el movimiento de traslación. De esta manera el sistema pasará a la Etapa 2
(Ascenso de la Pinza), provocando la situación que se representa en la Figura 5.53.
143
Casos de Estudio
Figura 5.53: Ilustración Incidente provocado por tarimas defectuosas
Para solucionar este tipo de conflicto, el usuario debiera modificar las condiciones de
transición correspondiente de manera de contemplar la simultaneidad de las 2 variables que
intervienen y de esta manera asegurarse que la pinza está en la posición correcta de carga y
se detecte la carga efectiva del pallet por parte de las uñas de la pinza, o sea perfectamente
enhebradas. Esta modificación quedaría representada por la pantalla de la Figura 5.54.
Figura 5.54: Vista de pantalla Condiciones de Transición 1-2 con Operador AND
144
Casos de Estudio
Segundo Caso:
De acuerdo a la pantalla de la Figura 5.55, vemos que la condición de transición de la
Etapa 2 a la Etapa 3, es decir la traslación de la pinza una vez cargado en pallet en la mesa, se
valida cuando la Pinza está arriba de la mesa con el pallet cargado.
Figura 5.55: Vista de pantalla de la condición de transición 2-3 Grafcet de la Pinza de Acopio
El usuario comprueba que al cabo de efectuar 3 ciclos del proceso, es decir ha
depositado los 3 grupos de pallets en el Box correspondiente, al cargar el cuarto grupo de la
mesa, y al validarse la transición, el sistema activa la Etapa 4 del ciclo (Traslación veloz a
Boxes), con lo cual se produce el incidente mostrado en la Figura 5.56.
Figura 5.56: Ilustración Incidente provocado por sobre- acopio de Pallets
145
Casos de Estudio
Esta situación puede producirse cuando el autoelevador no desocupa el box antes
de que la pinza cargue el cuarto grupo de la mesa, por cualquier circunstancia que demore el
normal transporte de pallets a la playa de acopio.
La manera de contemplar y solucionar esta situación sería adicionando a la condición
de la transición, la condición que contemple que al menos hay lugar para depositar un grupo
en el Box, que sería utilizando el sensor que determina la presencia de pallets en el Nivel 3
del Box (S10).
De esta forma la condición quedaría modificada como se muestra en la pantalla de la
Figura 5.57.
Figura 5.57: Vista de pantalla de la condición de transición 2-3 modificada
Con estos casos de análisis queda de manifiesto la importancia, para el usuario, de lo
que representa efectuar una prueba exhaustiva del proceso, que permita depurar la
programación del automatismo de tal manera de minimizar los futuros riesgos que
representarían los incidentes planteados si se efectuara la puesta en marcha física del
sistema sin posibilidad de pruebas preliminares.
Una vez finalizada la etapa de simulación del sistema, y efectuadas las depuraciones
necesarias del proceso automático, se podrá generar el código de programa generado en
forma automática. Para ello, si pulsamos el botón Codigo, del menú superior, obtendríamos
el código del programa correspondiente en lenguaje de PLC como se puede observar en la
pantalla de la Figura 5.58.
Mediante la opción Imprimir del Menú Archivo se puede descargar el programa en
dispositivos de impresión.
146
Casos de Estudio
Figura 5.58: Vista de pantalla código de programa generado de la Pinza de Acopio
147
Conclusiones
Capítulo 6 - Conclusiones
Luego de haber realizado una investigación inicial, donde se introdujo al lector en
conceptos importantes y necesarios para poder tener una visión completa y entender los
temas desarrollados en todo el trabajo, se planteó la problemática actual frente a la
implementación de un sistema automático de control industrial.
También se plantea la comparación, en cuanto a ventajas y desventajas que
presentan otras aproximaciones comerciales existentes en el mercado.
Estas herramientas si bien presentan diferentes propuestas que intentan brindar
ayuda al usuario, y facilitar la tarea de programación en el área del Control Automático, se
pudieron encontrar algunas deficiencias o faltantes que no permiten lograr una asistencia
integral y adecuada.
A partir de las deficiencias encontradas, se elaboró una herramienta de asistencia
amigable, capaz de brindar ayuda en temas de diseño de control automático secuencial. A
través de una interfaz clara y sencilla se pretende maximizar la usabilidad y la interacción
con los usuarios.
El beneficio adquirido al utilizar la propuesta planteada, es la separación de las
responsabilidades, fundamental para el mantenimiento del sistema y el desarrollo de
posibles futuras extensiones.
A partir de las pruebas realizadas en el capítulo anterior, se observó un
comportamiento satisfactorio de la herramienta. Los niveles de éxito entregados en cada
prueba se encontraron dentro del rango de los valores esperados, en general se lograron
buenos resultados.
La interfaz demostró ser simple e intuitiva, presentando la información de una forma
clara y precisa. Al realizar las pruebas se pudo comprobar un mínimo nivel de dificultad en
los casos en los que se trataba de usuarios de escaso nivel de conocimiento en programación
de PLCs, obteniendo prácticamente los mismos resultados que las pruebas llevadas a cabo
por personal experto en la materia.
Como se puede ver, utilizando diferentes escenarios en diversas aplicaciones, y
diversidad de niveles de experiencia por parte de los usuarios, los resultados son
prometedores y corroboran que el proceso cumple con su propósito.
Del mismo modo, y luego de las pruebas efectuadas, se identificaron algunas
limitaciones que presentaremos en las secciones posteriores.
A continuación se enumeran algunas de las ventajas que brinda el asistente así como
también algunas de sus limitaciones conocidas. Finalmente veremos algunas posibles
extensiones o trabajos futuros que han ido surgiendo durante el desarrollo y se consideraron
importantes.
148
Conclusiones
6.1 Ventajas
Algunas de las ventajas que se encontraron y fueron consideradas como relevantes
para presentar, son las siguientes:
 La utilización de la herramienta ofrece al usuario novato un aprendizaje en el área de
diseño de automatismos de control automático industrial. Esto se debe a que por el
grado de abstracción que ofrece la propuesta, el usuario puede desarrollar un
proceso de control sin mayores requisitos más que la experiencia práctica que brinda
el conocimiento de la instalación e incorporar nuevos conocimientos a medida que
utiliza la herramienta.
 La herramienta brinda al personal responsable de la ingeniería de proyectos de
Automatización, la posibilidad de delegar la tarea, al menos en parte, del diseño del
proceso así como también la programación del mismo ya que ofrece como resultado
final el código generado en forma automática.
 La interfaz gráfica de la herramienta es sencilla, práctica y concisa, permitiendo al
usuario una rápida adaptación al sistema de desarrollo.
 El módulo de simulación de la herramienta brinda a usuarios novatos la posibilidad
de efectuar todas las modificaciones y/o correcciones necesarias en la definición de
condiciones lógicas, liberándolos de la responsabilidad que significaría afrontar los
riesgos directos que puede causar la puesta en marcha física sin pruebas virtuales
previas.
 Las funcionalidades principales se dejaron totalmente abiertas para su extensión. De
este modo, se pueden realizar distintas implementaciones para generar dichas
funcionalidades y adaptarlas a la aplicación sin ningún tipo de impedimentos
aprovechando la flexibilidad que brinda la Programación Orientada a Objetos.
 La herramienta fue desarrollada en código Java, favoreciendo la portabilidad a
distintos sistemas operativos.
 Al estar integrada con el IDE Eclipse, logra combinar la rama del diseño de software
con el desarrollo del código que lo materialice.
149
Conclusiones
6.2 Limitaciones
Algunas de las limitaciones encontradas son las siguientes:
 Si bien la interfaz es sencilla e intuitiva el usuario debe tener algún conocimiento
previo del funcionamiento de la metodología Grafcet, ya que la herramienta carece
de un sistema de ayuda.
 El ámbito de condiciones lógicas en la definición de transiciones está acotada a
funciones básicas de operaciones con bits impidiendo realizar operaciones de carga,
transferencia de variables analógicas (Bytes, palabras), así como también
operaciones de conteo y temporización.
 Si bien la herramienta brinda la posibilidad de editar las condiciones lógicas de las
transiciones en modo gráfico, del tipo compuertas lógicas y posterior conversión a
listas de sentencias, no permite la reciprocidad, es decir obtener en modo gráfico las
condiciones en formato de instrucciones.
 La herramienta brinda la posibilidad de generación de código de PLC, pero en este
caso está limitado a una única línea de autómatas programables con su
correspondiente lenguaje y manejo de variables (concretamente S7-300 de Siemens).
 En cuanto al código de programa generado, la herramienta permite la salida a
dispositivos de impresión pero no permite su descarga directa al dispositivo real que
controla el automatismo, es decir la propia CPU del autómata.
 La herramienta no permite la importación de diagramas confeccionados en otros
sistemas posibles que no sean de formato propio de la herramienta.
150
Conclusiones
6.3 Trabajos futuros
Luego de haber presentado las conclusiones obtenidas a partir de los experimentos
realizados en este trabajo, se presentan los trabajos futuros que se podrían realizar
continuando con la misma línea de investigación.
Partiendo de la premisa de que por la estructura empleada en este trabajo, puede ser
extendido en numerosos aspectos, y conociendo las limitaciones resultantes se presentarán
los tópicos principales sobre los cuales se puede trabajar:
Ampliar el ámbito de condiciones lógicas en la definición de transiciones a todo el
universo de operaciones soportadas por un autómata programable industrial.
Ampliar el universo de lenguajes de programación basados en PLCs de manera que el
código generado pueda ser compatible con un mayor número de controladores
existentes en el mercado comercial. Esto brindaría la transparencia de un proyecto
creado, independizándolo del dispositivo físico que se fuera a utilizar, inclusive
reutilizar el proyecto en caso que se produzca un cambio en el hardware del
Automatismo.
Inclusión de los drivers y protocolos de comunicación PC<->PLC de manera que
permita que el código de programa generado, sea descargado directamente en el
dispositivo de control.
Como extensión del ítem anterior, podría vincularse la visualización de ejecución del
Grafcet en el modo simulación, con las variables reales del Autómata de manera que
la visualización del estado del sistema concuerde con la realidad del proceso.
Integrar un sistema de Supervisión, Control y Adquisición de Datos (SCADA),
(Rodríguez Penin, 2015) de manera de vincular, en el modo simulación, la
visualización del estado del sistema con el estado de proceso a nivel dinamización
gráfica de la instalación, tales los casos de ejemplo que se pueden observar en la
Figura 6.1 (estado en Etapa 2) y en la Figura 6.2 (estado en Etapa 3), en los que
además de dinamizar la posición actual respecto del estado del diagrama, también
pueden señalizarse el estado de los componentes del proceso (coloreo de sensores
de posición y actuadores).
151
Conclusiones
Figura 6.1: Dinamización del Sistema en Etapa 2: Ascenso veloz en Mesa
Figura 6.2: Dinamización del Sistema en Etapa 3: Traslación Veloz a Boxes
152
Bibliografía
Capítulo 7 - Bibliografía
1. AG, S. (2004). S7-Graph V5.3 para S7-300/400 Programación de Controles Secuenciales.
Nümberg: Siemens Energy & Automation .
2. Boix Aragonés, O., Sudía Andreu, A., & Bergas Jané, J. (1997). Automatización industrial con
Grafcet. Ediciones UPC.
3. Bolton, W. (1996). Instrumentación y control industrial. Paraninfo.
4. Bossy, J.-C., Brard, P., Faugère, P., & Merlaud, C. (1995). Grafcet. Práctica y aplicaciones.
Universitat Politécnica de Catalunya.
5. Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P., & Stal, M. (1996). Pattern-Oriented
Software Architecture, Volume 1: A System of Patterns. Inglaterra: John Wiley & Sons.
6. Clements-Jewery, K., & Jeffcoat, W. (1996). The PLC Workbook. EEUU: Prentice Hall.
7. Dahl, O.-J., Myhrhaug, B., & Nygaard, K. (1967). Simula 67 common base language. Noruega:
Norwegian Computer Center.
8. Eckel, B. (1998). Thinking in Java. Prentice-Hall.
9. Gálvez Rojas, S., Alcaide García, M., & Mora Mata, M. (2007). Como tratar con JAVA Figuras,
Imágenes y Texto en 2D. Edición Electrónica.
10. Gamma, E. (1995). Design patterns: elements of reusable object-oriented software. Pearson
Education India.
11. García Higuera, A. (2005). El control automático en la industria. Universidad de Castilla La
Mancha.
12. Garzón Vásquez, J. A. (2013). Lógica Cableada.
13. Gilbert, D. (2002). The JFreeChart Class Library. Simba Management Limited.
14. Glodberg, A., & Robson, D. (1983). Smalltalk-80: the language and its implementation.
Addison-Wesley Longman Publishing Co., Inc.
15. Gómez Crespo, D. (1999). Sistemas Secuenciales Grafcet. Bilbao: Dpto. Ingeniería de Sistemas
y Automática Escuela Superior Técnica de Bilbao.
16. Hill, F. J., & Peterson, G. R. (1979). Teoría de conmutación y diseño lógico. México: Limusa.
17. https://docs.oracle.com/javase/7/docs/api/javax/swing/package-summary.html. (s.f.).
18. Karl-Heinz, J., & Tiegelkamp, M. (2001). IEC 61131-3: Programming Industrial Automation
Systems. Alemania: Springer Verlag.
19. Knudsen, J. (1999). JAVA 2D Graphics. O´Reilly.
153
Bibliografía
20. Korson, T., & McGregor, J. (1990). . Understanding Object Oriented: a Unifying Paradigm.
Communications of the ACM. 33(9).
21. Marcos, M., Estévez, E., Gangoiti, U., & Portillo, J. (2001). Generador de Código IEC 61131
basado en tecnologías XML.
22. Meyer, B. (1988). Object-oriented software construction, volume 2. New York: Prentice hall .
23. Omron Industrial Automation. (s.f.). http://www.ia.omron.com/products/family/16/.
24. Oracle. (1995). The Java Tutorial. Obtenido de http://java.sun.com/
25. Peñin, L. F., Carrera, J., & Barrientos, A. (1999). Automatización de la fabricación: autómatas
programables, actuadores, transductores. Madrid: Universidad Politécnica de Madrid.
26. Rodríguez Penin, A. (2015). Sistema Scada 2da. Ed. Marcambo.
27. Sánchez Llopis, R., Romero Pérez, J. A., & Ariño Latorre, C. V. (2010). Automatización
Industrial. Universitat Jaume I.
28. Schneider Electric. (s.f.). http://www.schneider-electric.com/en/product-range/1468modicon-m340/.
29. Siemens. (2001). Manual S7-300 Instalación y configuración, lista de operaciones. Nümberg:
Siemens Enegy & Automation.
30. Siemens, A. (1998). El Grafcet. Práctica y aplicaciones. Siemens Energy & Automation.
31. Siemens, A. (2004). S7-Graph V5.3 para S7-300/400 Programación de Controles Secuenciales.
Nürberg: Siemens Energy & Automation.
32. Siemens, A. (2011). Manual S7-300. Instalación y Configuración, datos de CPU, datos de
módulos, lista de operaciones. Nürberg: Siemens Electric & Automation.
33. Siemens.com. (s.f.). http://www.siemens.com.ar/sites/internet/legacy/siepe/pe/automatizacion.htm.
34. Wirfs-Brock, R., & McKean, A. (2003). Object Design: Roles, Responsibilities, and
Collaborations. . Addison-Wesley.
154
Apéndice A
Apéndice A
Herramienta en Acción
155
Apéndice A
Índice
A.1 Editor Grafcet ............................................................................................................ 157
A.1.1 Abrir el Editor ........................................................................................................... 157
A.1.2 Descripción de componentes ................................................................................... 158
A.1.2.1 El menú .............................................................................................................. 158
A.1.2.2 Botones .............................................................................................................. 159
A.1.2.3 Etiquetas ............................................................................................................ 160
A.1.3 Ejemplos ................................................................................................................... 161
A.1.3.1 Transición entre dos etapas .............................................................................. 161
A.1.3.2 Divergencia en Y ................................................................................................ 162
A.1.3.3 Convergencia en Y ............................................................................................. 163
A.1.3.4 Crear una Acción................................................................................................ 164
156
Apéndice A
A.1 Editor Grafcet
El editor Grafcet, es una herramienta que nos permite crear un diagrama de
control grafcet y generar el código asociado directamente.
En las siguientes secciones brindaremos un panorama general de la
herramienta, así como también una breve descripción e ilustración de los
componentes del sistema.
A.1.1 Abrir el Editor
Para abrir el editor hay que abrir la aplicación GRAFCET, a continuación nos
aparecerá la pantalla mostrada en la Figura A- 1:
Figura A- 1: Vista de la Interfaz de edición de Grafcet
Se trata de la pantalla principal del editor. A continuación describiremos sus
componentes.
157
Apéndice A
A.1.2 Descripción de componentes
A continuación describiremos los elementos que componen la interfaz de la
herramienta así como también su correspondiente funcionalidad.
A.1.2.1 El menú
En él podremos realizar las siguientes acciones:





Guardar: Permite guardar el grafcet actual en el directorio seleccionado.
Leer: Permite recuperar un grafcet guardado con anterioridad.
Nuevo: Elimina el grafcet actual y comienza de cero un nuevo dibujo.
Imprimir: Envía a dispositivo de Impresión el código de programa generado
Salir: Nos saca del Editor Grafcet.
158
Apéndice A
A.1.2.2 Botones
Los botones sólo son aplicables a la ventana de diseño.
Sirven para crear el diagrama grafcet.
Los describiremos uno a uno:
Este botón sirve para seleccionar la posición puntero.
De este modo, podremos mover las figuras del diagrama.
Posición etapa inicial. En esta posición al pulsar dentro del
panel de dibujo se creará una etapa inicial en el lugar
pulsado. Si ya existiese uno, ignoraría el evento.
Posición etapa. En esta posición, al pulsar dentro del panel
de dibujo se crea una etapa en la posición pulsada. Si ya
existiese un elemento en esa posición ignoraría el evento.
Posición línea. En esta posición, se puede crear una relación
entre dos etapas, o línea especial. Existen dos modos. Punto
a punto y de forma automática.
Línea simultánea. En esta posición, al pulsar en el panel de
dibujo se crea una línea de este tipo en el panel.
Línea conjunta. En esta posición, al pulsar en el panel de
dibujo se crea una línea de este tipo en el panel.
Rejilla. Pulsando en este botón se activa o se oculta la
cuadrícula en el panel de dibujo.
Autoajuste. Pulsando en este botón, se activa o desactiva el
ajuste automático a la cuadrícula del panel de dibujo.
159
Apéndice A
A.1.2.3 Etiquetas
A continuación describiremos para que sirven cada una de las etiquetas de la
herramienta.

Dibujo
Sirve para que aparezca la ventana de dibujo del
diagrama.
En la parte inferior del panel aparece la siguiente etiqueta.
Sirve para seleccionar el panel grafcet que queremos
ver. Pulsando en la etiqueta más, creamos un grafcet
nuevo.

Código
Sirve para visualizar el código que se está generando
a partir del grafcet creado (ver Figura A- 2)
Figura A- 2: Vista de pantalla de generación de código
160
Apéndice A

Asignar bits
Esta opción está directamente relacionada con el
lenguaje de PLC en que será generado el código, por
lo que no se cree conveniente para este propósito
detenernos en mayores explicaciones. Aparece una
tabla como la de la Figura A- 3.
Figura A- 3: Vista de pantalla de asignación de bits

Tabla de Símbolos
Sirve para ver los símbolos que se crean
automáticamente, modificar el valor de los
mismos, o crear nuestros propios símbolos. Al pulsar
aparece la tabla de la Figura A- 4
Figura A- 4: Vista de pantalla de tabla de símbolos
A.1.3 Ejemplos
A continuación emplearemos algunos ejemplos básicos para facilitar la
comprensión de las distintas funcionalidades de la herramienta en el desarrollo de un
proyecto, y familiarizar al lector en la modalidad de trabajo de la misma.
A.1.3.1 Transición entre dos etapas
El primer paso una vez abierto el editor es crear dos etapas. Hay que tener en
cuenta que en todo grafcet es obligatorio la existencia de una etapa inicial.
En este caso vamos a crear una transición entre una etapa inicial y una etapa
normal.
Paso 1: Pulsamos el botón de etapa inicial
Paso 2: Pulsamos en la ventana de edición donde queremos situar la etapa
161
Apéndice A
Paso 3: Pulsamos el botón de etapa
Paso 4: Pulsamos en la ventana de edición donde queremos situar la etapa
Paso 5: Pulsamos en el botón línea
Paso 6: Pulsamos en la etapa inicial y a continuación en la etapa final. En este
caso, por ser la etapa origen la inicial, aparece el comentario
directamente
Paso 7: Hacer doble clic en la transición y seleccionar la condición de paso de
una etapa a otra, y el texto a mostrar, en la pantalla de la Figura A- 5.
Figura A- 5: Vista de pantalla de edición de condiciones
A.1.3.2 Divergencia en Y
Paso 1: Creamos una etapa origen y dos etapas destino. Pulsamos en el botón
etapa, y tres veces en la pantalla de panel de dibujo
162
Apéndice A
Paso 2: Pulsamos en el botón Divergencia en Y. Ahora hacemos clic en el punto
debajo de la etapa 2 entre las etapas 3 y 4
Paso 3: Pulsamos en el botón línea. A la hora de hacer las líneas de transición, la
línea divergente se comporta como una etapa. Hacemos clic en la etapa
2 y luego en la línea divergente. A continuación hacemos lo mismo con
el resto de las etapas.
Paso 4: Haciendo doble clic en la transición podemos definir las condiciones de
paso. Cuando éstas se cumplan y la etapa 2 esté activada, se activarán
las etapas 3 y 4.
A.1.3.3 Convergencia en Y
Paso 1: Creamos dos etapas origen y una etapa destino. Pulsamos en el botón
etapa, y tres veces en la pantalla de panel de dibujo
Paso 2: Pulsamos en el botón Convergencia en Y. Ahora hacemos clic en el
punto encima de la etapa 5 entre las etapas 3 y 4
163
Apéndice A
Paso 3: Pulsamos en el botón línea. A la hora de hacer las líneas de transición, la
línea convergente se comporta como una etapa. Hacemos clic en la
etapa 3 y luego en la línea convergente. A continuación hacemos lo
mismo con el resto de las etapas.
Paso 4: Haciendo doble clic en la transición podemos poder las condiciones de
paso. Cuando éstas se cumplan y las etapas 3 y 4 estén activadas, se
activará la etapa 5.
A.1.3.4 Crear una Acción
Si queremos crear una etapa realice una acción o acciones seguiremos los
siguientes pasos.
Paso 1: Partimos de una etapa
Paso 2: Pulsamos con el botón derecho encima de la etapa
Paso 3: Seleccionamos la opción acciones y nos aparecerá el panel de la
Figura A- 6.
164
Apéndice A
Figura A- 6: Vista de pantalla de edición de acciones
Paso 4: Seleccionamos la acción o acciones que queremos realizar. Para añadir
una línea, seleccionamos el modificador, luego indicamos la dirección de
memoria o el símbolo y pulsamos añadir. Si lo que queremos es que en
una etapa se active una variable utilizamos el símbolo =. El Editor,
internamente se encarga de asignar los Resets y Sets correspondientes,
de modo que sólo cuando indiquemos una acción = en una etapa, se
active el símbolo asociado. De este modo, nos aseguramos que no falta
ningún Reset que deje una variable activada y fuera de control.
165