domingo, 18 de noviembre de 2012

GUÍA ESTÁNDAR DE PROGRAMAÓN DE AUTOMATISMOS GENERAL APLICADA A AUTOMATAS OMRON EN LENGUAJE LADDER (GEPAG)


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:

Diagrama de estados que representa el funcionamiento del sistema General de la práctica


 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: