jueves, 24 de enero de 2013

Ya tenemos Raspberry Pi en GoShield!!!

Por fin ha llegado el día que llevamos esperando mucho tiempo..., el día en que puedo deciros que ya podéis comprar vuestra Raspberry Pi en GoShield!. El modelo distribuido es el modelo B de 512 megas de RAM y su precio es de 39,9€ PVP (iva incluido) y se puede obtener desde 5,01€ de gastos de envío. En breve publicaremos en el blog como construir tu propia recreativa y como montar un servidor multimedia usando como sistema operativo xbian. Así tendrás un media center con muchísimas posibilidades  y si sabes un poco de Linux no tendrás limites.



En breve traeremos nuevas novedades al respecto.

miércoles, 23 de enero de 2013

Nuevo Curso MOC de Electrónica y Fisica del MIT

Hoy os traigo una noticia que me ha llegado de los organizadores de un curso Masivo Online del MIT. El nuevo curso MOC de electricidad y magnetismo impartido por profesores del MIT. El curso es gratuito y tiene profesores de una altísimo calidad. Además, si finalizas el curso obtendrás un certificado del MITx. Uno de los profesores que lo imparte es Walter Lewin, famoso por sus peculiares clases, puedes ver el vídeo adjunto para hacerte una idea, no os lo perdáis no tiene desperdicio, es un genio.



Para quien esté interesado, puede darse de alta en este enlace.

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.





domingo, 13 de enero de 2013

Arduino Shield List: Lista de placas para Arduino

Arduino se ha convertido en una de las plataformas más populares para el desarrollo de electrónica en el hogar a nivel aficionado. Muchas universidades han incluido esta placa de hardware y software libre en sus clases prácticas, por la facilidad de programación que ofrece su entorno, donde es posible programar directamente en C ó C++ y cargar los programas a través del USB.

Pero esto no es todo, hay infinidad de posibilidades para la creación de nuevas ideas a partir de una placa Arduino. Una de las formas más fáciles de añadir nuevas funcionalidades a la placa Arduino es a través de las Shields de Arduino. Pero, ¿que es un shield?. Pues un shield no es más que una placa electrónica que puede ser conectada en la parte superior de Arduino y que normalmente permite a su vez conectar más placas encima de ella y que incorpora una determinada funcionalidad.

Jonathan Oxer ha creado y mantiene desde hace tiempo Arduino Shield List una interesante página sobre este tema. Su cometido, creo entender, que consiste en recopilar toda la información de utilización de los pines originales de Arduino de cada placa, a modo de poder determinar fácilmente que shields son compatibles con que otros.

Diferentes Arduino Shields Apiladas


Entre otras muchas cosas, muestro a continuación algunas de las funcionalidades más populares de los Shields de Arduino que pueden encontrarse por ahí:


  • Módulo de Relés: Un relé permite controlar con una salida de Arduino, la activación de dispositivos que tengan altos consumos de corriente. Cada salida de Arduino no puede emitir más de 20mA por lo que ciertos elementos como por ejemplo motores u otros elementos actuados con bobinas, no pueden ser activados directamente desde una salda de Arduino. En estos casos es util utilizar un modulo de Relés para poder activar dichos elementos. A continuación podéis ver un vídeo donde se utiliza un Módulo de relés para encender una bombilla, aquí tened cuidado ya que hay relés de características diferentes, por lo que esto no se debe hacer con cualquier tipo de relé, comprobad antes que el relé es capaz de conducir la intensidad correspondiente.

  • Módulo Ethernet: Con estos módulos es posible conectar Arduino a nuestra red local de cada. De manera que podemos hacer que acceda a cualquier información o bien que actúe como un pequeño servidor Web o de directorios, aunque su uso más útil es poder conectar a Arduino un dispositivo actuador o sensor, y acceder a su control o monitorización a través de la red local de casa. En este otro vídeo se muestra como controlar un módulo de relés a través de un PC utilizando para ello un módulo Ethernet para publicar el servicio.

  • Expansores de I/O: En muchas ocasiones, nos encontramos con determinados tipos de aplicación, donde podemos encontrar que Arduino no tiene suficientes entradas o salidas para controlar todos los elementos necesarios. En estos casos, se puede recurrir a Shields específicos para aumentar la cantidad de entradas salidas de nuestro Arduino. Generalmente estos Shields utilizan un bus de comunicaciones I2C o SPI para controlar desde el Arduino las nuevas I/O por lo que hay que fijarse en que bus utiliza el shield en concreto ya que según cual sea dejará sin poder utilizar unas determinadas entradas de Arduino. En el vídeo incluido a continuación, se muestra como con uno de estos expansores de entradas, es posible utilizar hasta 8 entradas como entradas de interrupción. Esto se consigue ya que cada puerto del expansor (8 entradas/salidas) tiene asociada una patilla de generación de interrupción (de manera que si hay un cambio en cualquier entrada del puerto se genera una señal de interrupción). Por lo tanto, es tan sencillo, como conectar esta salida de interrupción a una entrada de interrupción de Arduino y cuando se produzca una señal leer el puerto completo para detectar cual ha sido la que cambió. Trabajar de esta forma, con interrupciones  evita tener que chequear el puerto en cada ciclo de programa.


