Posibilidades de funcionamiento del Driver SLVDN

Recientemente hemos realizado una aplicación con un driver SLVDN de Parker, aprovechando su PLC interno. Un alimentador de horno cerámico. Sin necesidad de PLC el driver realizaba el control del alimentador. El driver dispone de E/S digitales y analógicas suficientes para esta automatización. Aprovechando este desarrollo citamos los modos de trabajo y programación del driver.

El funcionamiento del driver SLVDN puede ser de dos modos:

Como un driver dependiente de un controlador externo, en diversos modos de funcionamiento.

– Control en modo par, corriente y velocidad.

– Control en modo posicionador.

– Control en modo eje eléctrico.

– Control en modo leva electrónica

– Controlado mediante bus de campo.

O como un automatismo independiente. Activando y programando el PLC interno del driver. Para realizar la programación del driver existen dos posibilidades

utilizar el SW de parametrización MOTIONWIZ, limitado a cierto numero de líneas dependiendo del driver

utilizar el SW LOGICLAB que nos permite realizar un programa IEC61131. En este caso disponemos de mucha mas memoria y mas recursos.

 

En ambos casos los programas de control se basan en parametrizar y des/activar los modos de trabajo del driver.

En posteriores entradas mostraremos ejemplos de uno y otro tipos de programación.

Leer más

IP por defecto en controladores serie EC

En caso de que necesitemos establecer la IP por defecto en alguno de los controladores de la serie EC, normalmente por que necesitamos acceder a la pagina de configuración y no recordamos la IP establecida. El equipo dispone de un modo llamado «modo de mantenimiento» en el cual la IP del primer puerto ethernet del equipo pasa a ser la establecida de fabrica (169.254.255.xxx donde las xxx son los dos últimos números del numero serie del controlador).

Para que el equipo entre en este modo deberemos de alimentarlo mientras mantenemos el switch S1 pulsado, hasta que el led Run/Stop parpadea a intervalos de 2 segundos. Ya podemos acceder a modificar la IP del equipo mediante el interfase WebServer del controlador.

Leer más

Utilización de las E/S integradas en los EC22xx

En los links inferiores podréis ver un ejemplo de programa en el que se demuestra la utilización de las E/S Analógicas y Digitales integradas en los equipos de BergHof de las series EC22xx. Un simple ejemplo con un par de entradas de temperatura y un par de entradas analógicas de voltaje enlazadas con las salidas de voltaje. Fácil de montar para unas pruebas rápidas.

Si necesitáis equipos para realizar estas pruebas disponemos de algunos de ellos en Suelpla. Solo tenéis que poneros en contacto con nosotros.
Según la versión de controlador utilizado dispondremos de diferentes configuraciones. En el caso que nos ocupa hemos utilizado el controlador EC2250 que incorpora el máximo numero de E/S tanto analógicas como digitales.

En posteriores entradas del blog mostraremos la utilización de las E/S digitales rápidas y de las entradas de evento.

De momento podéis ir investigando y realizando pruebas con este ejemplo.

Documento descriptivo ▶ Gestion E_S

Proyecto ejemplo ▶ Acceso E_S_Integradas V03  Version: CoDeSys V3.5 SP4 Patch 3

Leer más

Targets familia EC2xxx de BergHof

En el fichero adjunto en el link inferior podéis encontrar los targets de la familia EC2xxx. Deberéis de instalarlo para poder utilizar los siguientes equipos:

EC2xxx Familia de PLCs compactos

ECC2100  4E/4S Digitales  2E Analogicas

ECC2200  16E/16S Digitales

ECC2250  16E/16S Digitales  6E Analogicas

ECC2251  16E/16S Digitales  12E/6S Analogicas

DC2400 Pantalla PLC de 4″   4E/4S Digitales  2E/S Analogicas

DC2700 Pantalla PLC de 7″   4E/4S Digitales  2E/S Analogicas

Para la instalación deberéis de descomprimir el fichero descargado y posteriormente instalarlo desde el menú Herramientas –> Repositorio de dispositivos… del entorno de CoDeSys.

Una vez instalado el target, en el listado de dispositivos aparecerá el BergHof MX6 Control, este dispositivo es el que deberemos de seleccionar para poder utilizar cualquiera de los dispositivos anteriormente mencionadas.

Fichero de target ▶ Target EC2xxx

