Modbus RTU y Modbus TCP: diferencias para integrar equipos de planta

Que dos equipos indiquen «Modbus» no garantiza que puedan intercambiar la información requerida sin configuración adicional. Deben coincidir transporte, funciones y representación de datos. Antes de integrar, reúna el manual de comunicación y el mapa de registros de cada equipo.

RTU y TCP utilizan transportes distintos

Modbus RTU se utiliza en enlaces seriales; RS-485 es una implementación habitual descrita en la guía serial de Modbus Organization. Es necesario identificar interfaz, parámetros seriales y direcciones de los equipos. La conexión física debe cumplir los requisitos de la red y de los dispositivos.

Modbus TCP transporta mensajes sobre TCP/IP, habitualmente en una red Ethernet. Utiliza una cabecera MBAP y requiere identificar direcciones de red y el servicio del dispositivo. Una pasarela puede vincular equipos TCP con una red serial, pero su configuración y compatibilidad deben comprobarse.

Defina quién solicita y quién responde

El cliente inicia las consultas y el servidor responde a ellas. Modbus Organization adoptó esos términos para describir la relación de comunicación. Identificar el papel de cada equipo evita esperar que dos dispositivos configurados únicamente como servidores comiencen a intercambiar datos por sí solos.

Para RTU, registre velocidad, paridad y parámetros indicados por los manuales. Para TCP, registre dirección IP, puerto y el uso del identificador de unidad cuando corresponda, especialmente con pasarelas. El esquema es conceptual y no define una topología física completa ni direcciones de una planta real.

El mapa de registros es indispensable

La especificación de aplicación distingue objetos y funciones de acceso. El fabricante documenta dónde está cada variable, qué operación admite y cómo se interpreta. Una respuesta de comunicación correcta puede contener un valor mal interpretado si se desconoce la escala o el formato.

Para cada dato, reúna dirección, función, tipo, unidad, factor de escala y orden de palabras cuando use varios registros. Confirme también si la herramienta expresa direcciones como posiciones de protocolo o como referencias documentales. La tabla ilustrada contiene un dato hipotético y no reproduce el mapa de un producto.

Qué verificar antes de usar el dato

Como propuesta de aceptación, compare una variable conocida con la indicación del equipo y revise su estado ante pérdida de comunicación. No transforme un dato antiguo en una lectura actual por conservar el último número recibido. Defina en el proyecto tiempos de consulta y tratamiento de calidad o disponibilidad.

Este artículo no propone escribir registros de control ni cambiar configuraciones de una red en servicio. Esas acciones requieren procedimiento y autorización de la planta, porque pueden afectar su operación.

Separe transporte, función y significado del dato

Para integrar un equipo se necesitan tres definiciones distintas: cómo llega el mensaje, qué operación solicita el cliente y cómo interpreta la aplicación la respuesta. RTU y TCP describen formas de transporte; el mapa del producto explica qué información existe y cómo se representa. Resolver la comunicación deja todavía pendiente esa interpretación.

La especificación de aplicación de Modbus Organization define objetos, funciones y direccionamiento. Las guías serial y TCP/IP describen sus mecanismos de transporte. Utilizar cada documento para la pregunta que responde evita atribuir al protocolo una escala o variable que pertenece al fabricante del dispositivo.

Como propuesta documental, prepare una ficha de red y otra de datos, vinculadas por equipo y versión. Si el producto cambia de firmware o de configuración, compruebe qué parte de la documentación sigue siendo aplicable.

Qué debe coincidir en una comunicación RTU

La guía serial describe el modo RTU y la configuración del enlace. Para una consulta, identifique interfaz física, parámetros seriales y direcciones de los dispositivos. Estos datos necesitan corresponder a la documentación de los equipos y a la red prevista.

Una etiqueta RS-485 identifica una interfaz física, pero no demuestra por sí sola que un dispositivo utilice Modbus RTU. Del mismo modo, indicar RTU sin la interfaz disponible deja incompleta la evaluación de conexión. Confirme ambas descripciones en la documentación del producto.

El artículo no fija longitudes, terminaciones o polarización para una red de planta. Esas decisiones deben revisarse con el diseño y las características de los dispositivos. Un esquema conceptual de intercambio no sustituye un plano de comunicaciones ni autoriza cambios sobre una red en servicio.

Qué identifica una solicitud Modbus TCP

La guía TCP/IP describe el intercambio cliente/servidor y la cabecera MBAP. La integración necesita documentar dirección del dispositivo, servicio y papel de cada participante. Tener conectividad de red no demuestra todavía que el servidor admita la operación que la aplicación solicita.

El identificador de unidad requiere atención cuando interviene una pasarela hacia una red serial. Su uso debe contrastarse con el dispositivo y la guía correspondiente. No conviene confundirlo con la dirección IP ni copiar un valor de ejemplo sin conocer la función que cumple.

Una pasarela debe evaluarse para el conjunto: equipos, transporte, operaciones y configuración. El artículo no afirma que cualquier convertidor permita cualquier combinación. La documentación debe mostrar cómo se vinculan los destinos y qué límites declara el producto.

Los objetos del protocolo no describen solos la aplicación

La especificación distingue entradas discretas, bobinas, registros de entrada y registros de mantenimiento, con características de acceso. Un registro utiliza una palabra de 16 bits en ese modelo. El producto debe documentar qué información representa cada objeto y qué funciones admite.