domingo, 6 de enero de 2013

Herramienta Multiway Omron - Debug Comunicaciones

En primer lugar desearos a todos un feliz año 2013 y como regalo de reyes os traigo una herramienta que a a aquellos que les gusten los trabajos con comunicaciones seguro que les va a ser muy interesante.

Cuando se desarrolla una aplicación que requiere del uso de comunicaciones entre diferentes equipos, ya sea modbus, hostlink, OPC o similares. Siempre es recomendable hacer pruebas en simulación para comprobar el funcionamiento independiente de los diferentes elementos. Esto es especialmente recomendable cuando se van a emplear una gran cantidad de equipos en la comunicación, ya que si se intenta hacer funcionar todo el sistema al mismo tiempo, se corre el riesgo de que alguno de los elementos provoque un error, y el coste de detectar que equipo ha provocado el error aumenta de forma exponencial según el número de equipos conectados.

Por este motivo, es muy interesante conocer Multiway, una potente herramienta gratuita por cortesía de Omron para realizar pruebas de comunicaciones, que permite entre otras cosas:
  • Envío y recepción de tramas SYSMAWAY
  • Protocolo FINS y HostLink
  • Modbus como Maestro y también puede funcionar como esclavo
  • Como terminal avanzado de telnet
  • Compoway
  • Sniffer
  • Cliente OPC
Es una herramienta muy recomendable para casi cualquier trabajo que uno necesite realizar con comunicaciones industriales tipo serie.

martes, 4 de diciembre de 2012

Algunos detalles de implementación con Omron

Relacionado con las clases en Sistemas de Control Automático de el Máster en Automática y Robótica, la práctica consiste en realizar la programación de un grupo de presión de cuatro bombas. A raíz de esto se han comentado algunas estructuras de programación en clase para gestionar ciertas cosas. A continuación expongo unos ejemplos de como gestionar estas estructuras.

Registro de desplazamiento, con este registro se apunta a la bomba a encender, con otro igual a la siguiente bomba a apagar y por último habrá otro para gestionar la bomba que deberá arrancar por variador en el siguiente ciclo de trabajo.


Respecto a la gestión de tareas, muchos tienen aún dudas de como funcionan estas estructuras. Los bloques TKOF y TKON lo que hacen es activar y desactivar unos registros especiales (marcas) llamadas TK00, TK01 y así sucesivamente. Cada una de ellas está asociada al estado de un "programa" y cuando digo programa me refiero a lo que en CX-Programmer se considera programa (ver árbol de proyecto a la izquierda de CX-Programmer). De manera que estas mismas marcas pueden ser empleadas para activar una determinada sección de código como en el ejemplo que se muestra a continuación:


En este ejemplo, la marca TK01 (es decir cuando el programa con tarea de prioridad 1 está en ejecución), se activa una sección de código donde se detiene el programa con tarea de prioridad 0 y se ejecuta el programa con tarea de prioridad 3.

Sobre la gestión de arranques y paradas de bombas, mi consejo es emplear un biestable RS utilizando la función KEEP. Como se muestra en en la figura, la linea de la primera conexión del biestable contiene la condidicón de arranque de un contactor de la bomba 1, y la segunda linea contiene la condición de parada del mismo contactor. (No es necesario tener las mismas condiciones, sólo son a nivel ilustrativo, no deben tomarse al pie de la letra).




lunes, 3 de diciembre de 2012

Comunicaciones Modbus RTU con Automatas OMRON CP1L

En este articulo, se pretende dar una guía de como montar un sistema de gestión de comunicaciones con autómatas CP1L, que permita gestionar el envío y recepción de información a través de protocolo modbus RTU, de forma sencilla y estandarizada. Permite la gestión de las comunicaciones de una forma centralizada y extensible, por lo que sin mucha complicación es posible extender el uso para nuevos tipos de tramas. En este enlace se puede encontrar un documento sobre como realizar las comunicaciones modbus RTU de forma sencilla con un autómata CP1L. Este documento es un extracto de la guía completa de dicho autómata. Aquí veremos los conceptos más importantes y como aplicarlos a un caso particular.

