Cuando realizamos un proyecto de automatización, lo ideal
siempre es realizar un análisis previo en el que se debería incluir un diagrama
de estados del funcionamiento del sistema. Si el sistema es muy sencillo quizá
con solo un diagrama sea suficiente para plasmar todo los estados. En cambio,
si el sistema no es suficientemente sencillo lo aconsejable es dividir el problema
en subproblemas más pequeños de manera que se aíslen unas partes del problema
de otras. Esto además de facilitar la trazabilidad del código y reducir enormemente
los errores que se cometerán en la programación, también evitará generar
diagramas de estados demasiado grandes y que muchas veces en lugar de permitir
manejar mejor el problema (como es su finalidad) acaban consiguiendo todo lo
contrario. De esta forma lo que se obtendría es un autómata general más grande que
corresponde al diagrama de estados principal y en cada uno de los estados de este
diagrama se tendrá un nuevo pequeño automatismo para gestionar cada uno de
estos estados.
A continuación se va a mostrar un ejemplo de esto en el caso
de autómatas Omron y utilizando lenguaje Ladder, ya que por ejemplo en el caso
de autómatas de bajo coste como es la familia CP1 es el único lenguaje que en
el que se puede desarrollar. El ejemplo empleado corresponde al de una práctica
de la asignatura Sistemas de Control Automático del Máster en Automática y Robótica
de la Universidad de Alicante. En este caso tenemos que controlar la gestión de
4 bombas que dan suministro para conseguir una presión estable en la impulsión.
Dejando a un lado las particularidades del sistema, el funcionamiento se puede
dividir en los siguientes tres estados según la guía Gemma que a su vez pueden
ser tratar como cuatro estados en los que no entraremos en detalles:
Cuando se desarrolla software, lo mismo se puede programar de infinitas
formas y se tiende a pensar que cualquiera de ellas es igual de buena si
realiza su función. Para empezar la eficiencia de los diferentes programas
tanto espacial como temporal no es la misma, pero dejando al margen este
detalle que puede no ser decisivo existe un motivo más importante para hacer
las cosas correctamente. Un código debe ser mantenible, fácilmente trazable, orientado
a la extensión y no al cambio y lo más estándar que sea posible, es decir hay que
establecer una metodología para la creación de código. El objetivo es que la
parte de ingeniería resida en el análisis del problema y en el diseño de la
solución en papel (a través de un diagrama de estados grafcet o similar) pero no
en el código que se escribe. Para conseguir esto, se debe utilizar una guía de
implementación, que dado un análisis del problema siempre termine generando el
mismo código sea quien sea el programador, por lo menos en lo esencial. Este
tutorial pretende ser una pequeña guía introductoria de cómo hacer esto en autómatas
Omron, para una pequeña parte de los programas. En futuras guías, se mostrará
como explotar estos estados y realizar pequeñas máquinas de estados secuenciales
para cada caso aplicando nuevos métodos.
Para implementar esto con autómatas Omron, hay muchas formas pero sin
duda alguna la forma más eficiente es desactivar completamente la ejecución de
los estados que no se estén utilizando. Esto permite ahorrar tiempo y evita que
posibles casos no contemplados en estos estados (cuando no deberían estar
siendo ejecutados) afecten al correcto comportamiento del sistema. Para conseguir
esto hay que dividir la solución en programas diferentes, en la parte izquierda
del entorno de CX-Programer se puede ver que en la última opción (programas) permite
crear diferentes bloques de código a los que CX-Programer llama programas. Al
añadir un nuevo programa se obtienen una pantalla donde se muestran las
opciones de Nombre, Tipo de tarea y una opción de chequeo
llamada Inicio de operación. El
nombre es tan solo un identificador, y el tipo de tarea debería estar ordenado
según el orden de ejecución que queramos, por ejemplo, en el caso expuesto tendríamos
5 programas. Un primer programa que gestionará el cambio de estados entre programas.
Y cuatro programas más, uno por cada estado de la máquina de estados. Por tanto
el orden de tareas que yo recomendarías sería el programa que gestiona el
cambio de estados como el de mayor prioridad (por ejemplo tarea 3) y el resto
consecutivamente según el orden en que entran en funcionamiento: PARO tarea 4,
MARCHA tarea 5, etc. Nótese que el estado
de mayor prioridad se le asigna la tarea 3, esto es porque previo a este
programa se han añadido otra serie de programas para realizar la gestión de
otras características como comunicaciones, inicialización de variables u otros
detalles comunes a todos los estados.
Para realizar el cambio entre estados lo que se debe hacer es detener
la ejecución de los programas que no correspondan al estado que está en el
instante actual en ejecución. Para ello hay que deshabilitar la casilla de chequeo
de las ventanas de propiedades de los programas correspondientes a las tareas
4, 5, 6 y 7 (PARO, REPOSO, SERVICIO y PARANDO). Esto se hace así, porque así los
programas permanecerán detenidos a no ser que sean activados de forma explícita
utilizando la función TKON, de lo contrario en cada estado habría que apagar
todos los que no estuviesen activos ya que por defecto estarían en ejecución.
De esta manera, el código de cambio de estados se puede expresar de
forma muy simple como una variable entera que almacena el estado entre 0 y 3 y
que según el estado si se cumple la señal de transición cambia el valor de la
variable por el valor del estado siguiente como se muestra a continuación:
Existe un mecanismo óptimo para
los sistemas secuenciales puros que se verá en nuevas guías. Sin embargo para
sistemas que contienen transiciones cruzadas entre estados, este es el
mecanismo que yo recomiendo.
Como se comentaba anteriormente, utilizando la función TKON es posible habilitar
el código (programa) correspondiente al estado en que se encuentra el sistema como
se muestra en la imagen. En caso de no haber desactivado la casilla
Inicio de operación en los programas
que contienen el código de los estados, todos estarían inactivos y habría que
desactivar todos aquellos no correspondientes al estado activo utilizando la
función TKOF. Esta solución es menos intuitiva y más complicada de gestionar,
porque en la mayoría de casos habría que detenerlos en más de un lugar del
código lo que complicaría la gestión del sistema y aumentaría la probabilidad
de cometer un error. Lo que se propone en esta práctica es que cuando se produce una transición se active el nuevo estado y se desactive el estado o estados de los que se pueda proceder, este no es el único modo de hacer esto, ya que según el caso podría haber formas más optimas de hacer lo mismo.
Es importante tener en cuenta que TKOF congela el programa en el estado exacto en que se quedó, esto quiere decir que sus salidas quedan activas y su estado al salir es el último estado que se ejecutó. Por lo tanto es conveniente, reiniciar el estado en la sección de control de la máquina anterior, como se muestra en la figura. Es decir, si se va a un nuevo estado cuyo subestado depende de una variable que almacena el estado es conveniente reiniciar el valor de esta variable (iniciarlo a cero) para que el subestado se ejecute correctamente.
Un detalle a tener en cuenta es utilizar como memoria para almacenar el estado (variable Estado) una palabra del área DM ya que esta memoria está reservada para datos y es posible escribirla desde diferentes partes del código sin que el programa se queje. En caso de emplear una dirección de memoria normal, se obtendría una advertencia diciendo que la escritura de las bobinas está duplicada.
Este sistema es fácilmente extensible a diagramas generales de muchos
más estados y permite la aplicación GEMMA de una forma cómoda y sencilla. En
este ejemplo como sólo se pretende implementar tres estados GEMMA (diagrama MARCHA/PARO)
se ha incluido en el ejemplo el desglose de dos subestados del estado F1. Esto
no deja de ser una particularidad del problema concreto, pero suele ser una
buena costumbre dividir F1 en entre 2 y 5 macroestados según la complejidad del
problema y gestionar este nivel de F1 con este mismo método, de esta manera se
simplificará la definición de los subestados del problema principal (F1).
Referencias:
