Guía completa de Modbus RTU para ingenieros de campo

Cuatro décadas después de su publicación, Modbus RTU sigue presente en tableros nuevos, retrofits de subestación y líneas de manufactura recién puestas en servicio. La pregunta razonable en 2026 es por qué un protocolo serie, sin seguridad nativa y con un modelo de datos de 16 bits aún compite con OPC UA, MQTT Sparkplug y variantes industriales sobre TCP. La respuesta es práctica: existe una base instalada de cientos de millones de dispositivos que hablan Modbus RTU, la especificación es abierta y estable desde 1996, cualquier microcontrolador de 8 bits implementa la pila en unos pocos kilobytes y el costo de un transceptor RS-485 se ubica por debajo de un dólar. Esta guía consolida lo que un ingeniero de campo necesita para integrar, depurar y documentar un enlace Modbus RTU con calidad industrial. El foco es el frame binario, los tipos de datos, el mapeo real de un dispositivo, la comparación con TCP, el tratamiento de excepciones y las trampas de capa física que aparecen en obras reales.

Qué es Modbus RTU

Modbus fue publicado por Modicon en 1979 como lenguaje de comunicación entre el PLC 084 y periféricos remotos. La variante RTU (Remote Terminal Unit) es la codificación binaria del protocolo sobre una línea serie asíncrona, en contraste con Modbus ASCII (caracteres hexadecimales legibles, con un overhead aproximadamente duplicado) y Modbus TCP (encapsulado en sockets IP, sin CRC). La especificación actual es mantenida por la Modbus Organization y referenciada en normas como la IEC 61158 (familia de fieldbus industriales), que cataloga a Modbus como Type 15.

La capa física típica es EIA/TIA-485 (frecuentemente llamada RS-485): diferencial, half-duplex, multidrop, con hasta 32 cargas unitarias por segmento sin repetidor. También es posible operar Modbus RTU sobre RS-232 punto a punto, aunque es poco habitual en instalaciones nuevas. El modelo es estrictamente cliente/servidor: existe un único cliente (anteriormente llamado "master") que inicia transacciones, y hasta 247 servidores ("slaves") direccionables en el mismo bus. Los servidores nunca hablan espontáneamente; solo responden a la dirección unicast dirigida a ellos o procesan en silencio solicitudes broadcast en la dirección 0.

La velocidad de transmisión usual cubre 4800, 9600, 19200, 38400, 57600 y 115200 bps. La especificación obliga al soporte de 9600 y 19200 bps; las demás son opcionales. El formato de carácter estándar es de 11 bits: 1 start, 8 datos, 1 paridad par, 1 stop. Cuando la paridad está deshabilitada, dos stop bits son obligatorios para preservar el tiempo total del carácter.

Frame Modbus RTU

El frame RTU está delimitado por silencio en la línea, no por caracteres especiales. La especificación define que el intervalo entre dos frames consecutivos sea de al menos 3,5 tiempos de carácter (t3,5) y que el intervalo entre dos caracteres dentro del mismo frame no supere 1,5 tiempos de carácter (t1,5). Para velocidades superiores a 19200 bps, estos tiempos se fijan en 1750 µs y 750 µs, respectivamente, por recomendación de la especificación.

La estructura del frame es:

Campo	Tamaño (bytes)	Contenido
Dirección	1	0 (broadcast) o 1–247 (unicast); 248–255 reservado
Function code	1	Código de la operación solicitada
Datos	0–252	Parámetros de la función (direcciones, cantidades, valores)
CRC-16	2	Polinomio 0xA001, low byte primero

El tamaño máximo del PDU (Protocol Data Unit) es de 253 bytes, lo que lleva al frame ADU (Application Data Unit) RTU a un máximo de 256 bytes considerando dirección y CRC. El CRC se calcula sobre dirección, function code y datos; el registro se inicia en 0xFFFF y usa el polinomio inverso 0xA001. Las implementaciones por tabla de 256 entradas resuelven el cálculo en microsegundos incluso en MCUs modestos.