En primer lugar comenzaremos viendo como configurar el puerto de comunicaciones del autómata. Si se realiza un doble click en el menú de la izquierda sobre el ítem del árbol de proyecto "Configuración" aparecerá el cuadro de dialogo de configuraciones generales del autómata. Una vez ahí, se elige la pestaña "Configuración de entrada Puerto Serie 1" ó "Configuración de entrada Puerto Serie 2" según corresponda y se selecciona la opción Configuración Personalizada. Una vez ahí, hay que configura la velocidad del puerto, y el formato de trama (el más común es 8,1,N - 8 bits, 1 de parada y sin control de flujo). En la casilla Modo, hay que seleccionar el sistema que interese, en el caso que nos atañe seleccionaremos Puerta de enlace serie.


Una vez configurado el puerto de configuraciones hay que cargarla al autómata, seleccionando que envíe la configuración (hay que activar la casilla correspondiente en el dialogo de carga de programa). Y a continuación es preciso reiniciar el autómata para que cargue la nueva configuración. 

Una vez configurado, se puede comenzar a comunicar, pero primero veamos los detalles básicos a tener en cuenta. La configuración de la trama modbus, se almacena en direcciones de memoria DM (que dependen del puerto y de la CPU utilizada). Los autómatas CP1L-M incorporan dos puertos de comunicaciones, y la trama se almacena entre la dirección D32200 y 32249 para el puerto 1 y entre la D32300 y 32349 para el puerto 2. Sin embargo para la CPU CP1L-L sólo hay un puerto de comunicaciones y se emplean los últimos (D32300 y 32349), cuidado con esto último.

De igual modo, la respuesta recibida se almacena en las direcciones entre D32250 y 32299 para el puerto 1 y entre la D32350 y 32399 para el puerto 2 en las CPUs CP1L-M. Y entre las D32350 y D32399 en las versiones CP1L-L de la CPU.

En las siguientes figuras se muestra el formato que debe tener la trama para poder ser enviada y para poder procesar adecuadamente la respuesta recibida. En primer lugar se puede ver que utilizando como dirección base 32300 ó 32200 según corresponda, se tiene que en la primera palabra base+0 se debe escribir la dirección de esclavo modbus al que se desea mandar el comando. Para ello se escribirá en la parte baja de la palabra y no en la parte alta  (que queda reservada para trabajos del sistema). De igual modo ocurre en la segunda palabra con dirección base+1, en la que se escribe la función de modbus a emplear. Esto no coincide con la definición estandar de modbus. Según el protocolo modbus, estos dos datos estarían incluidos en los primeros 16 bits enviados, a modo de cabecera, por lo que no hay que confundir una cosa con la otra. A continuación se escribe en base+2 el número de bytes a enviar a partir de esta palabra, es decir si el comando completo tiene una longitud de 6 bytes en total (1 dirección de esclavo, 1 byte del código de función y 4 del resto del comando), habrá que escribir un 4 en esta dirección. A continuación de aquí, se debe escribir normalmente el resto del comando, utilizando adecuadamente la parte alta y baja de los registros.

Veamos un ejemplo practico:

Si hay que enviar un comando Run a un variador de frecuencia MX2 que actúe como esclavo con dirección 1, el comando a enviar sería 01-05-00-00-FF-00  (para conocer mas detalles sobre este mensaje puedes consultar aquí la referencia de aplicación del protocolo modbus en modbus.org). Los dos primeros bytes correspondería como se ha dicho con la dirección de esclavo modbus y código de función, mientras que los cuatro siguientes son la dirección de memoria donde se desea escribir y el valor (FF00 en bobinas ó Coils representa que se desea escribir un 1). También como curiosidad, si se observa el Apendice B (página 279) manual del variador MX2 referenciado antes, se puede observar que la dirección de memoria para el comando Run indicada en el manual es 0001 y en el comando se escribe la 0000, esto se debe a que en Modbus para direccionar la posición N de memoria hay que escribir la N-1. Por tanto habría que escribir un 0000 en la dirección base+3 y un FF00 en la dirección base+4.
.

El formato de las respuestas es el mismo desplazado a las direcciones comentadas antes. En la parte baja del registro con dirección base+50 se tiene la dirección del esclavo que ha respondido y en la parte baja de la dirección base+51 se tiene el código de función del comando al que se está respondiendo. En la dirección base+52 el código de error (si es el caso) y en la posición base+53 se tiene el número de bytes recibidos, los cuales se encontrarán en las direcciones siguientes.