Leer más

Cambiar dirección IP y otras configuraciones

Para realizar el primer acceso sobre un equipo nuevo, su dirección IP por defecto es 169.254.255.XX, donde XX corresponde a los dos últimos números del numero de serie del equipo. Excepciones:

si XX es 00 se convierte en 169.254.255.100

(al escribir la dirección IP no se utilizan los 0 a la izquierda, esto es si el numero de serie termina en 09 la dirección será 169.254.255.9. La dirección 169.254.255.09 es errónea y no comunicaremos)

La mascara de red es 255.255.255.0

Si nuestro equipo puede acceder a esta dirección de red, mediante un navegador web podremos acceder a configurar el controlador. Estableciendo la dirección IP del controlador en la url del navegador accederemos a la pagina de entrada del webserver. El usuario y contraseña por defecto son «admin» y «admin«.

Desde estas paginas podremos cambiar la configuración por defecto del controlador para que se adapte a nuestras necesidades.

Leer más

Actualización del FW en la gama XL4 y XL7

A continuación describimos el proceso para actualizar los procesadores de las gamas XL4 y XL7. La actualización de los firmwares de los controladores a las ultimas versiones añaden nuevas funcionalidades y eliminan posibles errores a los controladores.

Estos controladores se actualizan mediante un «Bootloader», utilizando una tarjeta microSD o un lapiz USB (no como en otros controladores que se puede realizar desde el mismo SW CScape).

El proceso a realizar es el siguiente:

  1.- Descargar el nuevo firmware desde la pagina web de Horner. Verificar si el controlador es con comunicación CsCan o CANOpen.

  En la pagina www.heapg.com hay que entrar en la sección LOG IN (es necesario disponer de una cuenta de acceso, en caso de no tenerla la deberemos de crear). Una vez hemos accedido iremos a la sección «Support–> Controller Firmware» y descargaremos la versión mas reciente, para el protocolo adecuado a nuestro controlador.

EL SIGUIENTE PROCESO BORRAR EL PROGRAMA DE APLICACION DEL CONTROLADOR. DEBEMOS DE ASEGURARNOS DE REALIZAR UNA COPIA DE SEGURIDAD ANTES DE LA ACTUALIZACION.

  2.- Grabar los dos del firmware sobre la tarjeta o lápiz.

  3.- Actualizar el firmware mediante la función de actualización del controlador.

            3.1.- Insertar la microSD o el lápiz USB, en un controlador en funcionamiento.

            3.2.- Pulsar y mantener la tecla SYSTEM hasta que aparezca el menú de actualización.

            3.3.- Pulsar el primer botón «Install Bootloader» y confirmar.

            3.4.- Cuando finalizar la operación aparece un mensaje de confirmación

            3.5.- Reiniciar el procesador y esperar el arranque

            3.6.- Pulsando la tecla SYSTEM y abriendo el menú View Status, bajamos hasta ver los números de versión y comprobamos que todo ha funcionado correctamente.

Leer más

Persistencia (Persistent)

Que es Persistencia y como se puede establecer en CODESYS?

Llamamos datos persistentes a los que mantienen sus valores incluso tras la descarga de una nueva aplicación o tras un reset frió (cold reset) del controlador.

CODESYS provee los siguientes tres mecanismos para conseguir la persistencia:

– Declaración de las variables VAR PERSISTENT en los POUs

– Declaración de las variables persistentes utilizando el Persistence Manager

Recetas

Hay otra posibilidad para mantener los datos de modo permanente: Utilizando las variables RETAIN. Estas al igual que las variables PERSISTENT mantienen sus valores tras un «Reset Caliente» (Warm Reset o fallo de alimentación), pero no al realizar una nueva transferencia de la aplicación, que únicamente pueden mantener su valor si son de tipo PERSISTENT. Realizando una declaración RETAIN + PERSISTENT las propiedades de remanencia se pueden combinar, aunque las variables declaradas con «VAR PERSISTENT» siempre se tratan como «VAR RETAIN PERSISTENT» o «VAR PERSISTENT RETAIN». De este modo obtenemos unos datos que únicamente se pueden reinicializar cuando el controlador se resetea a su estado de origen «Reset Origin».

En el siguiente fichero se muestra el proceso de declaracion de las variables Persistent ▶ Fichero de ampliacion

Leer más

