¿Qué convertidor debo elegir para conectar Modbus RTU a Modbus TCP?

Elegir un convertidor Modbus RTU a Modbus TCP parece sencillo solo a primera vista. En la práctica no basta con comprobar si el dispositivo tiene un puerto RS-485 y Ethernet. Lo fundamental es determinar quién inicia la comunicación, en qué lado se encuentra el dispositivo maestro, cuántos dispositivos deben trabajar en el bus serie, cuáles son los requisitos de mapeo de registros, tiempo de respuesta, aislamiento, diagnosis y estabilidad de funcionamiento en un entorno industrial.

Para conectar Modbus RTU con Modbus TCP se debe seleccionar un convertidor de protocolos Modbus que, en el lado serie, soporte la variante Modbus RTU, normalmente RS-485, y que, en el lado Ethernet, funcione como Modbus TCP client o Modbus TCP server. La elección del modelo concreto depende de la arquitectura del sistema, es decir, de si el PLC, SCADA o sistema BMS debe leer dispositivos RTU, o al contrario. En términos generales, un master Modbus RTU existente debe comunicarse con un dispositivo o sistema mediante Modbus TCP.

Modbus RTU, Modbus TCP y otra capa de comunicación

Modbus RTU y Modbus TCP utilizan una lógica similar de intercambio de datos: direcciones de dispositivos, funciones Modbus, registros, bobinas, entradas discretas y registros de entrada. La diferencia se encuentra principalmente en la capa de transporte.

Modbus RTU funciona normalmente sobre RS-485 o RS-232. Es una comunicación serie en la que los dispositivos trabajan en un bus común, con una velocidad de transmisión, paridad, número de bits de parada y dirección slave definidos. Una instalación típica Modbus RTU incluye un master y muchos dispositivos slave conectados a una misma línea RS-485.

Modbus TCP funciona sobre Ethernet, normalmente mediante conector RJ45. En esta variante, la comunicación se realiza en una red IP y los dispositivos se identifican mediante dirección IP y puerto TCP, normalmente 502. En lugar de los términos clásicos master/slave se utilizan con frecuencia client/server, pero la regla práctica sigue siendo similar, es decir, una parte inicia la consulta y la otra responde.

Un convertidor Modbus RTU a Modbus TCP no es, por tanto, un simple adaptador. Es un dispositivo que debe interpretar correctamente las tramas Modbus en un lado y presentarlas en la forma adecuada en el otro lado.

¿Quién es el master y quién es el cliente?

El primer y más importante paso al elegir un convertidor es determinar qué dispositivo inicia la comunicación. En proyectos de automatización, el error más frecuente consiste en que el usuario busca un “convertidor Modbus RTU a TCP”, pero no especifica si necesita una variante:

• Modbus TCP client a Modbus RTU slave,
• Modbus TCP server a Modbus RTU slave,
• Modbus RTU master a Modbus TCP server,
• Modbus RTU slave a Modbus TCP client/server,
• o un convertidor con mapeo completo de datos entre dos lados.

El caso más habitual es el siguiente: un sistema SCADA, un PLC o un ordenador industrial trabaja en una red Ethernet y debe leer datos de contadores de energía, reguladores de temperatura, variadores de frecuencia, analizadores de red u otros dispositivos Modbus RTU. En esa situación normalmente se necesita un gateway que, en el lado Ethernet, proporcione comunicación Modbus TCP y, en el lado RS-485, consulte los dispositivos Modbus RTU.

Otro caso aparece cuando un PLC existente solo tiene puerto RS-485 y trabaja como Modbus RTU master, mientras que el nuevo dispositivo está disponible exclusivamente por Ethernet como Modbus TCP server. Entonces se necesita un convertidor que funcione en el sentido contrario: desde el lado del PLC se comporta como un dispositivo Modbus RTU slave, y desde el lado Ethernet se comunica con el servidor Modbus TCP.

Esta distinción es crítica. Dos convertidores pueden tener conectores idénticos, una carcasa similar y una descripción parecida, pero diferir en el rol del protocolo. Si el rol se selecciona de forma incorrecta, los dispositivos se conectarán físicamente, pero el intercambio de datos no arrancará.

