Archivo de etiquetas protocolos comunicación

De Arduino a OPC UA

Supongo que si has llegado hasta aquí es porque estás buscando alguna solución para llevar datos de tu placa (o PLC) Arduino a OPC UA.

¿Se puede hacer? Y si se puede, ¿Hay algún instructivo? ¿Cómo lo implemento?.. Pues aquí estamos para resolverlo. Vamos a resolver tus dudas:

¿Se puede hacer?

Desde luego. Cualquier comunicación con Arduino puede pasar por OPC UA. De hecho, en Opiron lo hemos hecho varias veces en diferentes proyectos.

Además, un punto no menor, es que se puede hacer tanto con comunicaciones Serial como TCP (para aquellos que se preguntan si necesitan una Ethernet Shield o similar). Esto incluye que también se puede hacer por WiFi.

Como ves, hay muy pocas restricciones!

 ¿Hay algún instructivo?

Sí, hay instructivo. Lo creamos porque queríamos mantener el conocimiento que adquirimos con los años en tantos ensayos y pruebas. Y lo hemos ido mejorando al punto que lo hemos probado con todo tipo de placas Arduino y clientes OPC UA.

En el instructivo, incluso, agregamos no sólo comentarios, sino también código y vídeos. No sea que vayamos a perder la información cuando nos toque implementar un proyecto 🙂

¿Cómo lo implemento?

Pues tienes dos vías: la primera es seguir nuestro camino:  desarrollar tu propio método para conseguir establecer una comunicación. Eso sí, quedas advertido: vas a pasar por un largo recorrido entre horas de ingeniería, pruebas, etc.

La segunda, es ir seguir nuestro instructivo. ¿Qué ventajas tiene?  Pues las resumimos:

  • Ganas la experiencia de años y años concentrada en un método 100% eficaz
  • Te ahorras semanas de pruebas y ensayos. En una hora tienes funcionando tu sistema.
  • Te ahorras dinero. Piénsalo así, ¿Cuánto vale tu tiempo?
  • Consigues una solución fiable

Como ves, sin duda la segunda opción te ofrece muchas ventajas… Pero depende de ti al fin y al cabo.

De Arduino a OPC UA!

Pues te comentamos que tienes este y otros accesos en nuestra web dedicada a ingenieros como tú:

Como verás, estamos más que dispuestos a ayudarte para tu próximo proyecto!

 

 

 

 

De Arduino a Codesys con Modbus

Si estás buscando una forma para comunicar Arduino y un PLC, este post te va a interesar. Te explicaremos como llevar datos de Arduino a Codesys, uno de los entornos de programación más dinámicos en el mundo de la automatización industrial.

¿Cómo ir de Arduino a Codesys?

Los habituales del blog ya saben que Modbus es uno de los protocolos más famosos en el mundo de la automatización industrial. Es un protocolo ideal porque se puede implementar en todo tipo de dispositivos, y es un protocolo muy fiable en cuanto a comunicaciones industriales.

Es tan versátil que se puede implementar sobre placas Arduino, y como no, cualquier dispositivo basado en Codesys (incluido un PLC). Por lo tanto, es el medio que usaremos para generar la comunicación entre ambos.

Vídeo

Sin entrar todavía en más detalles, y como un vídeo vale más que mil palabras, vamos a ver el vídeo donde veremos los detalles de la comunicación entre ambos:

¿Cómo funciona la comunicación entonces? Pues básicamente con un equipo Codesys que hace peticiones periódicas a nuestro dispositivo Arduino. Ambos hablan Modbus para comunicar datos.

Particularidades de la comunicación

Para aquellos que no están habituados a Modbus, seguramente han visto varias palabras que les pueden sonar a chino: Holding Registers, slave id, canal… Todos son conceptos importantes que definen una comunicación. En nuestro caso, usar 2 holdings es sólo un ejemplo para ilustrar cómo funciona la comunicación. Merece la pena mencionar que si necesitáis más información sobre Modbus, tenemos un curso disponible.