Comunicación FINS con un PLC Omron®

Hemos implementado la comunicación entre un equipo EC2250 de BergHof y un CJM2-CPU31 utilizando el protocolo FINS. Nuestras necesidades son leer el contenido de una área de memoria del PLC.

Los servicios de comunicación FINS habilitan el acceso como cliente al PLC, para realizar operaciones de lectura y escritura de las áreas de memoria del PLC servidor sin necesidad de realizar ninguna programación especifica, en el. Las unidades Ethernet utilizan un puerto UDP/IP dedicado para los servicios de las comunicaciones FINS.

Los datos se envian y reciben como paquetes UDP sobre la red Ethernet. Y el puerto utilizado para la comunicación es el 9600, por defecto.

Existe una descripción detallada del protocolo FINS en la documentación del fabricante.

En este protocolo deberemos de enviar una trama de petición de datos al PLC servidor, en este caso el CJM2, y el nos contestara con los datos solicitados.

En el programa simplemente hemos abierto la comunicación con el PLC, utilizando la función «UDP_Peer«. Y posteriormente se habilita la función de recepción en modo continuo «UDP_Receive«, para cuando llegan tramas de datos decodificar el contenido. Y activamos la función de transferencia cuando queremos solicitar una lectura del área de memoria.

El ejemplo se ha programado de modo que tras recibir la contestación se ejecuta una nueva consulta. También se observa en el ejemplo que se ha implementado el protocolo FINS como un FB de modo que en el programa principal únicamente deberemos de personalizar la petición a nuestras necesidades.

Leer más

Comunicacion abierta Ethernet

Utilizando la librería «CAANet Base Services» podemos implementar comunicaciones UDP y TCP de modo fácil y sencillo. La secuencia a realizar en ambos casos es la siguiente:

  1. Abrir la comunicación. Para ello deberemos de conocer la dirección IP del equipo remoto y el puerto. Para la comunicación TCP utilizaremos la función TCP_Client y para la comunicación UDP la función UDP_Peer.
  2.  Activamos la recepción de los datos mediante las funciones TCP_Read para la comunicación TCP y UDP_Receive para la comunicación UDP. En el momento que lleguen los datos la función nos retornara un array con ellos y nos indicara la cantidad recibida.
  3. Podremos realiza la transferencia de datos mediante las funciones TCP_Write y UPD_Send. Realizara la transferencia de los datos contenidos en un buffer.

Las pruebas de la comunicación TCP se han realizado utilizando el programa TCPClientServer.

Comparativa entre UDP y TCP

UDP : proporciona un nivel de transporte no fiable de datagramas, ya que apenas añade la información necesaria para la comunicación extremo a extremo al paquete que envía al nivel inferior. Lo utilizan aplicaciones como NFS (Network File System) y RCP (comando para copiar ficheros entre ordenadores remotos), pero sobre todo se emplea en tareas de control y en la transmisión de audio y vídeo a través de una red. No introduce retardos para establecer una conexión, no mantiene estado de conexión alguno y no realiza seguimiento de estos parámetros. Así, un servidor dedicado a una aplicación particular puede soportar más clientes activos cuando la aplicación corre sobre UDP en lugar de sobre TCP.

TCP: es el protocolo que proporciona un transporte fiable de flujo de bits entre aplicaciones. Está pensado para poder enviar grandes cantidades de información de forma fiable, liberando al programador de la dificultad de gestionar la fiabilidad de la conexión (retransmisiones, pérdida de paquetes, orden en el que llegan los paquetes, duplicados de paquetes…) que gestiona el propio protocolo. Pero la complejidad de la gestión de la fiabilidad tiene un coste en eficiencia, ya que para llevar a cabo las gestiones anteriores se tiene que añadir bastante información a los paquetes que enviar. Debido a que los paquetes para enviar tienen un tamaño máximo, cuanta más información añada el protocolo para su gestión, menos información que proviene de la aplicación podrá contener ese paquete (el segmento TCP tiene una sobrecarga de 20 bytes en cada segmento, mientras que UDP solo añade 8 bytes). Por eso, cuando es más importante la velocidad que la fiabilidad, se utiliza UDP. En cambio, TCP asegura la recepción en destino de la información para transmitir.

Fuente Wikipedia. http://es.wikipedia.org/wiki/User_Datagram_Protocol

Leer más