Enviar e-mail desde controlador

Podemos realizar el envió de e-mails desde los controladores de BergHof. Para ello necesitaremos una libreria de 3S (de pago, disponible en la tienda on-line) o la librería OSCAT Network (de uso libre).

Pero estas librerías únicamente pueden gestionar servidores de correo que no utilicen ningún tipo de encriptación, actualmente la mayoría de los servidores utilizan algún tipo de encriptación.

Siempre esta la opción de configurar un servidor de correo sin encriptación para gestionar estos e-mails.

Leer más

Comunicación con un GFXTermo4 (Gefran)

El GFXTermo4 de Gefran es un equipo controlador de temperatura de 4 bucles independientes. Que podemos conectar en una red de campo, en nuestro caso CanOpen con un controlador CoDeSys, para poder configurarlo y leer su estado. El equipo conectado a la red CanOpen puede controlar hasta 3 controladores esclavos mediante una segunda red Modbus. De este modo nuestro controlador CoDeSys dispone de 16 zonas de control de temperatura independientes con una sola dirección de red.

En los siguientes links podéis encontrar el manual con los pasos a seguir para conectar un GFXTermo4 de Gefran con un controlador CoDeSys. El fichero GSD y un programa de ejemplo. Ademas he añadido un catalogo de la gama GFXTermo para el que este interesado.

Es una muy buena opción para control de temperatura con reles estáticos con control distribuido en una red de campo.

Manual de configuraciónConexion Gefran_CoDeSys en CanOpen

Programa ejemploCanOpen V01

Fichero GSDGFX4_C03

Catalogo GFXTermo 81114_GEFLEX_08-2014_ESP

Leer más

Controlador como esclavo modbus

El Codesys V3 nos permite configurar el controlador con el HW necesario para que funcione como un esclavo mas de una red modbus. Agregaremos esta comunicación como un dispositivo adicional al controlador. En el documento adjunto se describe el proceso de configuración del esclavo modbus.

Podemos configurar el funcionamiento tanto en conexiones COM como en Ethernet TCP/IP. Si pretendemos configurar un esclavo TCP antes deberemos de insertar el HW del puerto Ethernet.

El funcionamiento del controlador como esclavo modbus nos permite configurar un par de áreas de memoria, que posteriormente mapearemos en el programa, una de ellas se utilizara para entrada y la otra para salida de datos

El área de salida de datos %IW (llamada Holding Registers) es el área sobre la que se reciben los datos enviados desde el maestro modbus.

El área de entrada de datos %QW (llamada Input Registers) es el área sobre la que se escriben los datos que se mandan al maestro modbus.

En la configuración del esclavo, en el tabulador «Configuración ModbusTCP«, existe un campo llamado «Tiempo de espera» que tienen el siguiente efecto sobre el funcionamiento del esclavo modbus:

Habilitado: El controlador espera que el maestro realice una actualización de los datos dentro de la ventana temporal que define el tiempo establecido en este mismo campo. Ósea que el maestro debe de estar refrescando continuamente los datos del esclavo. En el momento que no se recibe datos desde el maestro las variables asociadas al área de salida se establecen en 0.

Deshabilitado: ESTE ES EL FUNCIONAMIENTO NORMAL DE UN ESCLAVO. El controlador mantiene los últimos valores recibidos sobre las variables del área de salida.

Documento descriptivo del proceso ▶ Configurar Esclavo Modbus RTU

Proyecto ejemplo ▶ Esclavo ETH V01 Version: CoDeSys V3.5 SP4 Patch 3

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