Por otro lado, el programa desarrollado en Codesys ha mantenido la llamada “jerarquía IEC 61131-3”. Para aquellos que no saben que es Codesys, aquí tenemos una serie de entradas.

Últimos detalles

Arduino y Codesys (o cualquier otro PLC) son perfectamente integrables. Y no sólo con Modbus. Hay muchas más alternativas posibles. ¿Estás trabajando con algún proyecto similar? ¿Dudas o consultas? Entonces no dudes en contactarnos!

Serie de articulos sobre Modbus
Serie de articulos sobre OPC UA

Caso de éxito: Red Modbus RTU con en sector Aguas

Nuevo caso de éxito. En este caso, para contarte cómo hemos implementado una red de comunicación Modbus RTU con PLC’s en una estación de bombeo de aguas pluviales.

El caso inicial

Empecemos por el principio. Tenemos un cliente que necesitaba integrar datos de varios equipos dedicados a controlar sistemas de bombeo de agua.

En este caso, estos equipos se comercializan como máquinas que controlan las bombas de agua con un programa determinado, y dejan la posibilidad de ser comandados y comunicarse a través de Modbus RTU. Además, hay algunas válvulas y medidores que también usan este protocolo.

El caso es que nuestro cliente quería controlar estos equipos a través de un PLC con un programa un poco más complejo. Además, este PLC se tenía que comunicar con un sistema SCADA.

¿Qué pasos seguir para implementar una red Modbus RTU?

En resumen, que teníamos que comunicar varios equipos con el protocolo en cuestión, y para ello teníamos que implementar una red de comunicaciones.

Si tienes equipos Modbus RTU, y quieres comunicarlos con un PLC, debes seguir varios pasos:

  1. Hacer un listado de cada equipo y asignarle una dirección.
  2. Registrar el mapa de memoria de cada equipo y saber dónde están las variables que necesitas.
  3. Hacer una prueba de comunicación individual con cada equipo y el PLC.
  4. Probar la red con todos sus equipos.
  5. Implementar el código sobre el PLC y probar el funcionamiento.
  6. Finalmente, diseñar el sistema de visualización que necesitas.

Te puedes estar preguntando si hay que ser muy riguroso con cada una de las pruebas que necesitas hacer… La respuesta es sí. ¿Por qué? Porque cuanto más riguroso seas, menos probabilidades de fallo habrá en cada uno de los pasos, y más fácil será detectar donde puede estar el error en caso de problema.

¿Cómo funcionó todo?

Luego de haber diseñado y probado el sistema, podemos decir que la instalación quedó funcionando perfectamente. Por experiencia, sabemos que las comunicaciones Modbus, una vez se testean, son muy fiables.

De hecho, nuestro cliente va a seguir el mismo patrón de ingeniería en cada una de las instalaciones que van a seguir a esta. Vamos, todo un éxito.

Antes de irte…

Si necesitas implementar una red, no olvides que tenemos un curso de Modbus disponible. En cambio, si prefieres que te ayudemos en su implementación, no dudes en contactarnos. Ofrecemos soporte y asistencia.

 

¿Qué es una topología de red?

Si trabajas con redes, o intentas comunicar un dispositivo con otro, tarde o temprano te enfrentas al término topología. ¿Qué es?

La forma física en cómo se conectan nodos (ya sean pc’s, servidores, etc.) es lo que llamamos como topología de red. Existen diferentes topologías más o menos estandarizadas que tiene cada una sus propias características y que también son aplicables al protocolo TCP. En este post repasaremos algunas de las más comunes.

Topologías Estrella y Anillo

La del tipo estrella, es una de las configuraciones de red más comunes. En esta configuración, cada nodo se conecta a un dispositivo de red central, como un concentrador o un conmutador.

Esta topología tiene la principal característica que la comunicación de todos los nodos pasa por un nodo central. Esto significa que si se produce un fallo en el nodo central, todos los demás perderán la comunicación entre sí. Por lo tanto, en esta configuración es muy importante asegurar que las capacidades de este nodo serán las suficientes por el alto tráfico que deberá soportar.

 

