Cómo habla Modbus Captia Connect
Connect se comporta como maestro: es quien pregunta. El equipo de planta es el esclavo y solo responde cuando se le interroga, así que la cadencia del histórico no la decide el equipo, la decide la configuración de sondeo del nodo Connect. Esa es la diferencia práctica frente a OPC UA o MQTT y condiciona todo lo demás: aquí no hay notificación de cambio ni modelo semántico, hay un mapa de registros y un reloj.
Lo que Connect necesita para empezar no es software en el autómata, es documentación: el mapa de registros del equipo, que el fabricante publica en el manual de comunicaciones. Sin ese documento la integración se convierte en arqueología, y ese es el primer punto que se verifica antes de comprometer una puesta en marcha.
El modelo de datos: cuatro tablas y ninguna semántica
Un esclavo Modbus expone cuatro espacios de direcciones separados, y Connect los lee con funciones distintas porque el protocolo los trata como tablas independientes. Las coils son bits de lectura y escritura, típicamente estados de salida digital. Las discrete inputs son bits de solo lectura, típicamente entradas digitales o bits de alarma. Los input registers son palabras de 16 bits de solo lectura, donde suelen vivir las medidas. Los holding registers son palabras de 16 bits de lectura y escritura, donde conviven medidas, contadores, parámetros de configuración y consignas.
La consecuencia operativa importa más que la taxonomía: la misma magnitud puede aparecer en input registers en un contador y en holding registers en un variador, y no hay ninguna regla del protocolo que lo garantice. Connect no infiere nada de la tabla en la que está el dato. Cada señal se declara con su tabla, su dirección, su tipo y su escala, tomados del manual, y eso es lo que se verifica contra el display del equipo en la puesta en marcha.
Connect lee. Los holding registers admiten escritura y las coils también, pero la integración se plantea de adquisición: el control y las consignas siguen siendo del sistema de automatización de la planta. Cuando el equipo lo permite, la cuenta o el perfil que usa Connect se limita a lectura.
Direccionamiento y el desfase de 1
Este es el error que más veces obliga a repetir una puesta en marcha. La trama Modbus viaja con una dirección que empieza en cero, pero la documentación tradicional de muchos fabricantes numera los registros a partir de uno y con un prefijo de tabla: el holding register documentado como 40001 es la dirección 0 en la trama, y el 40108 es la 107. Otros manuales publican directamente la dirección de trama y añaden una nota que nadie lee.
Connect no adivina la convención. Al declarar una señal se fija de forma explícita si la dirección introducida es la de la trama o la del manual, y la comprobación es siempre la misma y siempre empírica: se lee un registro de valor conocido y estable, un número de serie, una versión de firmware o una tensión de fase que el equipo esté mostrando en su display, y se contrasta. Si sale desplazado un registro, la convención estaba mal. Hacer esa lectura de control al principio ahorra que el desfase aparezca semanas después disfrazado de dato absurdo.
Tipos, orden de palabra y escalado
Un registro Modbus son 16 bits sin más información. El protocolo no declara si eso es un entero con signo, un entero sin signo, o la mitad de un valor de 32 bits. Aquí es donde se cae media integración, y por eso la declaración de tipo en Connect es explícita señal a señal.
Cuando una magnitud ocupa dos registros, un entero de 32 bits o una coma flotante de precisión simple, aparece el orden de palabra. Dentro de cada registro el orden de bytes viene fijado por el protocolo, big endian, pero el orden en que el fabricante coloca la palabra alta y la palabra baja del valor de 32 bits no lo fija nadie. Existen equipos con palabra alta primero y equipos con palabra baja primero, y ambos son legítimos. Connect declara ese orden por señal, no por equipo, porque hay dispositivos que no son coherentes consigo mismos entre bloques del mapa.
El síntoma de acertar el tipo y fallar el orden de palabra es reconocible: la lectura no sale ligeramente desviada, sale absurda, del orden de 10^38 o negativa cuando no puede serlo, y salta de valor con cualquier variación pequeña de la magnitud real. Cuando ocurre eso no hay que revisar el sensor, hay que invertir las palabras y volver a leer.
Falta el escalado. La mayoría de los equipos no envían unidades de ingeniería: envían enteros con un factor implícito documentado en el manual, o un factor explícito guardado en otro registro. Una potencia en decenas de vatio, una temperatura en décimas de grado, una energía con un multiplicador que depende de la relación de transformación configurada en el propio equipo. Connect aplica factor y unidad en la normalización, de modo que en el histórico la señal llega ya en kW, en grados Celsius o en kWh. Ese es el paso que evita el clásico gráfico multiplicado por diez que nadie detecta hasta que alguien compara con la factura.
| Tabla del esclavo | Qué contiene en la práctica | Cómo la trata Connect |
|---|---|---|
| Coils | Bits de lectura y escritura: estados de salida digital, marchas, permisos | Se leen como señal booleana; la escritura queda fuera del alcance de la adquisición |
| Discrete inputs | Bits de solo lectura: entradas digitales, bits de alarma y de estado | Se leen como booleano y se usan como contexto de las medidas analógicas |
| Input registers | Palabras de 16 bits de solo lectura: normalmente medidas instantáneas | Se declara tipo, orden de palabra y factor de escala señal a señal |
| Holding registers | Palabras de 16 bits de lectura y escritura: medidas, contadores, parámetros y consignas | Se leen solo las direcciones declaradas, sin tocar los registros de configuración |
Modbus TCP: Ethernet, puerto 502 y unit id
Sobre Ethernet, Connect abre una conexión TCP saliente contra la dirección IP del equipo en el puerto 502, que es el que reserva el estándar, y mantiene la sesión abierta entre sondeos en lugar de reconectar en cada lectura. La trama pierde el checksum del modo serie, que TCP ya cubre, y gana una cabecera con un identificador de transacción, lo que permite tener varias peticiones en vuelo sin confundir respuestas.
El campo de dirección de esclavo no desaparece: sobrevive como unit id. En un equipo con Ethernet nativo suele ser irrelevante y vale 1 o 255, pero en una pasarela Modbus TCP a RTU es justamente lo que selecciona a cuál de los equipos del bus serie va dirigida la petición. Ese detalle es el que convierte una pasarela en una integración de veinte equipos con una sola IP, y también el que la convierte en un cuello de botella si se sondea sin criterio, porque detrás de esa IP sigue habiendo un bus serie con su velocidad real.
La conexión es saliente del nodo Connect hacia el equipo y se queda dentro de la red de planta. Hacia fuera, el nodo no abre puertos entrantes: el enlace con la plataforma lo establece Tailscale como conexión saliente segura. Esto importa especialmente en Modbus, porque el protocolo no lleva autenticación ni cifrado de ningún tipo. Un puerto 502 publicado en internet es un equipo de planta expuesto a cualquiera. Cómo se sube ese dato sin abrir la red es lo que desarrolla la guía de llevar datos Modbus a la nube.
Modbus RTU sobre RS-485: bus, tiempos y capa física
En serie, Connect es el único maestro del bus. RS-485 es un par diferencial multipunto: todos los esclavos cuelgan del mismo par trenzado en topología de cadena, cada uno con su dirección de esclavo de 1 a 247, y solo uno habla cada vez. La trama RTU es binaria y lleva un CRC de 16 bits; el fin de trama no es un carácter especial, es un silencio en la línea equivalente a tres caracteres y medio, y por eso el bus es sensible a cualquier cosa que introduzca latencia entre bytes.
Antes de mapear una sola señal hay que fijar cuatro parámetros de puerto que deben coincidir exactamente en todos los equipos del bus y en el nodo Connect: velocidad, habitualmente 9600 o 19200 baudios en parque instalado y 38400 o 115200 en equipos recientes; paridad, con la combinación par y un bit de parada como valor más extendido, y ninguna paridad con dos bits de parada como alternativa frecuente; bits de datos, siempre 8 en RTU; y la dirección de esclavo de cada equipo, que debe ser única en el bus. Dos equipos con la misma dirección producen respuestas solapadas y errores de CRC intermitentes que parecen ruido eléctrico y no lo son.
La capa física decide el resto. El bus va en cadena, sin ramas en estrella, con terminación de 120 ohmios en los dos extremos y en ningún punto intermedio, y con la malla del cable puesta a tierra en un solo punto para no crear un bucle. La longitud admisible depende de la velocidad: a 9600 baudios un bus bien construido llega cómodamente a varios centenares de metros, y esa distancia se reduce a medida que se sube la velocidad. La regla de campo es no subir la velocidad porque sí: si el sondeo cabe en el tiempo disponible a 9600, subir a 115200 solo compra errores de CRC en una nave con variadores conmutando cerca de la bandeja.
Los tiempos son la parte que se subestima. Cada lectura consume un turno de bus completo: petición, tiempo de respuesta del esclavo y silencio de fin de trama. Con veinte equipos en un bus a 9600 baudios, el ciclo de sondeo se mide en segundos, no en milisegundos, y esa es la resolución real de la señal por mucho que la configuración pida más. De ahí las dos decisiones que Connect toma en configuración: agrupar señales contiguas en lecturas de bloque, porque leer treinta registros seguidos en una sola petición cuesta prácticamente lo mismo que leer uno, y asignar cadencias distintas por señal, con la potencia activa a la resolución que exige el análisis y la temperatura de un armario cada varios minutos.
Cuando un esclavo no responde, el maestro se queda esperando hasta agotar el tiempo de espera configurado, y ese tiempo se lo come del ciclo de todos los demás. Un solo equipo apagado por mantenimiento degrada la cadencia del bus entero si el maestro insiste con reintentos agresivos. El comportamiento de Connect es el que evita ese efecto: tiempo de espera acotado, un número limitado de reintentos y, tras fallar, marcar ese esclavo como no disponible y reducir su frecuencia de reintento en lugar de seguir preguntando en cada vuelta. La ausencia se registra como tal en el histórico, que no es lo mismo que un cero.
Distinto es que el esclavo sí responda pero con un código de excepción. Una excepción de dirección ilegal no es un fallo de comunicación, es un mapa mal declarado, normalmente el desfase de 1 o un bloque que ese modelo concreto de la gama no implementa. Se arregla en la configuración, no reintentando.
| Parámetro | Qué se decide | Criterio de partida |
|---|---|---|
| Velocidad | Baudios comunes a todo el bus, entre 9600 y 115200 según el parque | La más baja que permita cerrar el ciclo de sondeo en el tiempo exigido |
| Paridad y bits de parada | Formato de carácter, idéntico en todos los equipos y en el nodo Connect | El que documente el equipo menos configurable del bus, y ese manda sobre el resto |
| Dirección de esclavo | Identificador de 1 a 247 de cada equipo del bus | Único por equipo y anotado en el as built, no solo en la memoria de quien lo montó |
| Terminación y topología | Resistencias de 120 ohmios y trazado del par trenzado | Cadena sin ramas en estrella, terminada en los dos extremos y solo en los dos extremos |
| Ciclo de sondeo | Cadencia por señal y agrupación de registros contiguos en lecturas de bloque | Bloques por equipo y cadencia distinta según lo que decide cada señal |
| Tiempo de espera y reintentos | Qué hace el maestro cuando un esclavo no contesta | Espera acotada, reintentos limitados y degradación del equipo caído para no frenar el bus |
Qué equipos hablan Modbus en una planta
Modbus es el protocolo con más parque instalado de la planta española, y aparece en cuatro familias de equipo que conviene distinguir porque el trabajo de integración es distinto en cada una.
Los analizadores de red y contadores de energía son el caso más frecuente y el más agradecido. Casi todos traen RS-485 con Modbus RTU de serie, y los de gama media añaden Ethernet con Modbus TCP. Su mapa de registros está bien documentado y es estable entre modelos de la misma gama, y exponen tensiones, corrientes, potencias activa y reactiva, factor de potencia y energía acumulada. La trampa habitual está en la energía acumulada, que llega escalada por la relación de transformación de los transformadores de intensidad configurada en el propio equipo, y en el desbordamiento del totalizador.
Los variadores de frecuencia exponen frecuencia de salida, corriente, par estimado, temperatura del disipador, horas de marcha y palabras de estado y de fallo. Estas últimas son mapas de bits: un solo registro que hay que descomponer bit a bit para que signifique algo. Son la fuente más directa para vigilar el estado real de una bomba o un ventilador sin instalar sensórica adicional.
Los PLC y autómatas hablan Modbus TCP casi siempre, bien de forma nativa, bien con un servidor Modbus configurable sobre el área de memoria que decida el programador. Aquí el mapa de registros no viene de un manual de fabricante: lo define quien programó el autómata, y eso lo convierte en el único caso en el que la conversación de puesta en marcha es con una persona y no con un PDF. Cuando ese mismo PLC ofrece OPC UA, suele preferirse esa vía porque el tipo viaja declarado.
Los equipos de instalación y proceso cierran la lista: compresores, enfriadoras, calderas, básculas, centrales de bombeo, sensórica de gama industrial con salida RS-485 y baterías de condensadores. Suelen exponer un conjunto cerrado de registros, que es lo que hay, y sobre eso se trabaja. El servicio que hace esa toma de datos extremo a extremo, incluida la parte de bus y armario, es conectividad de PLC y equipos de planta.
De registro Modbus a serie temporal
Lo que devuelve una petición Modbus es lo mínimo imaginable: una secuencia de palabras de 16 bits, sin tipo, sin unidad, sin nombre y sin hora. Toda la información que OPC UA trae declarada aquí la aporta la configuración de Connect, y por eso el mapeo no es un trámite sino el trabajo principal de la integración.
La identidad de la señal se construye entera en Connect. El registro 40108 del esclavo 7 no le dice nada a nadie: se declara como potencia activa total del cuadro de la línea 2, con su unidad y su nombre estable, y se asocia a su activo, su línea o su zona. Ese es el paso que hace la señal consultable por quien no tiene el manual del analizador delante, y el que describe en general la guía de sistema de adquisición de datos.
El timestamp lo pone Connect en el edge, en el instante de la lectura, porque el protocolo no lo transporta. Importa por el buffering: cuando la conectividad con la plataforma se corta, el nodo sigue sondeando el bus y persiste las lecturas en local sobre su base de datos de series temporales. Al recuperar la red, ese bloque atrasado se sincroniza de golpe, y si estuviera fechado por hora de llegada comprimiría la serie y falsearía la dinámica. Fechado en el edge, cada muestra cae en su sitio.
La calidad también se construye. Modbus no tiene un código de estado por valor como OPC UA, pero sí tiene información utilizable: la respuesta llegó, llegó con excepción, no llegó o falló el CRC. Connect arrastra esa distinción junto al valor en lugar de descartarla, de modo que en el histórico un hueco de comunicación se lee como hueco y no como una potencia de cero vatios. La diferencia se nota el día que una regla de alerta se dispara sobre un equipo que simplemente estaba desconectado.
Queda el caso particular de los contadores. Un totalizador de energía es monótono creciente y desborda al llegar al máximo del tipo, y además se pone a cero si alguien reinicia el equipo o cambia la configuración de transformación. Tratado como una medida cualquiera, ese salto produce un consumo negativo enorme o un pico absurdo en el informe mensual. Se trata declarando la señal como acumulador, de forma que lo que se consulta después es el incremento entre lecturas y el reinicio se identifica en lugar de propagarse al informe.
| Lo que entrega el registro | Qué aporta Connect | Para qué sirve después |
|---|---|---|
| Palabra de 16 bits sin tipo | Tipo declarado por señal y orden de palabra en los valores de 32 bits | Evita el valor absurdo por palabras invertidas y el signo mal interpretado |
| Entero con factor implícito | Factor de escala y unidad de ingeniería aplicados en la normalización | La serie llega en kW, en grados o en kWh, no en cuentas del fabricante |
| Dirección de tabla y de registro | Identidad de la señal, activo, línea o zona y nombre estable | Hace la señal consultable por quien no tiene el mapa de registros delante |
| Ninguna marca de tiempo | Timestamp puesto en el edge en el instante de la lectura | El histórico conserva la separación real entre muestras tras un corte de red |
| Respuesta, excepción, silencio o CRC erróneo | La condición de la lectura se arrastra junto al valor | Un hueco de comunicación se lee como hueco y no como un cero real |
| Totalizador monótono que desborda | La señal se declara como acumulador con detección de reinicio | El consumo por periodo no se rompe al desbordar ni al reiniciar el equipo |
Cuándo Modbus no es la vía adecuada
Modbus resuelve más integraciones que ningún otro protocolo de esta plataforma, y precisamente por eso conviene decir con claridad dónde deja de ser la respuesta correcta. Hay cinco escenarios en los que insistir sale caro.
Cuando hace falta detectar eventos rápidos. Modbus es sondeo puro: lo que ocurre entre dos lecturas no existe. Un pico de corriente en el arranque, un rebote de un final de carrera o un transitorio de proceso de decenas de milisegundos no se capturan subiendo la frecuencia de sondeo, porque el bus tiene un techo y el esclavo también. Cuando el fenómeno es más rápido que el ciclo, la vía es un equipo que lo registre en local y lo publique por evento, y ahí encaja OPC UA por suscripción o MQTT por publicación. Forzar Modbus a esa resolución degrada el bus para todas las demás señales y sigue sin capturar el evento.
Cuando el equipo ya expone OPC UA. Si el mismo PLC ofrece las dos vías, leer por Modbus significa renunciar al tipo declarado, al nombre legible y al timestamp de origen para volver a introducirlos a mano en la configuración. Se hace cuando el servidor OPC UA no tiene licencia o el fabricante no lo habilita, y entonces la decisión es económica y no técnica, pero no se hace por costumbre.
Cuando el dispositivo es autónomo o remoto. Un sensor alimentado por batería, un equipo en una nave sin cable hasta el armario del nodo o una instalación distribuida por varias ubicaciones no encajan en un esquema maestro/esclavo que exige un maestro preguntando de forma continua. Ahí el patrón correcto es que el dispositivo publique cuando tiene algo que decir, y eso es MQTT.
Cuando el dato no está en planta. Órdenes de fabricación, referencias de producto, partes de mantenimiento o resultados de laboratorio viven en un ERP, en un MES o en una aplicación cloud, y no hay registro que sondear. La vía son las integraciones estándar por API REST, webhooks o CSV.
Cuando la instalación es de edificio. Iluminación, clima y automatización terciaria tienen sus propios buses, y traducirlos a un mapa de registros añade una pasarela y pierde la semántica que el bus de edificio sí tiene. Para esa parte la vía es OpenWebNet, y en los contadores fiscales de compañía es IEC 870-5-102.
Y hay un límite que no es de arquitectura sino de seguridad, y conviene decirlo sin rodeos: Modbus no tiene autenticación, ni cifrado, ni control de acceso. Cualquiera con acceso a la red o al par de RS-485 puede leer todo el mapa y, en holding registers y coils, escribir en él. El protocolo se diseñó para un bus de campo cerrado y no se puede endurecer desde dentro. Lo que se hace es contenerlo: dejar el tráfico Modbus dentro de la red de planta, no publicar el puerto 502 hacia internet ni exponer una pasarela con NAT, y sacar el dato hacia la plataforma por la conexión saliente segura del nodo. Ese es el motivo real por el que la topología importa más aquí que en cualquier otro protocolo de la lista, y es el asunto del recurso Modbus a la nube.
Convivencia con el resto de la instalación
La planta normal no habla un protocolo, habla los que le fueron cayendo, y Modbus es casi siempre el sustrato: está en el analizador del cuadro general, en los variadores de la línea y en el compresor, con independencia de lo moderno que sea el resto. Connect adquiere en paralelo por todas las vías disponibles y las lleva al mismo modelo de series temporales, de modo que en el histórico una potencia leída de un analizador por Modbus RTU, una señal de un PLC por OPC UA y un consumo de un contador fiscal por IEC 870-5-102 quedan al mismo nivel. Nadie tiene que saber de qué protocolo vino un dato para poder usarlo.
Las dos variantes también conviven entre sí, y la forma habitual es la mixta: los equipos con Ethernet se leen por TCP directamente y el parque serie cuelga de una o varias pasarelas que el nodo interroga por TCP resolviendo cada esclavo por su unit id. Es una topología cómoda, y el error que trae asociado es olvidar que detrás de la pasarela sigue habiendo un bus lento: la cadencia de esos equipos la marca el RS-485, no el Ethernet.
La migración, cuando se plantea, casi nunca consiste en sustituir Modbus. Lo que ocurre es que los equipos nuevos entran hablando OPC UA o publicando por MQTT y el parque Modbus se queda como está mientras dure, que suelen ser décadas. Por eso la recomendación es no plantear la integración como un proyecto de homogeneización de protocolos, que es caro y no lo pide nadie, sino como una capa de adquisición que acepta lo que hay. Cuando esa capa existe, sustituir un analizador o un variador deja de ser un problema de datos y pasa a ser un cambio de mapa.
Sobre esa base ya trabajan los módulos de la plataforma, la definición neutra del protocolo está en el glosario industrial, y el proyecto de ingeniería que implanta la capa es integración OT e IT.