¿Gateway transparente o convertidor con mapeo de registros?

La segunda pregunta importante al elegir un dispositivo es si se necesita un gateway transparente simple o un dispositivo con mapeo de datos.

Un convertidor transparente Modbus RTU a Modbus TCP transmite las consultas entre Ethernet y el bus serie. Es una buena elección cuando el sistema superior sabe por sí mismo qué direcciones de dispositivos y qué registros debe consultar. Un buen ejemplo es cuando SCADA envía una consulta Modbus TCP a la dirección IP del convertidor, indica el Unit ID correspondiente al dispositivo RTU y el gateway transmite la consulta a RS-485.

Un convertidor con mapeo de registros es más avanzado. Puede consultar cíclicamente los dispositivos de un lado, almacenar los datos en su memoria y ponerlos a disposición del otro lado como un mapa de registros ordenado. Este modelo es mejor cuando se requiere:

• agrupar datos de muchos dispositivos RTU,
• modificar la direccionamiento de registros,
• separación temporal entre el bus RS-485 lento y la red Ethernet más rápida,
• comunicación con varios clientes TCP,
• un mapa de datos estable para PLC o SCADA,
• conversión de tipos de datos, orden de bytes u orden de palabras.

En aplicaciones sencillas basta con un gateway transparente. En sistemas industriales, BMS, energía, instalaciones de medida y sistemas SCADA más grandes, es más seguro elegir un convertidor con configuración de la tabla de intercambio de datos.

Número de dispositivos Modbus RTU y parámetros del bus RS-485

Si el convertidor debe trabajar con muchos dispositivos Modbus RTU, hay que comprobar no solo el número máximo de slaves soportados, sino también las limitaciones prácticas del bus.

Los parámetros importantes son:

• número de dispositivos en RS-485,
• direcciones Modbus slave,
• velocidad de transmisión, por ejemplo 9600, 19200, 38400, 57600 o 115200 bps,
• paridad, número de bits de datos y bits de parada,
• longitud del cable,
• topología del bus,
• terminación en los extremos de la línea,
• apantallamiento y tendido de cables,
• presencia de interferencias electromagnéticas,
• tiempo de respuesta de cada dispositivo.

Modbus RTU es secuencial. Esto significa que el master consulta los dispositivos uno por uno. Aunque la comunicación en el lado Ethernet sea rápida, el conjunto estará limitado por el tramo más lento, normalmente RS-485. Con un gran número de dispositivos y muchos registros consultados cada segundo, se deben seleccionar con mucho cuidado los tiempos de timeout, intervalos de consulta y número de consultas. Un buen convertidor debe permitir configurar los parámetros del puerto serie, los timeouts, los retardos entre consultas y el número de reintentos de transmisión. De lo contrario, una unidad que responda mal puede ralentizar todo el bus.

Modbus TCP - client o server y número de conexiones

En el lado Ethernet hay que comprobar si el convertidor trabaja como Modbus TCP server, Modbus TCP client o si soporta ambos modos. Para muchos proyectos también es importante el número de conexiones TCP simultáneas.

Si un solo PLC debe tener acceso a los datos de los dispositivos RTU, los requisitos son sencillos. Sin embargo, si esos mismos datos deben ser leídos en paralelo por SCADA, BMS, un panel HMI y un sistema de informes, el convertidor debería soportar varios clientes TCP o trabajar con una memoria interna de datos. Sin ello pueden aparecer conflictos, retrasos o una comunicación inestable. También conviene comprobar si el dispositivo soporta Unit ID en Modbus TCP. Es especialmente importante en gateways que transmiten consultas de Ethernet a muchos dispositivos RTU en un mismo bus RS-485. Unit ID permite indicar a qué dispositivo slave del lado RTU debe llegar la consulta.

Aislamiento galvánico y resistencia industrial