Por otro lado, la topología ring (o anillo) es una configuración de red en la que las conexiones de dispositivos crean una ruta de datos circular

Por lo tanto, en esta configuración, cada nodo es transmisor y receptor al mismo tiempo, pasando las señales de una estación a otra. En estas configuraciones existe el conocido “paso de token” o testigo, porque se necesita saber si el tráfico ya ha pasado por un nodo determinado. Una derivación de esta topología es la red de doble anillo.

Bus y otras topologías

Es una configuración que tiene todos los nodos conectados a un circuito común. En este caso por lo tanto, toda la información viaja por un cable – el bus -.

Este tipo de configuración se caracteriza porque, si alguno de los nodos falla, la comunicación se va a mantener, puesto que la comunicación del bus es independiente del buen funcionamiento de un nodo determinado.

¿Otras topologías? ¿Cuál es la correcta?

Hay muchísimas topologías: algunas de ellas son las Line, Fully connected, Tree y Mesh, entre otras, cada una con sus propias características.

La elección de una u otra depende de múltiples factores. Por un lado, la disponibilidad, ya que no siempre están disponibles en todos los protocolos de comunicación o recursos disponibles. Por el otro, cada una tiene sus propias ventajas e inconvenientes, por lo que en función de tu caso, va a depender mucho del proyecto que tengas que implementar.

¿Quieres aprender más sobre redes?

Si estás buscando información clara y concisa, en forma de un curso online, te recomendamos sin duda nuestro Curso de Redes TCP.

OSI, la pirámide de las comunicaciones

Todos asumimos que los protocolos de comunicación funcionan y sirven para llevar datos de un punto a otro. Por detrás, existe una tecnología que puede variar en función del protocolo. Sin embargo, lo que se mantiene inalterable es el modelo que emplean todos: OSI.

¿En qué consiste?

El modelo OSI, del inglés Open System Interconnection, se desarrolló por la ISO (International Organization for Standarization) como una arquitectura para comunicaciones electrónicas y es una referencia para el desarrollo y comprensión de protocolos.

Dicho de otra forma, OSI presenta un modelo común para entender cómo funcionan los protocolos y también para diseñar nuevos, ya que los divide en capas funcionales.

La pirámide de 7 capas

Las pirámides tienen una punta y una base. Desde el punto de vista funcional, pasa lo mismo con la capa OSI, la punta es el funcionamiento, mientras que la base mantiene el funcionamiento.

En OSI, se especifican siete capas:

  • Aplicación, 7
  • Presentación, 6
  • Sesión, 5
  • Transporte, 4
  • Red, 3
  • Enlace de datos. 2
  • Física, 1

Las capas en las que OSI divide los protocolos tienen funciones muy específicas. Las capas inferores (1 a 3), se dedican a transportar los datos a nivel físico, mientras que las superiores (4 a 7) se dedican a presentar la información a nivel de aplicación.

Ejemplos: OSI en TCP

Veamos el ejemplo del modelo TCP/IP (Protocolo para el Control de Transmisión/ Protocolo de Internet), está compuesto por cuatro capas (simplifica a OSI), en la que cada una se encarga de determinados aspectos en la comunicación y a su vez cada una brinda un servició especifico a la capa superior. 

En la imagen vemos la pila OSI (izquierda) y su modelo TCP/IP (derecha)

Conclusión, ¿Para qué sirve OSI?

En resumidas cuentas, para estandarizar protocolos de comunicación en un modelo comprensible para todos. Esto hace que los protocolos se diseñen, mantengan, y configuren en un lenguaje común, lo que sin duda hace que tanto desarrolladores como usuarios puedan generar comunicaciones de forma mucho más efectiva.

¿Te gustaría seguir profundizando en el tema? Revisa entonces nuestro recurso digital sobre Redes TCP.

Buses de campo en Codesys