Los cuatro function codes más usados en campo son:

• 0x03 Read Holding Registers: lee de 1 a 125 holding registers consecutivos. Es la operación dominante en sistemas SCADA.
• 0x04 Read Input Registers: lee de 1 a 125 input registers (solo lectura) consecutivos. Se usa para magnitudes medidas en tiempo real.
• 0x06 Write Single Register: escribe un valor de 16 bits en un único holding register. Útil para comandos y setpoints individuales.
• 0x10 Write Multiple Registers: escribe de 1 a 123 holding registers en una sola transacción. Indispensable para configurar bloques parametrizables.

También existen 0x01/0x02 para coils y discrete inputs, 0x05 para coil único, 0x0F para múltiples coils, 0x17 (read/write multiple), 0x16 (mask write) y 0x2B (read device identification). La función 0x08 (diagnostics) es útil para sondear la salud del enlace, pero el soporte varía según el fabricante.

Tipos de datos Modbus

El modelo de datos original de Modbus refleja la memoria del PLC 984 de Modicon, con cuatro tablas distintas. La confusión clásica entre "dirección lógica" (1-based, con prefijos 0/1/3/4) y "dirección de protocolo" (0-based, transmitida en el frame) es una fuente permanente de error en integraciones.

Tabla	Acceso	Tamaño	Dirección lógica	Dirección de protocolo	Function codes
Coils	Lectura/escritura	1 bit	00001–09999	0x0000–0x270E	0x01, 0x05, 0x0F
Discrete inputs	Solo lectura	1 bit	10001–19999	0x0000–0x270E	0x02
Input registers	Solo lectura	16 bits	30001–39999	0x0000–0x270E	0x04
Holding registers	Lectura/escritura	16 bits	40001–49999	0x0000–0x270E	0x03, 0x06, 0x10, 0x16

Los valores de 32 bits (float, int32, contadores de energía) se almacenan en dos holding registers contiguos. El orden de los bytes y de los registros varía entre fabricantes: ABCD (big-endian puro), CDAB (word swap), BADC (byte swap) y DCBA (full reverse). Documentar este orden es tan importante como documentar la dirección; las integraciones que fallan solo con valores grandes casi siempre tienen el swap equivocado.

Cómo mapear un dispositivo real

La documentación del mapa de registros es el activo de integración más importante de cualquier equipo Modbus. Como ejemplo práctico, considere el AEM-60DC8, monitor industrial de tensión DC de 8 canales, que en la versión de firmware v1.03 expone un total de 147 holding registers organizados en 17 bloques funcionales.

El recorte que sigue es un ejemplo simplificado con fines didácticos; el mapa autoritativo es el anexo B del manual técnico del producto:

Bloque	Rango (hex)	Registros	Tipo	Observación
Tensión CH1–CH8 (instantánea)	0x0000–0x0007	8	int16	Valor en mV, signed
Tensión CH1–CH8 (promedio 1 s)	0x0008–0x000F	8	int16	Ventana móvil de 1 segundo
Estado de alarma global	0x0100	1	bitfield	El bit i indica el canal i en violación
Límites superiores CH1–CH8	0x0110–0x0117	8	int16	Escritura habilitada
Límites inferiores CH1–CH8	0x0118–0x011F	8	int16	Escritura habilitada
Contadores de eventos	0x0200–0x020F	16	uint16	2 contadores por canal
Identificación y firmware	0x0F00–0x0F0F	16	ASCII/u16	Incluye versión v1.03

Buenas prácticas al publicar un mapa: indicar la unidad física, la escala (multiplicador y offset), el rango válido, el valor de "dato inválido" (típicamente 0x8000 para int16) y si el registro es volátil o persistente. Para quien lee el mapa, lo que importa es el contrato — no la estructura interna del firmware.

Modbus RTU vs Modbus TCP

La elección entre RTU y TCP rara vez es estética; depende de la topología, la latencia aceptada y la infraestructura existente.