Una vez que se tiene configurada la función a enviar, si se desea enviar el comando a través del puerto serie, se utiliza la palabra de función A640  para las CPUs CP1L-L en el puerto 1 ó bien para las CPUs CP1L-M en el puerto 2. Lo mismo que se explica a continuación, se realiza con la palabra A641 para el puerto 1 en las CPUs CP1L-M. En nusetro caso utilizamos una CPU CP1L tipo L, por lo que para enviar se activa la bobina A640.0 y cuando se reciba una respuesta correcta la bobina A640.1 se activará automáticamente. Si por el contrariop se recibe una respuesta errónea o si se produce un problema de comunicación se activará la bobina A640.2. Para gestionar esto se propone crear un programa (tarea con una prioridad 1,2 ó 3) en el que se creará una sección llamada comunicaciones_common y que contendrá la gestión común de las comunicaciones. Esta sección contendrá el siguiente código:


Comenzaremos explicando este código desde el centro, ya que todo el código se sustenta en la variable com_EnviandoTrama. Se trata de una variable con enclavamiento, que se activa con la señal set_EnviandoTrama y se desactiva con reset_EnviandoTrama. Esta señal es la que activa el bit A640.0 que indica el inicio de la comunicación. Además se emplean dos temporizadores para gestionar el envío automático de una trama en caso de error del envío.  La parte interesante de este sistema es que se centraliza la comunicación en variables independientes que habrá que ir añadiendo a las dos últimos diagramas, en la activación de set_EnviandoTrama, se añade el flanco de subida de las variables de comunicación según la trama que se desea enviar y en la de reset se añade el flanco de bajada de la misma variable. Es decir, cada vez que se desea añadir un nuevo comando a utilizar, se crea una variable asociada que gestione dicho comando (en el ejemplo com_LeerConsigna) que en su flanco de subida activa set_EnviandoTrama y en su flanco de bajada activa reset_EnviandoTrama.

Después se crea una sección común llamada, por ejemplo, comun_escribirDireccion. En ella se debe realizar la escritura en las direcciones base+(lo que toque) de aquellas cosas comunes en todos los comandos configurados. Esto no es obligatorio pero permite ahorrar algo de memoria. En este caso todos los comandos configurados se dirigen al esclavo 4 y tienen una longitud de 6 bytes (4 excluyendo la dirección de esclavo y la función de modbus) por lo que se añade el código correspondiente en esa sección:


A continuación se aconseja utilizar una sección nueva por cada comando donde se configurará la trama de envio. En nuestro caso _COM_LecturaConsigna. Esta escritura requerirá que se encuentren activas la señal com_EnviandoTrama y la variable de control de comunicaciones del comando correspondiente, tal como se puede ver a continuación:

Como se ve en el caso anterior, aquí se configura el resto del comando a enviar. En la parte final de esta sección, se tiene un control de set y reset de dicha variable, de forma que no se actúa nunca directamente sobre la variable sino a través de señales de ser y reset. De forma que si se requiere activar dicho comando desde diferentes sitios del código se puede añadir señales de set y reset según sea necesario, evitando así escribir varias veces sobre la misma variable.

Para el tratamiento de la respuesta hay que extraer los datos de las direcciones comentadas anteriormente (esto será común en muchos casos) y por último se moverá el resultado de la extracción a una dirección (configurada adecuadamente). Esto último como puede verse si que depende directamente de que sea un comando u otro el que se esté configurando, por este motivo se añade la nueva condición a dicha acción, en concreto en este caso se realiza una división del valor (adecuación del mismo a la escala deseada) y un movimiento final a la variable donde lo podremos consultar cuando lo deseemos a partir de este momento (a modo de variable temporal en un registro DM). Por último se puede observar que se utiliza una señal com_Realizada para indicar que la comunicación ha terminado (y se ha extraído la información de la respuesta recibida). Esta señal se activa con la señal set_EnviandoTrama de manera que se activa en el instante en que se va a iniciar una comunicación.

Por último, el uso de este sistema para la realización de una comunicación se puede resumir en tres estados. Un primer estado que activa la señal de envío a través de set_LeerConsigna. Un segundo estado que espera a que la comunicación se realice satisfactoriamente (tiene como condición un flanco de subida de la señal com_Realizada) y por último un estado que realiza el reset de la variable activando la señal reset_LeerConsigna. Este último habrá de esperar a que se desactive la variable com_EnviandoTrama para activar un flag que permite salir de dicho estado. Dichas condiciones y activaciones se deben realizar en las secciones correspondientes según la metodología que se esté empleando. La programación si se emplean las guías recomendadas es muy sencilla aplicando este sistema a cualquiera de ellas. Aquí un extracto de como quedaría el uso comentado:


Como ventajas de este mecanismo, es que permite ampliar fácilmente el uso de nuevos comandos modbus, permite el uso de estos desde diferentes puntos del código de forma sencilla y eficiente a nivel de espacio. Además su diseño modular permite su uso a través de infinidad de modos de programación aunque se recomienda su uso junto a las guías generales de programación de autómatas OMRON publicadas en este blog.