Modbus, un protocolo consolidado estándar de facto
1979 Nacimiento de un estándar
En el mundo convulso de 1979, mientras se producía la invasión soviética de Afganistán y se iniciaba la revolución islámica de Irán, la empresa que desarrolló el primer PLC en 1968, Modicon, desarrolló un protocolo de comunicación para que los PLCs pudiesen comunicar con módulos adicionales en aplicaciones industriales.
Así en 1979 nació Modbus, un protocolo estándar, abierto y universal. A pesar que después surgieron un gran número de protocolos, modbus tiene la mayor aceptación en la automatización industrial debido a su simplicidad, que permite una implementación completa con un código mínimo en cualquier procesador.
Las especificaciones de este protocolo son mantenidas y actualizadas por modbus.org, una asociación global que asegura la interoperabilidad entre distintos fabricantes. Empresas como Ibercomp, miembro de esta asociación, participan activamente en su mejora y difusión.
Puede obtener toda la documentación acerca de este protocolo en: https://modbus.org/
RS485 es la opción más común para implementar Modbus debido a su capacidad para transmitir datos a largas distancias y conectar múltiples dispositivos en una sola red. Es un estándar robusto y fiable, capaz de operar en entornos industriales con altos niveles de ruido electromagnético.
Como anécdota, se realizó una instalación para la monitorización de agua subterránea en el Aeropuerto de Palma de Mallorca, utilizando hilos telefónicos abandonados de los años 70 y cables que pasaban por una bandeja de 30000V de las lámparas baliza de la pista. A pesar de las condiciones adversas, la red de 15 km funcionó durante muchos años sin problemas.
En otra ocasión, uno de nuestros clientes instaló un sistema en un hotel de 180 habitaciones con una estructura caótica y muchos empalmes. Utilizando un osciloscopio y resistencias terminadoras de distinto valor para anular los reflejos, una solución nada ortodoxa, que hizo que el sistema funcionara mas de 15 años.
Cableado Modbus RS485
Elección del cable adecuado
Para que el modbus funcione correctamente sobre RS485 es un requisito indispensable que los cables de datos estén trenzados. Una opción práctica y económica es usar cable Ethernet apantallado y flexible. El apantallado protege contra interferencias electromagnéticas, asegurando una señal más estable y una mejor integridad de los datos transmitidos.
Esté trenzado, ya que esto reduce las interferencias externas y las distorsiones electromagnéticas generadas por los mismos cables, dado que los campos magnéticos creados por las corrientes en direcciones opuestas se cancelan mutuamente.
Esta es clave para evitar problemas de comunicación en redes RS485 largas o con muchos dispositivos conectados.
Que sea flexible evita que se parta, con cables rígidos es muy fácil que se partan y esta avería pase desapercibida. Una instalación puede funcionar perfectamente con un cable rígido, pero un técnico no muy cuidadoso o las vibraciones acabarán por dañar el cable.
Cable de electricidad de 1.5mm2 sin trenzar en distancias largas probablemente de problemas. En este punto también hay que tener en consideración el material de los cables, no se pueden mezclar distintos metales como cobre y aluminio. Si se hace con la humedad habrá corrientes galvánicas que destruirán el metal más pobre.
Si puede utilizar cable de datos KNX, que también es trenzado sin problemas, aunque en la práctica, el cable más fino tiende a ofrecer mejores resultados. La razón es que el cable fino presenta menos capacitancia y menor susceptibilidad a interferencias, lo que ayuda a minimizar las distorsiones en las señales.
Asignación fácil de pares utilizando cable Ethernet
Para aprovechar los cables Ethernet en instalaciones RS485, recomendamos la siguiente distribución:
Par Azul para los datos:
◦ Azul conectado a la línea A.
◦ Blancoazul conectado a la línea B.
◦ (Fácil de recordar: «Azul» para «A» y «Blancoazul» para «B»).
Par Marrón para GND.
Marrón y blancomarrón conectados a GND, asegurando que todos los dispositivos estén conectados al mismo potencial de tierra.
Par Naranja para alimentación:
Si los dispositivos requieren alimentación de 12V o 24V y tienen bajo consumo, se puede utilizar el par naranja (naranja y blanconaranja).
Par Verde en reserva:
El par verde queda libre como reserva. Se recomienda no cortarlo y dejarlo enrollado en la instalación para usos futuros.
Conexión de la pantalla (malla)
La pantalla o malla del cable debe conectarse a GND en un solo extremo de la línea RS485, preferiblemente en el extremo mas cercano del equipo master. Es importante que no circule corriente por la malla, ya que su función es exclusivamente actuar como blindaje frente a interferencias.
También es importante destacar que la red Modbus debe ser una línea con un comienzo y un final. No se permite una configuración en estrella ni la existencia de bifurcaciones en la red. Solo se aceptan latiguillos o conexiones en T, con un máximo de 20 cm.
Limitaciones de la Red RS485
Los transceptores RS485 modernos pueden soportar más de 128 dispositivos conectados en una sola línea. Sin embargo, se recomienda limitar el número de dispositivos a alrededor de 40 por línea para evitar sobrecargar la red. A continuación damos algunas pautas:
Segmentación de la red:
Dividir la instalación en cuadros pequeños con su propia línea RS485 mejora la estabilidad y facilita el mantenimiento. Con los conversores Ethernet-RS485 de Ibercomp, puedes acceder a varias líneas RS485 en paralelo, permitiendo una gestión centralizada.
Patillaje de los transceptores:
Es importante revisar el patillaje de los transceptores RS485, como el 75176, donde la línea A está marcada como positiva (+) y la B como negativa (-). Algunos dispositivos pueden tener el etiquetado inverso, por lo que es crucial verificar que los positivos estén conectados con positivos y los negativos con negativos para asegurar una comunicación correcta.
Conversores de LoRa a RS485 para Conectar Equipos Modbus Lejanos:
En algunas instalaciones donde los equipos Modbus están ubicados a una distancia considerable y el cableado RS485 no es práctico, una solución efectiva es el uso de conversores de LoRa a RS485. LoRa (Long Range) es una tecnología de comunicación inalámbrica que permite la transmisión de datos a largas distancias con bajo consumo de energía.
Un ejemplo claro puede ser un sensor de luz ambiental en azotea que está aislado, no es práctico subir un cable por diez plantas. También puede ser el caso de un cuadro de piscina que esté distante edificio y no haya forma de pasar el cable.
LoRa tiene algunas limitaciones:
Es importante tener en cuenta que la velocidad de transmisión de datos mediante LoRa es relativamente lenta, típicamente alrededor de 1200 baudios. Aunque esta velocidad puede no ser adecuada para aplicaciones que requieran un alto intercambio de datos en tiempo real, es suficiente para muchas aplicaciones de monitoreo y control en las que los datos se actualizan con menor frecuencia.
Una solución por radio siempre es susceptible a interferencias, que se pierdan paquetes. La capa de red de los equipos LoRa intenta solucionar este problema, pero al estar utilizando frecuencias libres como 433MHz cualquiera puede pisar la frecuencia. LoRa además limita las ventanas de ocupación, por lo que no es conveniente hacer una lectura continua.
Robustez RS485
Los dispositivos más robustos incluyen una protección de tres niveles que garantiza una mayor durabilidad y resistencia ante las condiciones adversas comunes en instalaciones industriales. Esta protección incluye:
◦ TBU (Transient Blocking Unit): Protege contra sobrecorrientes, cortando el flujo de corriente cuando se excede un umbral predeterminado.
◦ TVS (Transient Voltage Suppressor): Actúa frente a sobretensiones, absorbiendo picos de voltaje transitorios como los generados por descargas electrostáticas (ESD) o relámpagos.
◦ Descargador de Gas: Protege contra sobretensiones extremas causadas por descargas atmosféricas o picos de alta energía, derivando la corriente peligrosa a tierra.
Estos tres niveles de protección trabajan en conjunto para proteger los transceptores y demás componentes sensibles de los dispositivos RS485, ofreciendo resistencia ante sobretensiones, sobrecorrientes y descargas electrostáticas.
Nuestros equipos industriales incluyen estas protecciones, y en nuevos diseños las integramos, pero si utiliza equipos que no disponen de protecciones de linea, es conveniénte que las añada.
Es frecuente que equipos que no disponen de protecciones ante una tormenta o subidas repentinas de tensión se dañen.
Localización de Averías en Instalaciones RS485
Para instalar y mantener una instalación RS485 es necesario adquirir destreza, hay que tener en cuenta que si se daña un transceptor, hay un cortocircuito o se rompe un cable deja de comunicar toda la línea. A veces las averías o fallos son muy extraños, como es el caso de una instalación de un cliente en un hotel de 330 habitaciones, que funcionaba correctamente pero a ratos dejaban de comunicar 40 habitaciones. Revisando habitaciones una por una funcionaban correctamente, pero revisando cuadro por cuadro descubrimos que por error el electricista había conectado la salida de datos de un sensor PIR NPN a una de las líneas de datos del bus. Cuando alguien entraba en el baño de esa habitación, toda la linea dejaba de funcionar. La habitación estaba desocupada y se usaba como trastero, de modo que el baño daba presencia de peras a uvas.
Cuando una red RS485 presenta fallos de comunicación, es importante contar con las herramientas adecuadas para diagnosticar el problema de manera eficiente. A continuación, se describen algunos métodos y recomendaciones para identificar y resolver problemas en la red.
Uso del osciloscopio para verificar la línea
Los osciloscopios portátiles son herramientas ideales para comprobar si la señal de datos en las líneas A y B es correcta. Estos dispositivos se pueden adquirir por menos de 50€ en comercios online, y cualquiera de ellos será útil para esta tarea.
Para poder comprobar el estado de una línea se debe conectar la pinza del osciloscopio a GND y verificar las señales en las líneas A y B. Las señales deberían aparecer como ondas cuadradas que transiten entre 0V y 3.3V aproximadamente.
Si la transición no es limpia y se ve una señal retardada más tenue es que hay un reflejo y es necesario una resistencia terminadora en algún extremo. Recomendamos jugar con resistencias de distintos valores, empezando por 1K, 470Ohms, 270Ohms, 180Ohms hasta 120Ohms. Cuanto más grande la resistencia menos se atenuará la señal principal.
Si las señales están atenuadas, esto podría indicar un corto en algún transceptor o en un cable. En ese caso, es recomendable revisar los transceptores uno por uno, ya que puede ser la causa del fallo.
Alternativas sin osciloscopio
Si no dispone de un osciloscopio, puedes utilizar un tester true RMS o incluso un tester en modo alterna para medir el nivel de las señales. Aunque menos preciso, estos instrumentos pueden ayudar a verificar si el nivel de señal es bajo, lo cual puede indicar problemas en la comunicación.
Aquí podemos conectar el tester en modo alterna a las líneas A y B para comprobar que se observe una señal, aunque sea baja. Esto puede dar una indicación de si la señal está presente o si hay un problema significativo en la red. Una tensión normal suele estar por encima de los 3V cuando hay transmisión de datos más o menos continua.
Otra alternativa, cuando hay escasez de medios, es utilizar una pila de petaca y una bombilla en serie. Del positivo va a la bombilla, y de esta a la señal A. La señal B va conectada al negativo es decir al B. Para esta prueba es mejor que no se estén transmitiéndo datos. En el otro lado de la línea debe haber 4.5V y la bombilla debe estar siempre apagada. Si está encendida es que hay cortocircuito y si no hay 4.5V es que .
Método para identificar fallos en instalaciones grandes
Utlizando la técnica de busqueda binaria, en instalaciones grandes, como las de un pasillo de habitaciones en un hotel, no siempre es lo más adecuado molestar a 40 clientes abriendo cuadros para realizar una comprobación. Lo más aconsejable es dividir la línea para identificar el punto de fallo, siguiendo una serie de pasos:
◦ Abrir la línea en el primer equipo: Comienza desconectando la línea en el primer dispositivo de la serie. Asegúrate de que el primer equipo se comunique correctamente. Si lo hace, procede al siguiente paso.
◦ Dividir la línea por mitades: Si el primer equipo comunica bien pero el fallo persiste, divide la línea en dos mitades. Comprueba si la primera mitad funciona correctamente.
Logaritmo binario: Continuando con este enfoque, cada vez que la mitad de la línea funcione, continúa dividiendo el resto. En log 2 (n) veces, podrás aislar el problema. Este método es eficiente, especialmente en redes grandes.
Problemas comunes y cómo resolverlos
◦ Señal atenuada con la distancia: Es normal que la señal se debilite con la distancia en líneas largas. Si algunos equipos comunican intermitentemente o dejan de hacerlo, puede ser debido a la atenuación. Revisa si la red se extiende demasiado sin refuerzos de señal o si los transceptores están sobrecargados. Considera el uso de repetidores o amplificadores de señal si la distancia es considerable.
◦ Corte en los cables de datos: Si la comunicación funciona bien hasta cierto punto y luego no hay señal, es posible que uno de los cables de datos esté cortado. Revisa la integridad de los cables para asegurarte de que no haya discontinuidades. Usa herramientas como un tester de cable para identificar posibles cortocircuitos o fallos en la continuidad.
◦ Equipos con transceptores dañados: Un transceptor dañado puede consumir más corriente de la que el sistema de alimentación puede proporcionar, lo que podría provocar que la fuente de alimentación se corte o se sobrecargue. Si un equipo está fallando, comprueba si su transceptor está en buen estado y reemplázalo si es necesario. Asegúrate de que la fuente de alimentación sea capaz de soportar el consumo de todos los dispositivos conectados.
Con un poco de ingenio y paciencia, la mayoría de los problemas en una red RS485 se pueden resolver sin mayores complicaciones. Además, en los equipos de Ibercomp, siempre que sea posible, los transceptores están montados en zócalos para que su sustitución sea rápida y sencilla en caso de avería. Otros fabricantes sueldan los transceptores. También es posible que se dañen las protecciones y aparenten un cortocircuito.
Software para la Gestión de Redes Modbus.
La mayoría de los sistemas SCADA y HMI actuales incluyen librerías que soportan el protocolo Modbus de manera nativa, lo que facilita la integración y la comunicación con los dispositivos. Si trabajas con plataformas de software abiertas, como NodeRED, tampoco es necesario preocuparse demasiado por la gestión del protocolo Modbus, ya que suelen tener módulos preconstruidos que se encargan de esa tarea.
En Ibercomp, también proporcionamos nuestras propias librerías completamente testeadas en JAVA, diseñadas para garantizar una implementación robusta y eficiente de Modbus en diversos entornos. Sin embargo, hemos identificado un error común en algunos de nuestros clientes que desarrollan software para redes Modbus: crean aplicaciones monolíticas donde, para cada ciclo, se accede a un registro Modbus, se toma una decisión, se actualiza la interfaz gráfica, etc. Esto tiende a ralentizar el rendimiento de la aplicación.
Para testear nuestros equipos ofrecemos en código abierto la aplicación modbusTest, y también podrá encontrar programas válidos para testear en modbus.org.
La solución óptima es estructurar el software en capas y utilizar aplicaciones multihilo. Cada hilo debería encargarse de gestionar la lectura de una pasarela Modbus, copiando los datos constantemente a la memoria (ya sea a través de arrays, un servidor MQTT o una base de datos en RAM como MariaDB). De este modo, las decisiones y las actualizaciones en la interfaz gráfica se realizan directamente desde la memoria, mientras que los cambios en la instalación se actualizan mediante disparadores que envían los comandos a los dispositivos Modbus.
Es importante evitar las esperas activas, ya que solo consumen recursos del procesador sin mejorar la eficiencia. Si una aplicación de control Modbus consume el 100% de la capacidad del CPU, es probable que esté mal diseñada. Un uso elevado de CPU genera calor, lo que puede incrementar la probabilidad de fallos en el sistema.
Nosotros hemos desarrollado aplicaciones capaces de gestionar hasta 70,000 variables Modbus con un consumo de CPU de apenas el 6% y tiempos de refresco inferiores a los 2 segundos. Aunque es posible mejorar aún más los tiempos de respuesta, lograr más de 10 actualizaciones por segundo se vuelve poco realista cuando hay una gran cantidad de dispositivos conectados.
