Modbus TCP conecta pero lee ceros: cómo corregirlo
La luz de conexión está en verde, el puerto 502 acepta, los sondeos tienen éxito sin excepciones, y cada valor es cero. Este síntoma engaña a la gente porque todo en la capa de red está genuinamente bien; el maestro simplemente lee los datos equivocados, o las direcciones correctas en el destino equivocado. Esta guía recorre las causas en orden de probabilidad: área de registro equivocada, direccionamiento con desfase de uno, enrutamiento de ID de unidad, y leer un dispositivo que no es el que usted cree.
Corregir Modbus TCP que lee ceros en una línea: Cuando Modbus TCP conecta pero lee ceros, la sesión TCP solo prueba una trayectoria de red hacia algo que escucha en el puerto; no dice nada sobre si sus registros son los correctos. Las causas usuales son sondear el área de registro equivocada, como registros de retención con el código de función 3 cuando los datos viven en registros de entrada bajo el código de función 4, un desfase de uno entre direcciones documentadas como 40001 y la dirección base cero en el bus, un ID de unidad que un gateway enruta a nada, o un sondeo que cae en una región válida pero no usada que el dispositivo responde con gusto con ceros en vez de una excepción.
Primeras revisiones: pruebe que está leyendo datos reales
Empiece encontrando un registro que pueda garantizar que no es cero y conviértalo en su referencia. Un valor de proceso en vivo mostrado en la pantalla local del dispositivo, un registro de versión de firmware, o un ID de dispositivo del mapa de registros, todos sirven. Si puede leer esa referencia correctamente, el direccionamiento funciona en lo fundamental y los ceros en otras partes son un detalle de mapeo. Si incluso la referencia lee cero, el problema es estructural - área equivocada, offset equivocado o destino equivocado - y ha acotado la búsqueda antes de cambiar nada.
La prueba estructural más rápida es intentar la misma dirección con la otra función de lectura. Muchos dispositivos mantienen sus datos de proceso en registros de entrada, leídos con el código de función 4, mientras que el maestro predetermina a registros de retención con el código de función 3. Ambas lecturas pueden tener éxito, porque ambas áreas existen, pero una de ellas está vacía. Intercambiar FC3 por FC4, o al revés, revela al instante si ha estado sondeando un área válida pero vacía todo el tiempo.
Desfase de uno y la convención de 40001
La documentación Modbus tradicionalmente numera los registros de retención desde 40001, pero la dirección transmitida en el bus es de base cero: el registro 40001 es la dirección 0 en la trama del protocolo. Los fabricantes se dividen sobre qué convención usan su documentación y su configuración de driver, así que el mismo mapa puede ingresarse de dos maneras, una de ellas equivocada por exactamente un registro. La pista son datos que parecen corridos en vez de ausentes: un valor que espera en un tag aparece en su vecino, o una lectura en bloque devuelve números plausibles empezando un lugar tarde.
Cuando los registros circundantes resultan estar vacíos, un desfase de uno se muestra como ceros en vez de datos corridos, por lo cual pertenece también a la investigación de ceros. La prueba es barata: desplace la dirección sondeada en uno en cada dirección y vea si aparece el valor de referencia. Una vez que un registro se alinea, aplique la misma corrección a todo el mapa en vez de rastrear tag por tag, porque el error de convención es uniforme.
Enrutamiento de ID de unidad y trampas de destino equivocado
En un dispositivo Modbus TCP simple el campo de ID de unidad a menudo se ignora: el dispositivo responde cualquier ID que envíe el maestro. Detrás de un gateway la historia se invierte: el gateway usa el ID de unidad para seleccionar qué dispositivo serial aguas abajo recibe la petición. Envíe un ID que el gateway mapea a nada y, según su diseño, puede recibir una excepción, un timeout, o una respuesta generada localmente llena de ceros. Si sus sondeos atraviesan cualquier gateway serial o convertidor de protocolo, verifique el ID de unidad contra la tabla de mapeo del gateway en vez de la documentación del dispositivo final sola.
La última trampa es un hardware que responde y no es su dispositivo en absoluto. Una dirección IP duplicada, una entrada ARP obsoleta tras un cambio de dispositivo, una regla NAT apuntando al host interno equivocado, o un simulador de prueba que alguien dejó corriendo pueden aceptar su conexión de forma convincente y devolver datos vacíos. Leer un registro de identificación de dispositivo o número de serie y compararlo contra la etiqueta de la unidad física resuelve la cuestión. Vale la pena hacer esto temprano en sitios con muchos controladores similares, donde un error de lista de direcciones lo pone en el pozo equivocado por completo.
Cuándo escalar
Si el registro de referencia lee correctamente a través de cada combinación de función y offset y aun así no aparecen datos de proceso, el propio mapa de registros es el sospechoso restante. La documentación del fabricante sí se desvía de la realidad del firmware, en especial entre versiones de firmware, y algunos dispositivos requieren un paso de configuración antes de poblar su mapa Modbus en absoluto. En ese punto el escalamiento productivo es al fabricante del dispositivo con detalles: el código de función exacto, la dirección a nivel de bus, el ID de unidad y la respuesta que observó, que es una captura de cinco minutos con cualquier cliente de prueba Modbus.
Los ceros que llegan al historiador son peores que los huecos, porque parecen datos. Una plataforma SCADA como Merobix ayuda a contener el daño al hacer visible el estado de comunicación por dispositivo y al permitirle contrastar tags nuevos contra valores en vivo durante la puesta en marcha, de modo que un error de mapa se atrapa mientras alguien aun lo mira en vez de semanas después en un reporte. El hábito que previene toda la clase de problema es validar un registro de referencia conocido como no cero en cada dispositivo nuevo antes de confiar en el resto de su mapa.
Preguntas frecuentes
¿Por qué mi sondeo Modbus tiene éxito pero devuelve puros ceros?
Porque un sondeo exitoso solo significa que un dispositivo respondió una petición bien formada. Si la petición direccionó un área de registro que existe pero no contiene nada - el área equivocada del código de función, un offset corrido en uno, o una región que el dispositivo reserva pero no puebla - el dispositivo devuelve ceros sin ningún error. La conexión y el protocolo funcionan; el direccionamiento apunta a un espacio vacío.
¿Un dispositivo debería devolver una excepción en vez de ceros para un registro vacío?
Solo si la dirección es realmente inválida en su mapa. La especificación Modbus define la excepción 02, dirección de datos ilegal, para peticiones fuera de los rangos implementados del dispositivo, pero muchos dispositivos implementan bloques contiguos grandes de registros y legítimamente responden con ceros para cualquier dirección dentro del bloque que ningún dato pueble. Por eso los ceros no pueden leerse como prueba de que la dirección era correcta, y por eso un registro de referencia conocido como no cero es la prueba confiable.
¿Cómo sé si el ID de unidad importa para mi dispositivo Modbus TCP?
Revise si hay algo entre el maestro y el dispositivo final. Al hablar directo con un dispositivo Modbus TCP nativo, el ID de unidad se ignora con frecuencia y casi cualquier valor funciona. Al hablar a través de un gateway hacia dispositivos seriales, el ID de unidad selecciona el destino aguas abajo, y un ID equivocado significa una respuesta equivocada o ausente. La tabla de mapeo de ID de unidad del gateway, no el manual del dispositivo final, es la autoridad en ese caso.
Fuentes y lecturas
Referencias primarias de los organismos de normas y reguladores que definen este tema:
- Modbus Specifications - Modbus Organization
Servicios de automatización
¿Necesita convertir esta información en un sistema que funcione?
Merobix integra SCADA, programa PLC Allen-Bradley y Siemens, y diseña y fabrica tableros de control industrial.
Las solicitudes de reunión se revisan antes de confirmarse.