Criterio	Modbus RTU	Modbus TCP
Capa física	RS-485 o RS-232	Ethernet 10/100/1000 Mbps
Topología	Multidrop (hasta 32 nodos sin repetidor)	Estrella vía switch
Direccionamiento	1 byte (1–247)	IP + Unit Identifier
Integridad	CRC-16	Checksum TCP (sin CRC Modbus)
Encuadre	Por silencio (t3,5)	Cabecera MBAP (7 bytes)
Latencia típica	5–50 ms por transacción	<5 ms en LAN dedicada
Costo de hardware	Muy bajo	Moderado (PHY, switch industrial)
Distancia sin repetidor	Hasta 1200 m a 9600 bps	100 m por segmento (cobre)
Determinismo	Alto (solo el cliente habla)	Sujeto a colisiones lógicas y congestión
Inmunidad EMI	Excelente (par diferencial)	Buena, depende del cableado
Concurrencia	Un cliente, un diálogo a la vez	Múltiples clientes simultáneos

La regla práctica es: un bus físico largo, ruidoso y con muchos dispositivos económicos pide RTU; la integración con SCADA modernos, múltiples supervisores concurrentes y tasas de muestreo agresivas pide TCP. Los gateways RTU↔TCP son habituales y resuelven escenarios híbridos sin reescribir firmware.

Errores y excepciones

Cuando el servidor reconoce la solicitud pero no puede atenderla, responde con el function code original sumado a 0x80 y un byte de código de excepción. Los más comunes en campo:

Código	Nombre	Causa típica
0x01	Illegal Function	Function code no implementado por el servidor
0x02	Illegal Data Address	Dirección fuera del mapa o bloque prohibido
0x03	Illegal Data Value	Cantidad fuera de 1–125 o valor fuera del rango permitido
0x04	Slave Device Failure	Error interno (memoria, hardware, autocheck)

Los errores 0x05 (Acknowledge), 0x06 (Slave Busy), 0x08 (Memory Parity Error) y 0x0B (Gateway Target Failed to Respond) aparecen en escenarios específicos — programación larga, dispositivos con cola y gateways, respectivamente. Cuando no hay respuesta dentro del timeout (típicamente 100–500 ms), el cliente debe registrar timeout, no exception; la diferencia es diagnóstica.

La rutina recomendada de depuración en campo es: (1) confirmar baud rate, paridad y stop bits idénticos en ambos lados; (2) confirmar la dirección del servidor; (3) capturar el tráfico crudo con un analizador serie o sniffer Modbus; (4) validar el CRC de la solicitud manualmente; (5) probar el mismo registro con un cliente conocido (QModMaster, mbpoll); (6) recién entonces sospechar del firmware del servidor.

Buenas prácticas de instalación RS-485

La mayoría de las fallas atribuidas a "Modbus inestable" son en realidad problemas de capa física. La norma EIA-485 dimensiona el transceptor, pero el diseño del bus es responsabilidad del integrador.

• Topología: línea de transmisión única (daisy-chain), sin estrellas y sin stubs mayores a 30 cm. Las estrellas cortas funcionan en laboratorio y fallan en obra con ruido.
• Terminación: resistor de 120 Ω en cada extremo físico del bus, adaptado a la impedancia característica del par. Terminar solo un extremo genera reflexión.
• Polarización (bias): resistores de pull-up en A y pull-down en B (típicamente 680 Ω a 1 kΩ) para mantener un estado idle definido. Sin polarización, el primer bit tras el silencio puede ser interpretado mal.
• Cable: par trenzado apantallado con impedancia de 120 Ω (p. ej., Belden 9841 o equivalente). El apantallado conectado a tierra en un único punto, normalmente en el tablero del cliente Modbus.
• Referencia de tierra: conductor adicional (signal common) que interconecta todos los GND de los transceptores a través de un resistor de 100 Ω/0,5 W en cada nodo, limitando la corriente de modo común.
• Longitud × velocidad: la relación clásica es hasta 1200 m a 9600 bps; a 115200 bps manténgase por debajo de 100 m para preservar margen de jitter.
• Aislamiento galvánico: obligatorio en entornos con VFDs, soldadura o puestas a tierra cuestionables. Los transceptores aislados resuelven más problemas que los repetidores activos.
• Separación de cableado: distancia mínima de 30 cm respecto a cables de potencia; cruces siempre en ángulo de 90°.

