Mostrando entradas con la etiqueta CJ2. Mostrar todas las entradas
Mostrando entradas con la etiqueta CJ2. Mostrar todas las entradas

martes, 15 de enero de 2013

Configurar la dirección IP en automátas Omron

Al trabajar con los modelos de autómatas Omron cuyas CPUs utilizan Ethernet como puerto de programación, lo primero que hay que hacer es establecer la configuración de red necesaria para nuestro entorno. Al crear el programa nuevo desde el entorno de CX-Programmer y añadir nuestro PLC, este se añade con la dirección por defecto con la que viene de casa, en el caso nuestro ejemplo se trata de un PLC CJ2M con CPU 32 (la versión 3x son las que incorporan Ethernet en la CPU) y su dirección por defecto es 192.168.250.1.  Una vez configurado el PLC con una dirección de red de esta subred (por ejemplo 192.168.250.10, es posible conectar con el dispositivo.

Una vez establecida la conexión, se puede modificar la dirección de red haciendo doble clic en el ítem “Configurar tabla de E/S y unidad” dentro del árbol de elementos de la izquierda. Una vez hecho esto, aparecerá la tabla de entradas/salidas del PLC donde se puede ver las diferentes tarjetas del sistema. La primera de ellas (Puerto integrado/Tarjeta interna) es la que nos interesa, ya que se refiere a la tarjeta del puerto Ehternet ya integrada en la CPU. Al desplegar el ítem aparecen dos nuevos y uno de ellos es el que se refiere a la configuración de la unidad Ethernet. Pulsando doble clic nuevamente en este último, es posible realizar la configuración de diferentes detalles del puerto como la dirección IP o la conexión FTP.


La ventana de configuración del puerto Ethernet, consta de múltiples pestañas. La primera de ellas nos permite modificar la dirección IP del  dispositivo. Para ello hay que seguir los siguientes pasos:

  1. Establecer el PLC en modo programación.
  2. Pulsar doble clic en el ítem Configurar tabla de E/S y unidad en el árbol de elementos de la izquierda.
  3. Dentro de la Tabla de E/S hacer doble clic en el ítem que representa la configuración del puerto Ethernet (dirección 1500 para los autómatas de  la serie CJ)
  4. Establecer la nueva dirección, mascara de red y puerta de enlace.
  5. Pulsar en el botón Transf. [de PC a unid.]
  6. Una vez realizada la transferencia pedirá reiniciar el PLC (si no se reinicia, el PLC no cargará la nueva configuración).


Una vez seguidos estos pasos, la dirección del PLC se habrá modificado, y aparecerá el siguiente mensaje en la parte inferior del CX-Programmer:


Este problema es normal ya que la nueva dirección del dispositivo ya no es la dirección con la que habíamos conectado. Para conectar nuevamente, hay que desconectar del dispositivo, modificar la dirección a la que se desea conectar y conectar nuevamente. Para ello hay que pulsar botón derecho en el ítem del PLC, y seleccionar la opción Cambiar…


Hecho esto, aparecerá el cuadro de configuración del PLC y en este cuadro hay que pulsar en Configuraciones… dentro del recuadro Tipo de red y modificar la dirección IP que había por defecto en el dispositivo por la nueva dirección IP que se envió en la configuración.


Por último, se debe observar que el PLC se encuentra en estado de error, para solucionar esto, hay que modificar los dos switch rotatorio inferiores que incorpora el PLC y que deben coincidir con el valor hexadecimal del último byte de la dirección IP. Por ejemplo, la nueva dirección IP de nuestro dispositivo es 192.168.1.90, por lo tanto hay que pasar el valor 90 a hexadecimal que será 5A esto aparece como mensaje en la CPU del autómata. En los switch rotatorios hay uno con el texto 10x16^2 (10 por 16 elevado a 2) donde habrá que seleccionar el valor del dígito de mayor peso (en el caso de ejemplo será el valor 5) y el otro tiene el texto 10x16^1 donde habrá que seleccionar el valor de menor peso (en el caso del ejemplo A). Una vez hecho esto, se reinicia el PLC y listo, ya es posible seguir trabajando utilizando la nueva dirección IP del dispositivo.





miércoles, 28 de noviembre de 2012

GUÍA ESTÁNDAR DE PROGRAMACIÓN DE AUTOMATISMOS NO SECUENCIALES APLICADA A AUTOMATAS OMRON EN LENGUAJE LADDER (GEPNAS)


Cómo último ejemplo de programación de diagramas de estados con autómatas Omron, en este articulo se presenta una guía sencilla para implementar sistemas no secuenciales. Es importante tener en cuenta que siempre que sea posible es recomendable aproximar el problema a una solución secuencial, y sólo en el caso de que esto no sea posible hay que recurrir a diagramas de estados no secuenciales. Por simplicidad se emplea el mismo ejemplo que en el caso secuencial, aunque como ya se ha explicado un problema secuencial habría que resolverlo con la guía GEPAS.

En este caso, el esquema de contactos se divide en tres zonas, la zona de Trigger y condiciones de sensorización, establecimiento de estados y salidas o acciones de estado. 

El primero de estos, al igual que en la guía GEPAS se tiene que dado un estado se espera una determinada combinación de señales (condición de transición) para que el sistema pase a un nuevo estado. Para realizar esto, se utiliza una variable de memoria DX para almacenar el valor del estado que se modifica con la función MOV en los casos que sea necesario.


Para el caso del establecimiento de estado, lo único que se debe realizar es establecer el estado a través de un bloque de comparación que activa el flag correspondiente a dicho estado como se muestra a continuación:


Lo expuesto en el caso de establecimiento de estado permite poder utilizar la condición de estar en un determinado estado en cualquier momento del programa, mientras que si cada vez que fuese necesario utilizar esto como condición se utilizase el comparador se consumiría más memoria que con esta opción.

Por último, el bloque de salidas es el mismo que se daba en la guía GEPAG.


Cualquier duda, será contestada a través de los comentarios así queda para futuras consultas y otras personas podrán beneficiarse de la aportación.

martes, 27 de noviembre de 2012

GUÍA ESTÁNDAR DE PROGRAMACIÓN DE AUTOMATISMOS SECUENCIALES APLICADA A AUTOMATAS OMRON EN LENGUAJE LADDER (GEPAS)

En la anterior entrada de esta serie, se propone como plantear la solución general a un problema dado utilizando los recursos que CX-Programer proporciona para los autómatas incluso de la gama más baja. En esta ocasión se va a abordar como solucionar el caso de la programación de los subestados derivados del caso anterior. Al abordar el problema que se plantea en uno de estos subestados, pueden darse dos casos, el primero es que dicho subestado sea una maquina secuencial o que no lo sea. En este articulo se pretende mostrar una de las formas más eficaces de programar un sistema secuencial, que además es aplicable a la mayoría de los autómatas del mercado ya que no emplea ninguna característica propia de Omron ni de ningún otro sistema.

En principio como siempre lo ideal es plantear el problema como un diagrama de estados secuencial con los diferentes pasos desarrollados:

E1-->E2-->E3-->E1

A partir de aquí hay que definir 5 zonas en nuestro programa, las condiciones de sensorización, el reset de control, el contador, el establecimiento del estado y las salidas.

Las condiciones de sensorización tienen la finalidad de lanzar un trigger que es utilizado como señal para cambiar de estado, esto se consigue a través del contador que utiliza esta señal para realizar una cuenta. Para evitar que esté contando permanentemente, el trigger se desactiva a sí mismo de manera que sólo se produce un pulso de un ciclo, (también podría emplearse una operación DIFU).

El reset de control es el encargado de activar la señal de RESET en caso que no estar en ninguno de los estados definidos en el sistema.



La zona del contador contiene el contador y las señales de cuenta y de RESET que realizan las acciones comentadas anteriormente.


El establecimiento del estado realiza una comparación con el número de contador y establece la marca del estado correspondiente a la cuenta actual (esta marca es la empleada en los casos anteriores como indicador que de se está en un determinado estado y también se utiliza en el control).



Por último la sección de control, básicamente contiene el código correspondiente a cada estado, en base a si está activa o no la marca correspondiente a dicho estado. Esto debería contener las señales a activar en cada estado o en un sistema muy sencillo podrían ser las salidas aunque no se recomienda activar las salidas directamente, es mejor tener una sección donde se gestionen las salidas y emplear alguna señal intermedia para activar la salida a través de un contacto.


Evidentemente este método habrá que adaptarlo a la solución concreta. Siguiendo esta guía en la implementación de diagramas de secuencia para resolver los problemas de automatización secuenciales dejará clara sus ventajas frente a otros métodos, a pesar de que no es el más eficiente a nivel de memoria utilizada, es fácilmente extensible, trazable y muy claro.

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: