Orden de bytes (endianness) en registros Modbus

Por qué un flotante necesita dos registros y un acuerdo

Un registro Modbus contiene exactamente 16 bits, suficiente para un entero sin signo de 0 a 65535 pero no para los números de punto flotante que la mayoría de los valores de proceso necesita. Un flotante de precisión simple y un entero de 32 bits ocupan cuatro bytes cada uno, así que se transmiten en dos registros consecutivos. Esa división es donde empieza el problema. Los cuatro bytes tienen un significado definido solo cuando ambos extremos acuerdan qué registro lleva la mitad más significativa y, dentro de cada registro, qué byte va primero.

El estándar Modbus sí especifica orden big-endian para los dos bytes dentro de un registro: el byte alto se envía antes que el byte bajo. Lo que nunca estandarizó es el orden de los dos registros que componen un valor de 32 bits. Un dispositivo pone la palabra de orden alto en el primer registro y la de orden bajo en el segundo, lo que suele llamarse orden de palabras big-endian. Otro dispositivo lo invierte y envía primero la palabra baja, comúnmente etiquetado como word-swapped u orden de palabras little-endian. Algunos dispositivos además intercambian los bytes dentro de cada registro, dando cuatro combinaciones posibles para los mismos cuatro bytes.

Como el protocolo deja esto abierto, los fabricantes tomaron decisiones distintas y no hay manera de inferir la correcta a partir de los bytes crudos por sí solos. Dos registros que leen, digamos, 0x42C8 y 0x0000 podrían representar 100.0 o un número totalmente diferente según el arreglo que usó el emisor. Al lado receptor hay que decirle, explícitamente, cómo rearmar los cuatro bytes antes de interpretarlos como flotante o entero largo.

Las cuatro combinaciones y cómo decodificarlas

En la práctica hay cuatro arreglos de orden de bytes que la gente describe con abreviaturas como ABCD, CDAB, BADC y DCBA, donde cada letra es un byte del valor de cuatro bytes en el orden en que llega. ABCD es big-endian directo: palabra alta primero, byte alto primero, y se decodifica directamente. CDAB mantiene intactos los bytes de cada registro pero intercambia los dos registros, que es el clásico word swap visto en muchos PLC y computadores de flujo. BADC intercambia los bytes dentro de cada registro pero conserva el orden de los registros, y DCBA invierte todo en little-endian completo. Un totalizador o un flujo que se ve correcto en magnitud pero corrido por órdenes de magnitud, o que aparece como NaN, casi siempre está a una de estas permutaciones de distancia de lo correcto.

Decodificar es un rearmado en dos pasos. Primero se leen los dos registros como palabras crudas de 16 bits sin interpretarlas. Luego se colocan sus cuatro bytes en un buffer de cuatro bytes en el orden que usa el dispositivo, y solo entonces se convierte ese buffer a flotante o entero de 32 bits. La mayoría del software de SCADA y de gateways expone esto como un ajuste por punto - un menú para orden de palabras y orden de bytes, o una sola entrada de tipo de dato como float-CDAB - de modo que usted elige el arreglo en lugar de escribir código. La disciplina clave es elegir ese ajuste por familia de dispositivos, porque dos dispositivos en la misma línea serial pueden usar legítimamente órdenes diferentes.

La forma confiable de encontrar la combinación correcta es forzar un valor conocido. Pida al dispositivo que reporte algo que usted pueda predecir - un valor de ingeniería fijo, un totalizador que pueda leer en su pantalla local, o un registro de prueba que el manual documente - y pruebe los cuatro órdenes hasta que el número decodificado coincida. La documentación del fabricante normalmente indica el orden, pero es común que un manual sea ambiguo o que una revisión de firmware difiera, así que la confirmación en vivo contra una lectura conocida es la verificación confiable.

El orden de bytes al conectar dispositivos de campo al SCADA en la nube

Cuando un computador de flujo, una RTU o un PLC se incorpora a una plataforma SCADA en la nube, el orden de bytes es una de las primeras cosas que hay que fijar para cada punto multiregistro. Una presión que se lee plausible pero un flujo que se decodifica como un número grande aleatorio es la firma de un desajuste de orden de palabras en los valores de 32 bits, no una falla de sensor. Como los bits de estado enteros suelen usar registros individuales y se ven bien, el error se esconde específicamente en los flotantes y totalizadores que más importan para la contabilidad de producción.

En un despliegue estilo Merobix la corrección vive en la configuración del punto, no en el cableado de campo. Cada punto Modbus se mapea con un tipo de dato y un orden de palabras o bytes explícitos, así que un dispositivo que usa flotantes word-swapped se decodifica correctamente en la plataforma sin tocar el dispositivo. Hacer esto bien una vez, por perfil de dispositivo, significa que cada valor de esa familia de dispositivos aterriza correctamente y se mantiene correcto conforme se agregan más sitios idénticos.

Lo que está en juego crece con la transferencia de custodia y la medición de asignación, donde un totalizador mal decodificado no es un detalle cosmético sino un volumen equivocado en un reporte. Por eso la puesta en marcha de un dispositivo nuevo incluye leer un total conocido en su pantalla local y confirmar que el valor en la nube coincide antes de que el punto entre en servicio. Confirmar el orden de bytes desde el principio convierte toda una clase de problemas silenciosos de calidad de datos en un paso único de configuración en lugar de un misterio recurrente en las tendencias.

Preguntas frecuentes