5.1. Evolución del RS-485 al Modbus TCP

UF1794 | Del cable serie a la red Ethernet industrial

graph TD subgraph Modbus_RTU ["Modbus RTU sobre RS-485"] M["Maestro"] --"Polling Secuencial"--> S1["Esclavo 1"] M --"Polling Secuencial"--> S2["Esclavo 2"] M --"Polling Secuencial"--> S3["Esclavo 3"] end subgraph Modbus_TCP ["Modbus TCP sobre Ethernet"] SW[("Switch Ethernet")] C1["Cliente 1"] --> SW C2["Cliente 2"] --> SW SRV["Servidor (PLC)"] <--> SW end Modbus_RTU --"Encapsulación
en TCP/IP"--> Modbus_TCP style M fill:#c0392b,color:white style SRV fill:#2980b9,color:white style SW fill:#2c3e50,color:white

1. El Reinado del RS-485 y Modbus RTU

Antes de la llegada de Ethernet a la planta, el protocolo de comunicación más universal y robusto era Modbus RTU, que operaba sobre una capa física RS-485. Para un técnico de automatización (UF1794), es crucial entender sus fundamentos, ya que miles de dispositivos "legacy" siguen utilizándolo.

  • Capa Física (RS-485): Es un bus serie que utiliza un par de cables trenzados. Permite conectar hasta 32 dispositivos en una topología de "Daisy-Chain" (línea) a lo largo de cientos de metros. Es Half-Duplex, lo que significa que solo un dispositivo puede "hablar" a la vez.
  • Capa Lógica (Modbus RTU): Sigue un estricto modelo Maestro-Esclavo. Solo puede haber un Maestro en el bus. El Maestro interroga (hace "polling") a cada Esclavo de forma secuencial: "Esclavo 1, dame tu temperatura", espera la respuesta, "Esclavo 2, dame tu presión", espera la respuesta, y así sucesivamente.
  • Limitaciones: Este modelo es lento, no permite que varios maestros consulten datos simultáneamente y es muy sensible a errores de cableado y ruido eléctrico.


2. Modbus TCP: La Encapsulación Inteligente

Con la llegada de Ethernet, en lugar de inventar un protocolo nuevo, la industria optó por una solución brillante: tomar el "corazón" de Modbus RTU y "envolverlo" o encapsularlo dentro de un paquete TCP/IP estándar. Así nació Modbus TCP.

La idea es simple: la parte de datos del mensaje Modbus (llamada PDU - Protocol Data Unit) es idéntica en RTU y en TCP. Lo único que cambia es el "sobre" que la transporta. Modbus TCP utiliza el puerto estándar 502 y reemplaza el modelo Maestro-Esclavo por el modelo Cliente-Servidor, mucho más flexible, donde múltiples Clientes (SCADAs, HMIs) pueden consultar a un mismo Servidor (PLC) de forma simultánea.



3. El Encabezado MBAP (Modbus Application Protocol)

Para que esta encapsulación funcione, Modbus TCP añade una pequeña cabecera de 7 bytes al principio del paquete, llamada MBAP Header. Esta cabecera es el "traductor" entre el mundo Modbus y el mundo TCP/IP.

  • Transaction ID (2 bytes): Un número de secuencia. Permite a un Cliente enviar múltiples peticiones sin esperar la respuesta de la anterior. El Servidor incluirá este mismo ID en su respuesta, para que el Cliente sepa a qué pregunta corresponde.
  • Protocol ID (2 bytes): Siempre es 0 para Modbus.
  • Length (2 bytes): Indica cuántos bytes de datos vienen a continuación.
  • Unit ID (1 byte): Este es el campo más importante para la integración. Actúa como el antiguo "ID de Esclavo". Permite que un único dispositivo con una IP (un Gateway Modbus TCP) actúe como pasarela para toda una red de dispositivos Modbus RTU serie. El Cliente TCP envía la petición a la IP del Gateway, pero pone en el Unit ID el número del esclavo final al que quiere llegar.

Es importante destacar que Modbus TCP elimina el campo CRC que era vital en Modbus RTU. La razón es que la capa TCP ya se encarga de forma nativa y mucho más robusta de la detección y corrección de errores, por lo que el CRC se vuelve redundante.

ANATOMÍA DE LA TRAMA: MODBUS RTU vs. MODBUS TCP Modbus RTU (Serie RS-485) Slave ID PDU (Function Code + Data) CRC Check Modbus TCP (Ethernet) Ethernet IP TCP MBAP Header PDU (Function Code + Data) El PDU se mantiene intacto
Figura 1: Encapsulación de Modbus. La unidad de datos del protocolo (PDU), que contiene el código de función y los datos, es idéntica en ambas versiones. Modbus TCP simplemente coge esa PDU, le antepone la cabecera MBAP y la envuelve en las capas TCP/IP y Ethernet para su transporte por la red.
Fuente: Elaboración Propia. Licencia: CC BY-SA 4.0.

🎥 Formación Técnica: Modbus RTU vs. Modbus TCP

Comprende visualmente las diferencias físicas y lógicas entre el bus serie y la red Ethernet, y por qué el MBAP Header es la clave para la integración de sistemas modernos y antiguos.

▶ Ver Comparativa en YouTube

📝 Evaluación Técnica: Evolución de Protocolos

1. ¿Cuál es la principal diferencia en el modelo de comunicación entre Modbus RTU y Modbus TCP?

2. En Modbus TCP, ¿qué función cumple la cabecera MBAP (Modbus Application Protocol)?

3. Un Gateway Modbus TCP tiene la IP 192.168.1.100 y está conectado a una línea serie RS-485 con 5 variadores (esclavos RTU con IDs del 1 al 5). Si un cliente SCADA quiere leer la velocidad del variador con ID=3, ¿cómo lo hace?

🤖 Ejercicio Práctico 5: Cliente Modbus TCP en Python

Objetivo: Crear un cliente Modbus TCP funcional para leer datos de un dispositivo real o simulado, entendiendo la simplicidad y potencia del protocolo.

Copia el siguiente *prompt* y pégalo en un modelo de IA (como ChatGPT, Gemini o Claude).

Actúa como un ingeniero de control y automatización. Escribe un script en Python que utilice la librería `pyModbusTCP` para funcionar como un cliente Modbus TCP. El script debe: 1. Importar la clase `ModbusClient`. 2. Configurar la IP del servidor y el puerto (usa 'localhost' y 502 para pruebas locales). 3. Instanciar el cliente y intentar conectarse. 4. Si la conexión es exitosa, leer 1 'holding register' desde la dirección 0. 5. Imprimir el resultado de la lectura o un mensaje de error si la lectura falla. 6. Asegurarse de cerrar la conexión al final. Comenta el código explicando cómo este simple script podría usarse para monitorizar la temperatura de un sensor o el estado de un PLC en una fábrica real.