Una de las mejores funcionalidades que tiene Codesys es su capacidad para poder comunicarse con todo tipo de dispositivos mediante diferentes protocolos de comunicación y buses de campo. ¿Te interesa configurarlos en Codesys? Sigue  leyendo.

¿Qué son?

Empecemos por lo esencial. Los buses de campo son medios de comunicación electrónicos e industriales para comunicar PLC’s con otros PLC’s o periferia descentralizada.

En su día, publicamos este post donde te ampliamos la información.

¿Cómo los usa Codesys?

Los buses de campo se integran en Codesys mediante librerías propias, lo que significa que podemos programar las comunicaciones mediante configuradores o mediante bloques.

Los configuradores están perfectamente integrados y se pueden usar para programar las comunicaciones de forma sencilla e intuitiva:

Por el otro lado, los bloques e instrucciones específicas permiten programar las comunicaciones de forma dinámica, lo que en algunas veces puede ser beneficioso para programar determinadas funciones.

¿Qué buses de campo soporta Codesys?

Codesys cada día se amplía, pero para resumir podríamos decir que tenemos disponibles:

  • Modbus en sus diferentes variantes (TCP, RTU…)
  • PROFIBUS y PROFINET
  • EtherNet / IP
  • EtherCAT
  • BACnet
  • J1939
  • Sercos
  • IO-Link

Unos cuántos, ¿Verdad?

Beneficios de usar Buses de Campo en Codesys

Además de las propias ventajas que tiene poder comunicarse con tantos tipos de dispositivos, hay otras ventajas implícitas, que las podríamos resumir en:

  • Generar la configuración en el mismo entorno (sin tener que aprender e instalar cosas nuevas)
  • Depurar errores en el mismo entorno que la lógica del PLC
  • Elegir con más libertad el protocolo o bus que usaremos para la aplicación (tenemos tantos disponibles…)

Seguir aprendiendo

Este año hemos iniciado nuestros Workshops con buses de campo con Codesys, donde, entre otros, hablamos de Modbus, I/O Link, Ethercat y CANOpen.

Y tú, ¿Cuáles usas? ¿Te sientes cómodo con ellos?

Nuevo Evento I/O Link con Codesys

Desde hace unos años, I/O Link ha emergido como una prometedora tecnología dentro de la norma IEC 61131 (Sí, la misma de Codesys).  Como especialistas en IEC61131, hemos decidido organizar un evento I/O Link donde se muestre como integrar Codesys con I/O Link.

¿Qué es Codesys?

Es un software de programación de PLC’s basado en la normativa IEC 61131-3, . Una de sus mayores particularidades es que es agnóstico al hardware, lo que posibilita que se puedan programar muchos controladores. Tienes más información en nuestra serie de artículos codesys.

¿Qué es I/O Link?

I/O Link es parte de la normativa IEC61131, de la que también forma parte Codesys. En particular, I/O Link es la sección IEC61131-9, que resuelve la interfaz de comunicación entre PLC’s con sensores y actuadores.

Por lo tanto, diríamos que se trata de un protocolo de comunicación orientado a la comunicación de sensores y dispositivos en la industria. Hay muchas ventajas en I/O Link, pero seguramente la más importante es la de formar parte del estándar -lo que genera la independencia de hardware, al igual que ocurría con Codesys-.

Puntos de la Jornada

Durante la jornada, haremos una demostración de las capacidades de I/O Link. En particular, veremos diferentes casos sobre cómo se usa la tecnología, y cómo combinarla con Codesys y OPC UA para tener una fábrica inteligente.

El enfoque de la jornada es muy práctica, y va a incluir tanto presentaciones técnicas como demostraciones para facilitar una rápida comprensión de la tecnología.

¿Cuándo y dónde?

El evento I/O Link será en Munro, Buenos Aires, el día 10 de Marzo de 2020. El evento lo organizaremos junto con la empresa Aumecon, representante de Turck en Argentina.

¿Cómo apuntarse?

Puedes solicitar tu vacante consultándonos aquí. Si eres un gerente, programador, integrador de sistemas, técnico de mantenimiento y en general estás interesado en conocer más de I/O Link, no deberías dejar pasar esta oportunidad.