En automatización industrial, la elección del convertidor no termina en los protocolos. El dispositivo trabaja a menudo en un armario de control, cerca de variadores de frecuencia, fuentes de alimentación conmutadas, contactores, cables de señal largos y circuitos con diferentes potenciales de masa. Por eso conviene prestar atención al aislamiento galvánico del puerto RS-485, al aislamiento de alimentación, al rango de temperatura de trabajo y a la resistencia EMC.

En proyectos de laboratorio o instalaciones de edificios sencillas, un convertidor económico puede funcionar correctamente. En instalaciones industriales, una mejor elección es un dispositivo con carcasa para carril DIN, alimentación industrial, interfaces aisladas y diagnosis clara. La diferencia suele aparecer solo después de varias semanas de funcionamiento, cuando surgen pérdidas periódicas de comunicación, errores CRC o bloqueos de transmisión bajo carga de la instalación.

La diagnosis es más importante que el precio

Un buen convertidor Modbus RTU a Modbus TCP debería permitir una diagnosis sencilla. En la práctica, el integrador necesita saber:

• si el puerto Ethernet está conectado,
• si el convertidor recibe consultas Modbus TCP,
• si envía tramas a RS-485,
• si los dispositivos RTU responden,
• si aparecen errores CRC,
• si el problema afecta a la dirección, a los parámetros de transmisión o a la propia red.

Son útiles los diodos LED, registros de diagnosis, vista previa de tramas, estadísticas de errores y la posibilidad de probar la lectura de registros desde el software de configuración. En instalaciones pequeñas se puede trabajar con un tester Modbus simple. En sistemas más grandes, la falta de diagnosis implica largas horas buscando el error entre el PLC, el gateway, el cable RS-485 y el dispositivo final.

¿Cuándo basta un convertidor simple y cuándo se necesita un gateway industrial?

Un convertidor simple basta cuando:

• en el lado RTU hay uno o varios dispositivos,
• el sistema superior consulta los registros por sí mismo,
• no es necesario cambiar la direccionamiento de datos,
• no hay grandes requisitos temporales,
• el entorno de trabajo es poco exigente,
• basta una conversión básica Modbus TCP a Modbus RTU.

Un gateway industrial con mapeo de datos será mejor cuando:

• hay muchos dispositivos RTU,
• los datos deben estar disponibles para muchos clientes TCP,
• es necesario ordenar el mapa de registros,
• hay que cambiar la estructura de direcciones,
• se necesita separación entre la red Ethernet rápida y el bus RS-485 más lento,
• la instalación trabaja en un entorno industrial difícil,
• se requiere diagnosis estable y comportamiento previsible tras la pérdida de comunicación.

Ejemplo 1: SCADA por Ethernet lee contadores Modbus RTU

Este es uno de los escenarios más frecuentes. Los contadores de energía trabajan por RS-485 como Modbus RTU slave. El sistema SCADA funciona en un ordenador industrial dentro de una red Ethernet. En este caso se debe seleccionar un convertidor que, desde el lado Ethernet, sea visible como punto de comunicación Modbus TCP y, desde el lado RS-485, transmita las consultas a los dispositivos RTU.

Si SCADA debe consultar cada contador de forma independiente, basta con un gateway transparente con soporte de Unit ID. Si hay muchos contadores y los datos deben además ordenarse, será mejor elegir un convertidor con mapa de registros y polling cíclico.

Ejemplo 2: un PLC antiguo Modbus RTU debe leer un nuevo dispositivo Ethernet

En instalaciones antiguas aparece a menudo un PLC con puerto RS-485 que no conviene sustituir. El nuevo analizador, contador o controlador está disponible solo por Modbus TCP. En este caso, un gateway TCP a RTU ordinario puede no ser suficiente. Se necesita un convertidor que, desde el lado del PLC, se comporte conforme a las expectativas del master RTU, y desde el lado Ethernet se comunique con el dispositivo Modbus TCP. Aquí el mapeo de registros es especialmente importante. El PLC no debería “saber” que los datos proceden de un dispositivo TCP. Debe recibir un mapa Modbus RTU estable y previsible.

Ejemplo 3: muchos dispositivos RTU, un sistema BMS