Un bus bien dimensionado a 19200 bps con 16 dispositivos es más confiable y más fácil de mantener que el mismo bus llevado a 115200 bps sin necesidad real. El rendimiento no es un objetivo aislado en Modbus RTU.

Cómo probar su integración

Antes de poner en marcha el SCADA, conviene ejercitar el mapa de registros contra un servidor controlado. LRI pone a disposición un simulador en Python que emula el comportamiento de un AEM-60DC8 — incluyendo los 147 holding registers, los bloques de alarma y la curva de lectura de los 8 canales — sobre puerto serie virtual o TCP encapsulado. Conceptualmente, el simulador permite:

• Validar el cliente sin el equipo físico en mano.
• Forzar condiciones de borde (canal en sobretensión, alarma global, falla de canal) que serían difíciles de provocar en banco.
• Ejecutar pruebas de regresión automatizadas en CI ante cada cambio del SCADA.
• Comparar dos implementaciones del cliente (p. ej., legado vs. nuevo) leyendo el mismo conjunto de registros.

La combinación de un simulador determinístico con el equipo real reduce drásticamente el tiempo de puesta en servicio. Para conocer el mapa de registros completo, los rangos eléctricos y los modos Secure by Design del producto, consulte la página del AEM-60DC8 y la documentación técnica disponible en aem.lri.com.br.

Conclusión

Modbus RTU sobrevive porque resuelve un problema bien definido: transportar enteros de 16 bits entre un cliente y decenas de servidores por un par de hilos, de forma previsible, económica y auditable. Saber leer un frame, mapear holding registers con claridad, dimensionar la capa física y diagnosticar excepciones es el herramental mínimo del ingeniero que integra equipos industriales en 2026. Los protocolos modernos van a coexistir con RTU durante mucho tiempo, y el profesional capaz de transitar entre serie y TCP, entre CRC y TLS, es el que entrega los proyectos en plazo. El AEM-60DC8 fue diseñado para ese profesional, con un mapa de registros estable, un simulador disponible y una postura Secure by Design.

Preguntas frecuentes

¿Modbus RTU todavía se usa en 2026? Sí. La base instalada es del orden de cientos de millones de dispositivos, y la mayoría de los retrofits industriales aún exigen compatibilidad con RTU. Los equipos nuevos suelen exponer RTU y TCP simultáneamente.

¿Cuál es la diferencia entre holding registers e input registers? Los holding registers son de lectura/escritura (function codes 0x03, 0x06, 0x10), y se utilizan típicamente para parámetros, setpoints y configuraciones. Los input registers son de solo lectura (function code 0x04), reservados para magnitudes medidas.

¿Cómo descubrir la dirección Modbus RTU de un dispositivo desconocido? El barrido sistemático en las direcciones 1–247 con lectura de un registro probable (por ejemplo, 0x0000) es el enfoque estándar. Herramientas como mbpoll y QModMaster automatizan el barrido. En buses críticos, realice el barrido offline para evitar ruido en los intercambios normales.

¿Es seguro Modbus RTU? La especificación no prevé autenticación ni cifrado. La buena práctica es aislar físicamente el bus y usar gateways con filtrado para cualquier puente con redes no confiables. Los equipos con postura Secure by Design complementan a Modbus con controles en capas adyacentes (firma de firmware, registros de auditoría, separación de planos).

¿Puedo tener dos clientes (masters) en el mismo bus RTU? No, no en la especificación clásica. El modelo es estrictamente un cliente por bus. Los escenarios con múltiples supervisores requieren gateway con arbitraje, paso a Modbus TCP o segmentación física del bus.

---