Buses de campo

La imperiosa necesidad de integrar cada día más señales de control en la industria llevó a  buscar alternativas al cableado habitual ¿Te interesa saber más sobre buses de campo? Sigue leyendo.

¿Qué es un bus de campo?

Empecemos por lo esencial. Los buses de campo son medios de comunicación electrónicos e industriales para comunicar PLC’s con otros PLC’s o periferia descentralizada.

Dicho de otra forma, un bus de campo es un bus que nos permite comunicar con otros dispositivos con un protocolo específico en campo, es decir, en una área de fabricación.

¿Por qué debería comunicarse un PLC con un bus de campo?

Bueno, ya sabrás que una de las características esenciales de los PLC es su capacidad de comunicarse con su entorno mediante Entradas y Salidas. Las Entradas y Salidas normalmente se comunican con el PLC mediante módulos específicos y cada una de ellas es cableada por separado.

El bus de campo integra muchas señales, reduciendo en gran medida los costes de instalación

Los buses de campo se caracterizan por hacer lo mismo pero simplificando la instalación, puesto que el cable permite integrar muchas más señales. Además, estos buses tienden a ser cada vez más inteligentes, lo que significa que permiten llevar señales adicionales como fechas de calibración etc.

Los beneficios de los buses de campo por lo tanto son muchos, pero resumiendo: instalación más rápida, mejor mantenimiento, más interoperabilidad y reducción de tiempos de parada.

¿Qué buses de campo existen hoy en día?

El desarrollo tecnológico ha hecho que surjan muchos y diferentes. Por ejemplo, AS-I, Profibus, Modbus, etc. Cada uno con sus diferentes particularidades y ventajas.

Seguramente, la evolución tecnológica de los últimos años ha venido acompañada por los pasos hacia delante en la electrónica, lo que ha permitido que los buses más nuevos tengan mayores capacidades de comunicación, más velocidad, etc.

¿Debería usar aprender a usar buses de campo?

Si estás trabajando en automatización industrial, más temprano que tarde vas a tener que aprender, así que sí… Por eso, te recomendamos que eches un vistazo a este curso sobre buses.

 

TCP y UDP, aplicaciones en la industria

Las aplicaciones que se comunican con Ethernet usan normalmente uno de estos dos protocolos, TCP o UDP. ¿Cuál es la diferencia entre ambos? ¿Para qué se usa cada uno? En esta entrada repasamos las propiedades y ventajas de cada una de estas tecnologías

¿Qué es TCP?

Las siglas son Transmission Control Protocol. La principal característica que diferencia a TCP es que este protocolo garantiza la entrega de los datos entre el emisor y el receptor de un mensaje.

¿Se usan en la industria? Por supuesto. Casos:

  • Comunicaciones PLC a PLC
  • Comunicaciones PLC a PC (Incluido OPC, etc.)
  • Comuninicaciones PC a PC
  • Comunicaciones PC a Cloud

Es decir, se usan para casi todo… Las comunicaciones TCP sin ir más lejos son las que usamos todo el tiempo para comunicarnos. Sobre tu navegador, en definitiva, haces una petición como cliente a algun servidor donde está alojada la web con TCP.

¿Qué es UDP?

Las siglas son User Datagram Protocol. Se trata de un protocolo que permite el envío de datos sin la necesidad que exista una conexión establecida.

Las propiedades de UDP hacen que sea un protocolo más ágil, aunque UDP no controla la entrega de la información.

¿Se usan en la industria? Sí, aunque en casos más específicos, pero igualmente útiles. Por ejemplo:

  • Si vas a enviar una temperatura que está fluctuando, lo puedes hacer perfectamente con UDP. ¿Y si se pierde un paquete? Nada, la inercia de las temperaturas es tan lenta que no vas a notar cambios. Es decir, que si pierdes un “23.23” y recibes el siguiente paquete con un “23.223”, te dará igual.
  • Si necesitas hacer un broadcast (envío a muchos) a varios servidores, sobre vídeo… ¿Qué pasa si se pierde un paquete? Nada, el emisor seguirá enviando imagen todo el tiempo..

