Preguntas frecuentes del curso de iniciación a Codesys ®
La primera edición del curso de Codesys ® fue un rotundo éxito, tanto que ya estamos preparando una nueva edición, que se repetirá periódicamente. En esta entrada contestamos a las preguntas frecuentes sobre este apasionante curso.
1. ¿Qué es Opiron?
El curso lo damos desde Opiron, donde somos expertos en Codesys ®, ya que hemos realizado cursos y proyectos sobre esta tecnología. Llevamos más de 10 años en el mundo de la automatización industrial.
2. ¿Sirve si no sé programar PLC’s?
El curso de Codesys ® es un curso de inciación en la programación de PLC’s. Eso significa que explicamos las bases de programación de PLC’s, el entorno de programación , las instrucciones más importantes e incluso hacemos proyectos. Sin embargo, es recomendable tener nociones básicas de programación en cualquier lenguaje, reconocer tipos de datos, etc.
3. ¿Qué es Codesys ®?
Codesys ® es el acrónimo de Sistema de Desarrollo de Controladores y es un software de programación de PLC’s industriales conforme con el estándar industrial internacional IEC 61131-3. Un entorno de programación de automatización industrial universal. Permite poder programar cualquier PLC sea del fabricante que sea, incorporando además lenguajes Ladder, de instrucciones y bloques…
4. ¿ Por qué Codesys ®?
Si buscas iniciarte en un estándar de programación versátil, que te permita programar cuántos más PLC mejor, ésta es sin duda la herramienta que debes conocer. Codesys ® te permite programar más de 500 PLC’s en el mercado. Te recomiendo leer la entrada Codesys: 5 Razones para aprender a programarlo.
5. No tengo claro los temas que vamos a ver en el curso
El curso contiene temas teóricos y prácticos. Estos son Introducción a la automatización industrial, Introducción al estándar IEC 61131, Introducción a Codesys ®, Lógica con Codesys ®, Automatización y visualización y Proyectos. Cada tema tiene ‘un ejercicio para comprobar los conocimientos adquiridos.
6. ¿Cómo se va a desarrollar el curso?
El curso de iniciación a Codesys es un curso online de 4 semanas de duración en el Campus Tecnológico Virtual, un micro-site privado (recibirás un login/password personal). Tendrás acceso a un profesor durante estas 4 semanas.
Puedes suscribirte a nuestro blog para estar en la última en este enlace. Puedes inscribirte en este enlace.
Tramas Modbus
Puede que en algún momento te tengas que sentar e ir un paso más allá que simplemente leer datos desde tu SCADA, ya sea para diagnosticar un problema o para verificar la red, y analizar los datos crudos que vienen de un equipo Modbus. Por eso, en esta entrada vamos a analizar cómo se conforman las tramas Modbus.
¿Qué es una trama?
En protocolos de comunicación, las tramas son unidades de datos que envía un dispositivo hacia otro/s, y que, en conjunto, conforman un mensaje. Por lo tanto, y a modo de simplificación, podríamos decir que en definitiva la trama es el conjunto de bits que conforman un mensaje
El formato de los mensajes depende, además del protocolo en si, de la capa física con la que trabaje el protocolo. Por lo tanto, no podemos esperar que la trama de mensajes de Modbus RTU y Modbus TCP sean exactamente igual, aunque en ambos casos conservan similitudes.
¿Qué campos conforman la tramas Modbus?
Una vez que sabemos de qué se tratan las tramas, tratemos de identificar qué campos identifican las tramas Modbus:
- Device Address: Dirección del dispositivo hacia donde se dirige el emisor.
- Function Code: Función que necesita realizar el emisor.
- Register Address: Dirección a la que queremos acceder.
- Number of Registers: Número de registros sobre los que queremos realizar la función.
Por ejemplo, para leer dos registros del Holding Register 40212 de un Slave cuya dirección es 15, el comando que el Master debería enviar sería 15 -03-0212-02.
Luego, puede haber más campos, por ejemplo, normalmente al final del mensaje nos encontramos con el Error Check.
- Error Check: El CRC es una verificicación del mensaje, para comprobar que éste no tiene malformaciones. Esta verificación se corresponde con el checksum de la trama.
Por supuesto, éste análisis no completa la trama completa del protocolo completo – RTU, TCP, etc – pero sí son los campos de cualquier protoclo Modbus, sea cuál sea el medio.
Tramas en Modbus TCP
Como ya hemos mencionado, en realidad las tramas completas dependerán del medio que usemos para enviar nuestros mensajes Modbus. Por ejemplo, en Modbus TCP la trama Modbus viene dentro de una trama TCP, por lo que ésta es un poco más larga. Te recomendamos que te suscribas al blog y descargues la guía gratuita sobre Modbus TCP para analizar las diferencias.
La torre de Babel de los PLC
No hace mucho me encontré a un viejo amigo, con el que compartí muchos momentos en la industria en el pasado. Nos sentamos a tomar un café en una cafetería cerca de la estación de tren, dado que justamente coincidimos allí, uno por razones de trabajo y el otro por vacaciones… De entre las varias cosas que discutimos, hablamos sobre programación, y de la torre de Babel de los PLC.
Una historia larga
Dejad que os comente que nos conocemos desde hace mucho tiempo, cuando estábamos en la primaria y porque compartíamos como afición los ordenadores y los videojuegos. Con los años, terminaríamos dedicándonos a lo mismo, la automatización industrial.
Ya salidos de la universidad, y cada uno trabajando en empresas diferentes, nos surgió la posibilidad de hacer parte de la automatización de una fábrica que estaba cerca de nuestras casas. Era algo fuera del trabajo, como un extra, que decidimos hacer no tanto por el dinero sino por el reto que significaba para nosotros.
El proyecto lo hacíamos los fines de semana y tardamos meses en terminarlo, en parte por la inexperiencia y por otra por el poco tiempo con el que contábamos, pero lo terminamos haciendo y, a día de hoy, parte de esa fábrica sigue utilizando esos PLC’s que dejamos instalados ya hace tantos años.
La integración
Por diferentes razones, la fábrica se expandió y el gerente de tecnología fue reemplazado por uno nuevo. Un día, el gerente decidió ampliar nuevamente la fábrica y contrató a una popular empresa para hacer el trabajo, que instaló unos PLC de una multinacional muy conocida… Hasta aquí, todo normal.
Pero no pasó mucho tiempo hasta que el gerente quiso integrar las partes vieja y nueva de la fábrica: quería comunicar ambas tecnologías para tener una mayor integración de los datos… ¿Ya sabéis a quiénes llamó imagino, no?… A los 15 días yo mi amigo volvíamos a la fábrica.
Lo que vino luego fueron semanas de idas y venidas con los técnicos de la nueva tecnología: Las incompatibilidades eran notorias, ya que los driver no eran compatibles entre sí, los ciclos de scan de cada PLC eran completamente diferentes… ¡Tuvimos que hacer una auténtica obra de ingeniería para hacer una compatibilidad!
Un objetivo
Tomando el café hace unos días recuperamos estos momentos, nos reímos y suspiramos, y él me preguntó: ¿Te imaginas que hubiésemos utilizado IEC 61131? ¡La de problemas que nos hubiésemos ahorrado para dejar de lado la torre de babel de los PLC! Sigue leyendo para saber más de este protocolo.
¿Qué es un protocolo de comunicación?
Quienes estamos en esto del mundo de la automatización, lo usamos todo el tiempo: usamos un protocolo de comunicación para comunicar datos entre máquinas de alguna forma u otra.
¿Qué es un protocolo de comunicación?
Bueno, empecemos por lo básico. Un protocolo de comunicación es un método para comunicar datos entre máquinas, ni más ni menos. Este método, en realidad queda definido tanto por el medio físico como por el medio informático en la que se intercambian los datos.
No hace tanto tiempo, los protocolos de comunicación eran de lo más primitivos: una voltaje tenía un significado, y una ausencia de voltaje tenía otro. Y digo más, todavía hoy este método es ampliamente usado en el mundo industrial.
La evolución
Este método funcionó, y funciona, bastante bien en entornos donde no es necesario comunicar grandes cantidades de datos. En cambio, cuando necesitamos ampliar las comunicaciones para hacerlas más rápidas y con mayor ancho de banda, necesitamos métodos más sofisticados para comunicar. Necesitamos definir reglas que permitan comunicar más y mejor.
De esta manera, en la industria surgieron primero estándares físicos, como RS-232, RS-485 o WiFi, donde los programadores pueden basar sus comunicaciones para realizar sus propios protocolos. De esta forma por ejemplo, Modbus se puede basar en estándares serie o TCP/IP para comunicar sus datos.
Cuestión de capas
De esta manera, el Modelo OSI define 7 capas para definir un protocolo de comunicación. Las más bajas tienen que ver con el medio físico por donde se propagará el mensaje, y allí se define el cableado, el conector, o los niveles de voltaje. En las más altas se definirán el conjunto de reglas por cómo se hará la comunicación para las aplicaciones informáticas.
Ahora que ya sabes qué es un protocolo de comunicación, te recomiendo que leas sobre Modbus, el protocolo de comunicación más universal del mundo industrial.
5 Diferencias entre OPC UA y OPC Clásico
Quién más y quien menos, ha escuchado a hablar en alguna ocasión del Internet de las Cosas, también es probable que en alguna ocasión haya escuchado que se puede aplicar a la industria y, si así ha sido, probablemente también OPC UA. ¿Por qué es OPC UA tan importante? ¿Qué diferencias hay entre OPC UA y OPC Clásico?
1. Sistemas Operativos
OPC Clásico está basado en tecnología Windows, ya que utiliza COM / DCOM para mover datos entre aplicaciones. OPC UA, en cambio, se puede implementar sobre cualquier sistema operativo, ya sea Android, Linux o Windows.
2. Tecnología embedida
En OPC UA, los servidores pueden residir dentro de los mismos PLC, formando parte del hardware. En OPC Clásico, los Servidores OPC son drivers que deben instalarse sobre una máquina que se comunique directamente sobre la máquinas.
3. Seguridad
En la era de la información, somos cada vez más conscientes de la importancia de proteger los datos. A diferencia de OPC Clásico, OPC UA permite la encrpitación de las comunicaciones mediante certificados de seguridad que los interlocutores deben conocer antes de empezar a comunicarse.
4. Comportamiento con Firewall
Aquellos que han sufrido los problemas de DCOM sabrán que OPC Clásico no es especialmente amistoso con el Firewall: ya que además de necesitar tener muchos puertos abiertos, necesita de muchas configuraciones. OPC UA es amistoso con el Firewall, basta con abrir un puerto para comunicar aplicaciones.
5. Modelo de información
En OPC Clásico tenemos diferentes tecnologías para lidiar con cada tipo de fuente de datos: OPC DA para el tiempo real, OPC HDA para historización de datos y OPC A&E para alarmas y eventos… todas tecnologías que no pueden comunicarse entre si. Este problema es resuelto con OPC UA, que combina todas ellas en una sola tecnología.
Como vemos, las diferencias entre OPC UA y OPC Clásico son sustanciales, por lo que merece la pena plantearse el modelo de información de la empresa y saber más sobre esta tecnología.
El reto de aprender Modbus por si sólo
Por allá en el año 2007, cuando empecé en este mundo de la automatización, me asignaron un nuevo proyecto: Tenía que comunicar dos máquinas con un protocolo del que ya había escuchado cosas antes, tenía que aprender Modbus.
La empresa para la que yo trabajaba por ese entonces desarrollaba proyectos de automatización y tenía un PLC desde hacía ya varios años que controlaba la extrusora de una fábrica.
Para aquel entonces, la fábrica compró un nuevo conjunto de válvulas y encomendó la tarea de integrarlas al PLC mencionado a la empresa para la que trabajaba, que me asignó a mí el trabajo, uno de mis primeros realmente.
¿Qué hice en ese momento?
Pues me puse a sudar. Pero al mismo tiempo, tuve una sensación difícil de explicar, lo vi como un reto, ¡Tenía que hacerlo!
Me fui a la universidad a buscarme un libro de comunicaciones industriales que tuviese contenido sobre Modbus. En general puedo decir que aprendí cosas, pero antes…
Me frustré.
¿Cómo podía ser que esos libros tuviesen tan pocos ejemplos? Luego de esta parte teórica, vino la parte práctica, es decir, la etapa de programar el PLC en si mismo con algunas funciones Modbus. ¿Cómo podía acceder al mapa de memoria de las válvulas? ¿Cómo podía mapear Entradas y Salidas? Desde luego, el PLC que programaba no tenía mucha literatura.
Me frustré.
¿Cómo podía ser que hubiese pocos ejemplos? Luego de tener una parte del código desarrollada me faltaba poderlo probar con algo… pero en la empresa no tenían ningún dispositivo Modbus, así que ya te lo puedes imaginar, la prueba la tuve que hacer en la misma fábrica.
Me frustré.
¿Cómo podía ser que no hubiese ningún dispositivo para probar? No puedo mencionar la cantidad de cosas que aprendí, pero también la cantidad de horas que me tiré en la fábrica…
¿Y entonces?
Bueno, el proyecto desde luego salió, logré comunicar el PLC con esas nuevas válvulas y la satisfacción que me llevé fue impresionante, me sentí como el mismo Mark Zuckerberg: aquello era impresionante, la fábrica estaba funcionando y en parte era gracias a mí. Era la sensación de éxito.
Pero cuando pasaron unas semanas y maduré la experiencia, recopilé toda la información que había obtenido y la organicé correctamente. Desde luego, pensé que sin esfuerzo no hay éxito, pero también me di cuenta que en realidad había mal gastado muchas horas por errores básicos de organización en mi aprendizaje.
¿Te sientes identificado? Te recomiendo leer esta serie de post para aprender Modbus…
3 tecnologías para sentar las bases de industria 4.0
¿Qué líneas de trabajo puedo seguir para implementar éxitosamente la industria 4.0 en mi fábrica? Hoy en día existen múltiples tecnologías, todas ellas complementarias, que sentarán las bases adecuadas para converitr una fábrica convencional en una fábrica 4.0. Veamoslas:
Arquitecturas flexibles: OPC UA
Una arquitectura 4.0 es aquella que puede llevar datos de forma transversal desde los activos de planta hasta la red empresarial – incluida la nube -. Y como el personal de IT sabrá, esto no siempre es tan fácil. Durante los últimos 20 años nos hemos dedicado a poner barreras que tienen por objeto garantizar la seguridad de los activos industriales, como firewalls, dominios diferentes, redes de control independientes a las redes corporativas… pero que realmente no ayudan a generar un movimiento de datos transversal. ¿Cómo llevar datos entre redes? OPC UA.
Tecnología Web: Scada Web
Los SCADA nunca pasan de moda, llevan en la industria desde hace más de 20 años entregando beneficios a las empresas que han mejorado la productividad de las mismas.
- Mejorar eficiencia de operación
- Maximizar calidad
- Optimización de procesos
Si quieres saber cómo funciona un Cloud Scada puedes revisa esta entrada de nuestro blog. También te recomiendo leer los Beneficios de un SCADA móvil.
PLC’s inteligentes
Las fuentes de datos como los PLC deben proveer de seguridad y robustez. En este sentido Codesys es una tecnología ideal para implementar la tecnología inteligente a nivel de planta. Codesys es un entorno de programación que:
- Está basado en el estándar IEC 61131-3.
- Es independiente del hardware que tengamos en planta.
- Provee de múltiples recursos y librerías online.
Te recomiendo leer esta entrada si quieres saber más sobre Codesys. Por supuesto, te recomiendo que nos contactes si quieres hacer un curso, dado que hacemos cursos de Codesys.
Soluciones Industria 4.0
En Opiron tenemos todos los ingredientes disponibles dado que ofrecemos soluciones basadas en OPC UA, Scada y Codesys, herramientas líderes en su campo para llevarte a la auténtica industria 4.0. ¿Estás listo? 🙂
¿Modbus y Arduino combinados?
Modbus y Arduino: por un lado un protocolo de comunicación con un larguísimo recorrido en el mundo industrial del que hemos hablado en otras entradas.
Por el otro, una marca que desarrolla placas Open Source de la que Opiron ha hablado largo y tendido en muchos tutoriales. De hecho, tenéis la sección de Arduino abierta en nuestro canal de Youtube.
¿Qué pasaría si combináramos ambos?
¿Un dispositivo con Modbus y Arduino?
Sigamos avanzando en nuestro concepto: Modbus es un protocolo de comunicación que desde hace unos años es libre, y por lo tanto, puede implementarse en múltiples dispositivos sin necesidad de pagar royalties. Por el otro, Arduino es también una plataforma de hardware libre, con una comunidad de programadores y recursos enormes. Las posibilidades de combinar ambas tecnologías son muchas, pudiendo ampliar las capacidades de comunicación de las placas Arduino con:
- Sistemas SCADA.
- Sistemas PLC, RTU.
- Redes industriales ya existentes.
Pero seguramente conviene no quedarse ahí, puesto que Modbus además aporta la seguridad de apoyar nuestros proyectos sobre una tecnología absolutamente robusta y probada en el mundo industrial.
Modbus: ¿TCP o RTU? , Arduino ¿Qué placa?
Cuestión de tecnología: Como sabemos, de Modbus tenemos diferentes versiones, desde las versiones Modbus RTU hasta las Modbus TCP. Por suerte, todas ellas son integrables con los módulos Arduino gracias a la gran cantidad de librerías desarrolladas para tal fin. Elegir una u otra dependerá de las necesidades de las comunicaciones que debamos implementar así como de las redes donde se deba integrar el dispositivo. Te recomiendo leer esta entrada para más información.
En cuanto a Arduino, ¿Es Modbus implementable en cualquier placa? La respuesta corta es sí… Al menos Arduino Mega, Uno o Leonardo sí lo son (probado!)
¿Quieres aprender a implementar Modbus con Arduino?
Es evidente que las ventajas de combinar ambos son enormes. Ahora bien, aprender por separado ambas tecnologías (aunque ya sepas al menos una de ellas), no es tan fácil. Por mucho que haya librerías y recursos disponibles en internet. Por ello, te proponemos que estés atento, puesto que muy pronto lanzaremos un curso que te permitirá convertirte en un experto de ambas tecnologías.
Mapa de memoria de Modbus
Para comprender el mapa de memoria de Modbus, basta recordar que Modbus es un protocolo desarrollado para PLC’s, y que a estos se les pueden conectar básicamente 4 tipos de instrumentos: de salida digital, de entrada digital, de salida analógica y de entrada analógica, que coinciden con las 4 áreas que describimos a continuación.
Coils
Las salidas digitales, también llamadas coils en la mayoría de biblografía que podáis encontrar. Cada registro dispone de 1 bit. La región de salidas digitales va de la dirección @1 a @9999. Por lo tanto, esta región del mapa de memoria ocupa 10.000 bits, y cada bit puede representar una salida digital.
Inputs
Las entradas digitales, también llamadas inputs en muchos libros. Cada registro dispone de 1 bit. La región de entradas digitales va en este caso de la dirección @10001 a @19999. Por lo tanto, al igual que en las salidas, el mapa de memoria de las entradas digitales ocupa 10.000 bits, y cada bit representa una entrada digital.
Input Registers
Las entradas analógicas, que podréis identificar como input registers en la mayoría de bibliografía. Cada registro dispone de 16 bit. La región de entradas digitales va en este caso de la dirección @30001-@40000. Por lo tanto, al igual que en las salidas, el mapa de memoria de las entradas digitales ocupa 160.000 bits. ¿Qué por qué ocupan más bits las entradas analógicas que las digitales? Pues porque en las entradas digitales sólo hay dos estados (abierto o cerrado), mientras que las analógicas pueden tener infinitos (2 elevado a 16) valores entre dos valores diferentes.
Holding Registers
Las salidas analógicas, que podréis identificar como holding registers en la mayoría de bibliografía. Por lo tanto, al igual que en las salidas, el mapa de memoria de las entradas digitales ocupa 160.000 bits.
¿Y dónde están las direcciones @20001- @30000?
Por si no te has dado cuenta mientras ibas leyendo, entre el espacio que comprende las inputs y las holding registers queda un espacio de direcciones indefinido según el estándar Modbus.
Conclusión
El mapa de memoria de Modbus es un reflejo de los instrumentos que podemos conectar a un PLC. Conocer el mapa de memoria nos permitirá optimizar los accesos a memoria de dispositivos externos, optimizar las conexiones y también depurar / diagnosticar problemas más rápidamente.
Redes Modbus: Cuatro puntos a recordar
Imagina que eres un ingeniero de control y un día te llaman por problemas de latencia o sincronización en redes Modbus… ¿Qué parámetros debería consultar? Cada red puede tener sus propias particularidades, veamos 😉
1. Funcionamiento
Lo primero es lo primero: recordar el funcionamiento: En redes Modbus, las reglas de cómo fluye la comunicación las dicta el propio protocolo. En la comunicación, hay siempre un maestro que pregunta datos a uno o varios esclavos al mismo tiempo. El protocolo determina, en función del mensaje enviado por el maestro, qué acción debe tomar el esclavo (por ejemplo, abrir una válvula o comunicar un dato).
2. Capa física
Ya lo hemos mencionado en otros post, estamos hablando de un protocolo de aplicación y por lo tanto, podemos encontrarnos su implementación sobre diferentes medios fìsicos, en concreto, sobre RS-232 o RS-485 – Modbus RTU y Modbus ASCII- y Ethernet, Modbus TCP/IP. Si vamos un poco más allá, las comunicaciones serie y TCP/IP pueden ser implementadas para conexión por cable, wireless, SMS o GPRS.
En función de cada una además, tenemos más particularidades. En redes Modbus RTU, se prevé un total de 255 direcciones entre @1 y @254 para dispositivos, y la @0 reservada para broadcasting. Cabe mencionar de cada protocolo físico, el broadcasting no es posible sobre RS-232, mientras que en RS-485 el broadcasting se puede extender a 32 dispositivos al mismo tiempo. La velocidad de transferencia para estas redes está limitada a 19,2 kbps.
En redes Modbus TCP/IP, puede haber más dispositivos en la red y también la velocidad de transferencia es mayor, 10/100 Mbaud. Esto convierte a Modbus en un protocolo IoT, tal y como comentábamos en esta entrada.
3. Cantidad de dispositivos
Parece obvio pero muchas veces, no se tiene en consideración. ¿Cuántos dispositivos tiene la red? La cantidad de dispositivos va a afectar en la latencia y sincronización de las comunicaciones.
4. Implementaciones
Por último, podemos encontrar muchas implementaciones diferentes. Por ejemplo, podemos encontrar dispositivos RTU que envíen datos de caudal remotamente desde varios kilómetros de distancia, pero también sistemas más locales conectados a un sistema SCADA.
Conclusión
Hay muchísimas implementaciones posibles de redes Modbus, cada una puede tener características muy diferentes que van a determinar su rendimiento. No olvides estos cuatro puntos 🙂