No se puede inferir que un registro contiene presión, temperatura o una orden por su dirección. Tampoco que todos los registros accesibles tengan la misma escala. Para cada variable, conserve nombre, función, dirección, cantidad de registros, formato y unidad declarados por el fabricante.

Si un objeto permite escritura, eso no autoriza modificarlo desde una herramienta de prueba. Una operación sobre consignas o control puede afectar el proceso. Este artículo se centra en preparar la integración y no entrega instrucciones de escritura de registros.

Revise la convención de direcciones

El apartado 4.4 de la especificación diferencia la numeración del modelo y las direcciones utilizadas en el mensaje de protocolo. Una aplicación puede presentar referencias documentales y otra pedir un desplazamiento. Antes de configurar, revise qué convención utiliza cada herramienta.

Ejemplo conceptual: si un fabricante numera el primer elemento como uno, la dirección correspondiente en el mensaje puede ser cero según ese modelo. El ejemplo explica la diferencia de base; no permite restar uno indiscriminadamente a todos los números impresos en un manual.

La ficha de integración debería conservar tanto la referencia del documento como el valor introducido en la herramienta, junto con su interpretación. Así se puede revisar una discrepancia sin perder el vínculo con la documentación original.

Escala y formato pueden producir errores con comunicación correcta

Una respuesta válida puede contener un entero que representa una magnitud mediante un factor de escala. El ejemplo de la imagen utiliza 253 y un factor hipotético de 0,1 para obtener 25,3. Ese cálculo no corresponde a un mapa real de producto.

Si una variable utiliza varios registros, se necesita conocer cómo se organiza el dato compuesto. La especificación define la codificación de valores del protocolo; la representación de una variable de aplicación debe verificarse en el mapa del fabricante. No deduzca el orden de palabras de un dato de mayor tamaño únicamente del nombre Modbus.

Registre también si el dato tiene signo y qué valores especiales declara el producto. Aplicar una conversión de una variable a otra sin esa información puede producir un número plausible y una interpretación equivocada.

Distinga una respuesta, una excepción y la falta de respuesta

La especificación describe respuestas de excepción para solicitudes que no pueden procesarse como se pide. Una excepción aporta información distinta de un silencio de comunicación. Para una consulta de integración, conserve el mensaje completo y la operación solicitada, sin atribuir automáticamente ambos casos a una falla física.

El proyecto también debe definir qué ocurre cuando no se recibe un dato en el tiempo previsto. Ese tiempo requiere evaluación según la aplicación y los dispositivos. No se propone un valor universal de espera ni una frecuencia de consulta para cualquier red.

Una pantalla puede conservar el último dato recibido, pero su uso debe distinguir disponibilidad actual y antecedente. Documentar esa condición permite revisar la respuesta del sistema ante interrupciones sin interpretar una cifra detenida como medición vigente.

Prepare una aceptación basada en variables conocidas

Como propuesta original, seleccione variables de lectura cuyo significado pueda contrastarse con una indicación o referencia disponible. Registre operación, dirección, respuesta, interpretación y resultado esperado. El alcance y las condiciones deben acordarse antes de ejecutar pruebas.

Para una planta en Paraguay, adjunte modelos, versiones, mapas y requerimientos de datos junto con la topología prevista. La revisión podrá separar incompatibilidades de transporte, dudas de direccionamiento y preguntas de representación. Esa preparación facilita delimitar la integración sin intervenir sobre registros de control ni atribuir capacidades no documentadas a los equipos.

Consulta de integración en Paraguay

Reúna modelos, versiones, interfaces, mapas de registros y variables necesarias para consultar Automatización Industrial o Instrumentación y Control de TECNICAT. Otros contenidos sobre integración están en Automatización industrial.

Fuentes técnicas

• MODBUS-APP — Modbus Organization. MODBUS Application Protocol Specification. V1.1b3, 26 de abril de 2012. Modelo/alcance: Sin modelo; protocolo de aplicación. Apartado: §4.2 Data Encoding, §4.3 Data Model, §4.4 Addressing Model; §6 Function Codes; §7 Exception Responses, pp. 47–48. Consulta: 2026-10-02.
• MODBUS-SERIAL — Modbus Organization. MODBUS over Serial Line — Specification and Implementation Guide. V1.02, 20 de diciembre de 2006; guía que el portal recomienda para nuevas implementaciones seriales. Modelo/alcance: Sin modelo; RTU sobre red serial. Apartado: §2.2 Modbus Addressing Rules; §2.5 RTU Transmission Mode; §3 Physical Layer. Consulta: 2026-10-02.
• MODBUS-TCP — Modbus Organization. MODBUS Messaging on TCP/IP Implementation Guide. V1.0b, 24 de octubre de 2006, listada en portal oficial. Modelo/alcance: Sin modelo; Modbus TCP. Apartado: §1.2 Client/Server Model; §3.1.1–3.1.3, pp. 2–6. Consulta: 2026-10-02.
• MODBUS-TERMS — Modbus Organization. Modbus Organization Replaces Master-Slave with Client-Server. Noticia oficial, 9 de julio de 2020. Modelo/alcance: Terminología; sin modelo. Apartado: Anuncio y descripción del intercambio. Consulta: 2026-10-02.