Protocolo Modbus: RTU, TCP y direccionamiento de registros

Modbus es un protocolo de comunicación cliente/servidor para leer y escribir bobinas y registros. RTU y ASCII utilizan tramas serie; Modbus TCP utiliza TCP/IP. Antes de configurar la conexión, compruebe el mapa de registros del dispositivo y la convención de direcciones del cliente.

En una modernización, un controlador puede ofrecer Modbus RTU por una línea serie mientras el sistema de supervisión espera Modbus TCP. Que ambos extremos indiquen «Modbus» no garantiza que una pasarela convierta las tramas ni aclara qué dirección corresponde a una referencia de registro.

Esta guía separa el modelo de datos, el transporte y el formato de los mensajes. Compara RTU, ASCII y TCP, y explica por qué una referencia como 40001 no siempre es la dirección que debe introducirse en el cliente. La última sección ayuda a preparar un pequeño mapa antes de configurar la conexión.

Empezar por el modelo de datos

Modbus define peticiones y respuestas entre un cliente y un servidor. El protocolo de aplicación organiza los datos en cuatro grupos:

Grupo de datos	Unidad	Acceso habitual
Coils (bobinas)	Bits individuales	Lectura y escritura
Discrete Inputs (entradas discretas)	Bits individuales	Lectura
Input Registers (registros de entrada)	Palabras de 16 bits	Lectura
Holding Registers (registros de retención)	Palabras de 16 bits	Lectura y escritura

Los códigos de función especifican operaciones como leer bobinas o registros y escribir valores. Un dispositivo puede implementar solo una parte de esas funciones. Su manual proporciona el mapa particular: funciones admitidas, significado de cada dirección, permiso de escritura y codificación de los valores.

Un registro de 16 bits no define por sí mismo el significado de una magnitud.

Un número mayor puede ocupar varios registros. El signo, el orden de bytes y palabras, la escala y la unidad deben obtenerse del manual y anotarse junto a la referencia del registro.

La especificación del protocolo de aplicación Modbus define el modelo de datos y los códigos de función, pero no el mapa de registros de un producto concreto.

RTU, ASCII y TCP usan tramas diferentes

RTU y ASCII son formatos de mensajes serie. Modbus TCP transporta la petición de aplicación por TCP/IP y añade una cabecera distinta. RS-485 es una capa física frecuente para Modbus serie; no es, por sí sola, un formato de mensaje Modbus.

Variante	Trama	Datos que conviene confirmar
Modbus RTU	Trama serie binaria con dirección de dispositivo, código de función, datos y CRC	Interfaz serie, dirección del dispositivo, velocidad, paridad, bits de parada y tiempos requeridos
Modbus ASCII	Trama serie con datos hexadecimales codificados como caracteres ASCII, carácter inicial, LRC y terminación de línea	Si el dispositivo admite ASCII y qué parámetros serie necesita
Modbus TCP	Petición de aplicación en un mensaje TCP con cabecera MBAP	IP del servidor, puerto TCP, roles cliente/servidor y posible uso del Unit Identifier para seleccionar un dispositivo aguas abajo

La guía de Modbus sobre línea serie describe las tramas RTU y ASCII. La guía de Modbus TCP/IP explica la cabecera MBAP. El puerto TCP 502 es habitual, pero debe confirmarse el puerto configurado en el equipo.

Los códigos de función y el modelo de datos pueden ser familiares en las distintas variantes; las tramas no son intercambiables. Un cliente serie no puede enviar directamente una trama RTU a un servidor TCP y esperar una conversión automática. Se necesita una pasarela o un modo de dispositivo diseñado para ello.

Distinguir la referencia del registro de la dirección solicitada

Los manuales y programas de ingeniería suelen mostrar referencias como 00001, 10001, 30001 y 40001. Estos rótulos normalmente indican un grupo de datos y un número de registro legible para las personas. La petición Modbus incluye un campo de dirección numérica; el rótulo mostrado no tiene por qué ser el número que espera el cliente.