UDP de hecho es usado para aplicaciones VoIP o DHCP, entre otras.

¿Qué se usa en la industria?

Pues de todo. Las comunicaciones TCP y las UDP tienen cada una sus propias particularidades, que las hacen beneficiosas en cada caso.

Sin entrar en formalismos, el resumen es que las comunicaciones TCP son más interesantes cuando se necesita establecer una comunicación segura, mientras que las UDP pueden ser más beneficiosas cuando se envían streams de datos que fluctuan todo el tiempo, además de broadcast.

Curso de comunicaciones TCP en la industria

Si eres de aquellos que lleva tiempo buscando algun curso de introducción para saber de una vez la diferencia entre TCP, UDP, FTP, etc. o buscas cómo abrir y cerrar puertos, te traemos buenas noticias, puesto que muy pronto lanzaremos un Curso Digital sobre comunicaciones TCP.

OPC UA: Conexiones y sesiones

Una de las principales características en la que se basa OPC UA es que las comunicaciones entre cliente y servidor están basadas en conexiones y sesiones. ¿Qué son?, ¿Para qué sirven?, ¿Cómo se aplican? En esta entrada trataré de clarificar algunos de estos conceptos.

Sesiones

Lo más importante, las comunicaciones en OPC UA se basan en sesiones. Las sesiones representan una conexión entre la aplicación cliente y la aplicación servidor. En este punto, es bueno diferenciar entre una conexión y una sesión. La conexión se produce cuando el cliente apunta a un endpoint – el del servidor -, y éste le devuelve la “conexión”. En el momento que esto pasa, se establece una sesión, que no es ni más menos que el flujo de información que fluye a través de la conexión generada (como si de una autopista se tratara). Aunque la diferencia a nivel práctico es poca, seguramente conviene recordar que la sesión está más ligada al flujo de datos.

Timeouts y sesiones

¿Qué sentido tendría tener una conexiones y sesiones abiertas si en las mismas no fluyen datos? …Ninguna. Por lo tanto, las sesiones, en general, deben estar “vivas” todo el tiempo… Esto significa que, si una sesión se cierra por lo que sea, luego los clientes y servidores deben desconectarse entre sí. En la práctica, esto significa que cliente y servidor pueden monitorear el estado de la sesión para que noten los problemas con suficiente anticipación y, en caso de desconexión, puedan ser notificados y cerrar la conexión. Los timeouts son herramientas que tienen clientes y servidores para que, teniendo un tiempo predefinido, puedan consultarlo y, en su caso, cerrar la conexión. Por ejemplo, en OPC UA muchos clientes tienen el timeout especificado en una hora, lo que significa que, si no ha habido flujo de datos en ese tiempo, cierran el canal de la comunicación.

Parámetros de sesión

Para generar comunicaciones fiables y seguras en el tiempo, es deseable parametrizar diferentes parámetros en una comunicación OPC UA basada en sesiones. ¿Ejemplos? La cantidad de sesiones abiertas, el timeout y la negociación de la reconexión y son sólo algunos de los parámetros a los que nos referimos.

¿Dónde y cómo setear estos parámetros?

A pesar de la conveniencia de poder configurar estos parámetros, los mismos no siempre están disponibles en los GUI de clientes y servidores para configurarlos. En cualquier caso, eso no significa que no puedan ser manipulables. En Opiron contamos con varias herramientas para ello. ¿Tienes algún problema con la sesión o los timeouts? Aquí estamos para ayudar 😉

Soluciones OPC UA

De Modbus a OPC UA
De PLC's al Cloud, ERP's...
De OPC a OPC UA
data logging
De PLC a SQL

¿Quiénes somos?

Somos expertos en tecnología OPC UA y partners de ProsysOPC. Nuestros servicios incluyen desde consultoría, proyectos o Workshops regulares.