En sistemas BMS a menudo hay que recoger datos de reguladores, contadores, módulos I/O o dispositivos HVAC. Si cada dispositivo tiene una dirección distinta, registros diferentes y tiempos de respuesta distintos, una buena solución es un gateway con posibilidad de configurar una lista de consultas. El convertidor consulta por sí mismo los dispositivos RTU, guarda los datos en memoria y los pone a disposición del sistema BMS por Modbus TCP. Esta solución limita el número de consultas directas desde BMS al bus RS-485 y mejora la estabilidad de todo el sistema. También es más fácil de mantener, porque el mapa de datos del lado TCP puede organizarse independientemente de lo caóticos que sean los registros en los dispositivos de campo.

Errores más frecuentes al elegir un convertidor Modbus RTU a Modbus TCP

El error más frecuente es elegir el dispositivo solo por el nombre “convertidor Modbus RTU a Modbus TCP”, sin comprobar los roles de comunicación. El segundo error es suponer que el convertidor acelerará la comunicación RTU. Ethernet es más rápido, pero si los datos proceden de un bus RS-485 lento, la limitación sigue estando en RTU.

Otros errores son la falta de terminación RS-485, paridad incorrecta, direcciones slave duplicadas, timeouts demasiado cortos, consultas demasiado frecuentes de un gran número de registros, ausencia de aislamiento en un entorno difícil y falta de diagnosis. En la práctica, muchos problemas no proceden del propio protocolo, sino de errores físicos y temporales en la capa RS-485.

¿Cómo elegir un convertidor Modbus RTU a Modbus TCP? Paso a paso

Antes de elegir un modelo concreto conviene responder a varias preguntas:

1. ¿El dispositivo superior se encuentra en el lado Modbus TCP o Modbus RTU?
2. ¿El convertidor debe trabajar como Modbus TCP server, Modbus TCP client, Modbus RTU master o Modbus RTU slave?
3. ¿Cuántos dispositivos RTU estarán conectados al bus RS-485?
4. ¿Cuáles son los parámetros de transmisión: baud rate, parity, data bits, stop bits?
5. ¿El sistema superior debe consultar directamente los dispositivos o los datos deben mapearse en la memoria del convertidor?
6. ¿Cuántos clientes TCP utilizarán los datos simultáneamente?
7. ¿Es necesario soportar Unit ID?
8. ¿Se requiere aislamiento galvánico?
9. ¿El dispositivo debe trabajar en un armario industrial, en carril DIN, a temperatura elevada o en un entorno con interferencias EMC?
10. ¿El convertidor ofrece diagnosis de tramas, errores y estado de comunicación?
11. ¿El software de configuración permite ajustar el mapa de registros, timeouts, polling y orden de bytes?
12. ¿Tras la pérdida de comunicación, el dispositivo conserva los últimos valores, pone a cero los registros o señaliza un error?

¿Qué convertidor elegir?

Para conectar Modbus RTU con Modbus TCP no se debe elegir “cualquier adaptador RS-485 Ethernet”, sino el gateway Modbus correcto, seleccionado según el sentido de la comunicación, los roles master/slave o client/server, el número de dispositivos, el modo de mapeo de datos y las condiciones de trabajo. Si el sistema SCADA, PLC o BMS por Ethernet debe leer dispositivos Modbus RTU, normalmente se elige un convertidor Modbus TCP server a Modbus RTU master/slave con soporte de Unit ID o mapeo de registros. Si, en cambio, un master Modbus RTU antiguo debe comunicarse con dispositivos por Ethernet, se necesita un convertidor que trabaje en el modo contrario, a menudo con una tabla de intercambio de datos.

En instalaciones sencillas basta con un gateway transparente. En aplicaciones industriales, donde cuentan la estabilidad, la diagnosis, la separación de datos y la resistencia a interferencias, es más seguro elegir un convertidor industrial con configuración de registros, aislamiento, montaje DIN y diagnosis completa de comunicación. Precisamente la definición correcta del rol del protocolo y de la estructura de intercambio de datos decide si la integración de Modbus RTU con Modbus TCP funcionará de forma estable o se convertirá en una fuente de problemas difíciles de detectar durante la puesta en marcha y el servicio.