Por ejemplo, 40001 suele identificar el primer holding register, mientras que la dirección de petición correspondiente suele ser cero. Es una convención extendida, no una regla segura para todos los manuales, controladores y pasarelas. Algunas herramientas piden la referencia completa; otras, un desplazamiento basado en cero o una dirección basada en uno.

Antes de configurar una lectura, registre:

• El grupo de datos: coil, discrete input, input register o holding register.

• El código de función que requiere el dispositivo.

• La referencia exacta indicada en el manual.

• La dirección o el desplazamiento que espera el software cliente.

• El tipo de valor, signo, orden de bytes y palabras, escala y unidad.

No reste uno a todas las direcciones por costumbre. Compare el ejemplo del manual con la convención del cliente o la pasarela y verifique después un valor conocido de solo lectura. El campo de dirección y los códigos de función se definen en la especificación Modbus.

Separar el enrutamiento IP de la conversión de protocolo

Un router IP reenvía tráfico entre interfaces de red. Eso no significa que lea registros Modbus ni convierta una trama serie RTU en una petición Modbus TCP. La conversión ocurre en la capa de aplicación y requiere una pasarela o un modo de funcionamiento preparado para ella. La RFC 1812 describe las funciones de reenvío de un router IPv4.

La distinción importa cuando un PLC está conectado por serie, pero el cliente de supervisión reside en una red IP. Un servidor serie puede transportar bytes serie por una conexión IP sin modificar el protocolo serie. Una pasarela de protocolo, en cambio, puede terminar una variante Modbus y generar peticiones en otra.

Confirme qué modo se utiliza, dónde se realiza la consulta y cómo se asignan los identificadores de dispositivo y los registros. Las expresiones «router industrial» y «compatible con Modbus» no bastan para afirmar que exista una interfaz serie o una función de conversión. Consulte el manual del modelo y firmware concretos.

Preparar un pequeño mapa Modbus antes de la puesta en marcha

Antes de configurar, documente en una página los dispositivos y puntos necesarios:

Elemento	Qué registrar
Extremo	Modelo, firmware y función de cliente o servidor
Variante	RTU, ASCII o TCP
Enlace	Parámetros serie y dirección de dispositivo, o dirección IP y puerto TCP configurado
Punto de datos	Grupo, código de función, referencia del manual y dirección/desplazamiento del cliente
Interpretación	Tipo de dato, signo, orden de bytes/palabras, escala y unidad
Acceso	Solo lectura o escritura permitida según el manual

Empiece por un punto documentado de solo lectura. Compruebe la respuesta y el valor interpretado antes de añadir más puntos o permitir escrituras. Si llega una respuesta pero el valor mostrado es incorrecto, revise primero el mapa y la representación del dato antes de cambiar la ruta de red.

Si un valor del PLC, variador o SCADA no llega o queda desactualizado, siga la guía de diagnóstico PLC/Modbus.

Preguntas frecuentes

¿Son Modbus RTU y Modbus TCP el mismo protocolo?

Comparten el modelo de datos de aplicación y códigos de función relacionados, pero difieren en el formato de trama y el transporte. RTU usa una trama serie; Modbus TCP añade una cabecera MBAP y circula por TCP/IP.

¿El registro 40001 corresponde siempre a la dirección cero?

No. 40001 suele designar el primer holding register, representado con frecuencia por la dirección cero en una petición. Los manuales, controladores y pasarelas pueden mostrar o aceptar direcciones de otra manera. Compruebe las convenciones del dispositivo y del cliente.

¿Puede un router industrial corriente convertir Modbus RTU a Modbus TCP?

No de forma automática. El enrutamiento IP y la conversión Modbus son funciones distintas. El equipo concreto debe disponer de un modo de pasarela o conversión, y su manual debe explicar cómo asocia el dispositivo serie y las peticiones de registros.

¿Qué datos hacen falta para investigar un problema de conexión Modbus?

Facilite el dispositivo y firmware, la variante RTU/ASCII/TCP, los roles cliente/servidor, los ajustes serie o IP, el identificador del dispositivo, el mapa de registros, el código de función solicitado, la convención de direcciones y la codificación del valor. Incluya una captura breve de petición y respuesta si el equipo lo permite.