Modbus: el protocolo industrial que lleva más de 40 años vivo
Modbus nació en 1979, de la mano de Modicon (hoy Schneider Electric), como un protocolo de comunicación simple para sus propios PLC. Cuatro décadas después sigue siendo uno de los protocolos más usados en la industria, y no por inercia: es abierto y gratuito (sin licencias ni royalties), tiene un modelo de datos extremadamente simple (bobinas, entradas discretas, registros de entrada y registros holding) y prácticamente todos los fabricantes de variadores, analizadores de red, contadores de energía y sensores industriales lo implementan de serie. Esa combinación de simplicidad y adopción universal es la razón de que siga siendo, hoy, el mínimo común denominador para integrar equipos de fabricantes distintos.
Lo que confunde a muchos ingenieros que empiezan es que "Modbus" en realidad son dos protocolos distintos que comparten modelo de datos pero no capa física ni forma de transportar los mensajes: Modbus RTU y Modbus TCP.
Modbus RTU: comunicación serie maestro-esclavo
Modbus RTU circula sobre una línea serie, normalmente RS-485 (dos hilos, multipunto, hasta 32 dispositivos por segmento sin repetidor) o RS-232 (punto a punto). Es una arquitectura estrictamente maestro-esclavo: un único maestro pregunta y hasta 247 esclavos, cada uno con una dirección única de 1 a 247, responden solo cuando se les pregunta directamente. No existe comunicación esclavo-esclavo ni un esclavo puede iniciar una transmisión por iniciativa propia.
Las velocidades típicas van de 9600 a 115200 baudios, y el formato de trama es binario y compacto, con verificación de errores mediante CRC. Es la opción natural para dispositivos de campo económicos —sondas de temperatura, variadores de gama básica, contadores de energía— donde no compensa el coste de una interfaz Ethernet, y para instalaciones donde el cableado ya existe en RS-485 y no tiene sentido sustituirlo.
Modbus TCP: el mismo modelo de datos sobre Ethernet
Modbus TCP encapsula exactamente el mismo modelo de datos —las mismas bobinas y registros— dentro de un paquete TCP/IP estándar, normalmente por el puerto 502. Al apoyarse en Ethernet hereda sus ventajas: velocidades muy superiores, cableado estructurado con switches en lugar de un bus serie compartido, y la posibilidad de que varios clientes (un SCADA, un HMI y un PLC, por ejemplo) lean el mismo dispositivo simultáneamente, algo que Modbus RTU no permite de forma nativa al tener un único maestro por segmento.
La contrapartida es que cada dispositivo necesita una interfaz Ethernet, lo que en equipos muy sencillos o de gama muy económica puede no estar disponible o encarecer el componente de forma notable.
RTU frente a TCP, punto por punto
| Aspecto | Modbus RTU | Modbus TCP |
|---|---|---|
| Capa física | RS-485 / RS-232 (serie) | Ethernet |
| Direccionamiento | ID de esclavo (1-247) | Dirección IP + Unit ID opcional |
| Maestros simultáneos | Uno por segmento | Varios clientes a la vez |
| Velocidad típica | 9600 – 115200 baudios | 10/100/1000 Mbps |
| Cableado | Par trenzado, bus multipunto | Cable de red, topología en estrella con switches |
| Coste por dispositivo | Bajo | Medio (requiere interfaz Ethernet) |
Pasarelas Modbus RTU/TCP: mismo idioma, distinta capa física
Cuando un proyecto necesita incorporar dispositivos de campo antiguos —una sonda RS-485, un contador de energía heredado— dentro de una arquitectura moderna basada en Ethernet, la solución habitual es una pasarela Modbus RTU/TCP: un pequeño gateway que expone hacia la red TCP los mismos registros que el dispositivo serie ofrece hacia su bus RS-485, traduciendo entre ambos formatos de forma transparente para el maestro. Esta es exactamente la lógica que aplicamos en el sistema multiprotocolo que describimos en nuestro artículo sobre BMS con PLC Wago, donde inversores fotovoltaicos y analizadores de red conviven en la misma arquitectura sin importar si hablan RTU o TCP de origen.
Errores comunes al mezclar RTU y TCP en el mismo proyecto
La mayoría de incidencias en proyectos con Modbus no vienen del protocolo en sí, sino de detalles de implementación que varían entre fabricantes:
- Direccionamiento de registros con offset distinto: algunos fabricantes numeran los registros desde 0 y otros desde 1 en su documentación, lo que provoca leer el registro equivocado si no se verifica contra el manual del dispositivo concreto.
- Terminación de línea incorrecta en RS-485: olvidar las resistencias de terminación de 120 ohmios en los extremos del bus provoca reflexiones y errores de comunicación intermitentes, especialmente en buses largos.
- Timeouts mal ajustados al mezclar RTU y TCP tras una pasarela: un maestro TCP que espera una respuesta tan rápida como la de un dispositivo Ethernet nativo puede dar por perdido a un esclavo RTU que simplemente tarda más en responder por el bus serie.
- Exceder la longitud máxima de bus o el número de esclavos sin añadir un repetidor RS-485, lo que degrada la señal de forma progresiva y difícil de diagnosticar.
- Confundir el Unit ID en TCP puro: cuando no hay pasarela de por medio, muchos dispositivos Modbus TCP ignoran el Unit ID y basta con la IP; asumir que hace falta un ID de esclavo sin comprobarlo genera errores de configuración innecesarios.
Cuándo elegir RTU y cuándo elegir TCP
La decisión rara vez es una cuestión de preferencia, sino del contexto del proyecto. Modbus RTU tiene sentido para sensores y actuadores de bajo coste, instalaciones remotas con poco ancho de banda disponible o cableado RS-485 ya existente, y cuadros pequeños con pocos dispositivos donde no compensa una interfaz Ethernet por unidad. Modbus TCP es la opción natural cuando el proyecto crece —muchos dispositivos, varias líneas—, cuando varios sistemas necesitan leer el mismo dato a la vez (un SCADA y un PLC consultando el mismo analizador de red, por ejemplo), o cuando la instalación ya usa Ethernet industrial como columna vertebral y añadir un dispositivo Modbus TCP más es trivial.
Cómo encaja Modbus en una arquitectura moderna
Modbus sigue viviendo en la capa de campo, cerca del sensor y el actuador, mientras que protocolos más recientes como OPC UA o MQTT operan en la capa de integración, hacia el SCADA, el IIoT o el ERP. En la práctica, la mayoría de proyectos combinan ambos niveles: los dispositivos de campo hablan Modbus (RTU o TCP según el caso) y un PLC o gateway agrega esos datos y los expone hacia arriba en un protocolo más moderno, sin que eso implique sustituir Modbus en el nivel donde sigue siendo la opción más simple y fiable.
Cómo lo trabajamos en Bluemation
En Bluemation decidimos entre RTU y TCP —o entre mezclar ambos con una pasarela— en función del proyecto concreto, no de una preferencia por defecto: evaluamos el número de dispositivos, la distancia, el cableado existente y qué otros sistemas necesitan acceder a los mismos datos. Esta decisión forma parte de cualquier proyecto de programación de PLC o de integración de protocolos industriales que abordamos.
Si tienes dispositivos de fabricantes distintos que necesitas integrar en una misma arquitectura, con independencia del protocolo con el que hablen de origen, consulta nuestro servicio de programación de PLC o ponte en contacto con nosotros. Te ayudamos a definir la arquitectura de comunicaciones antes de comprar el primer equipo.