Cómo corregir un valor de registro Modbus equivocado

Síntoma y qué descarta

El síntoma definitorio es que el transporte está sano pero el valor está equivocado. Usted obtiene una respuesta en cada sondeo, la calidad del tag es buena, y no regresa ninguna excepción, así que la petición alcanzó el registro correcto y el dispositivo devolvió datos. Eso descarta de inmediato toda la familia de fallas de direccionamiento y timeout y confina el problema a la interpretación. Los bits en el registro casi con seguridad son correctos; lo que está mal es la receta que su driver usa para convertir esos dieciséis o treinta y dos bits en un número.

La forma específica en que el valor está equivocado es una pista fuerte de cuál decodificación está mal. Una lectura que está cerca de lo correcto pero corrida por exactamente un factor de diez, cien o mil apunta a un error de escala en vez de un problema a nivel de byte. Un valor que es negativo cuando el proceso no puede ser negativo, o que salta a un número enorme cerca del tope del rango, apunta a confusión de con signo frente a sin signo. Un número que es basura completa, cambia terriblemente por un cambio real pequeño, o aparece como NaN apunta al orden de palabras o de bytes, en especial en un valor que abarca dos registros. Leer el sabor de la equivocación acota cuál corrección probar primero.

El movimiento diagnóstico más útil es establecer una referencia. Lea el mismo valor en la propia pantalla local del dispositivo, o comande el dispositivo a un estado conocido, para tener un número verdadero hacia el cual decodificar. Con una referencia en mano todo el ejercicio se vuelve determinista: usted ajusta la decodificación y ve si el número converge hacia la verdad, en vez de adivinar a ciegas. Anote el contenido crudo del registro que su driver recibió, porque los mismos bits crudos decodificados de cuatro maneras distintas es exactamente como distingue un problema de orden de palabras de uno de signo de uno de escala.

Orden de bytes, orden de palabras y valores repartidos

Cualquier valor mayor que dieciséis bits abarca dos registros, y cómo se ordenan esas piezas es la causa más común de basura. Hay dos preguntas independientes. El orden de bytes es cuál de los dos bytes va primero dentro de un solo registro de dieciséis bits, y el orden de palabras es cuál de los dos registros va primero cuando se unen en un valor de treinta y dos bits. Como estas son independientes, los cuatro bytes de un valor de treinta y dos bits pueden ensamblarse en una de cuatro permutaciones, y solo una coincide con cómo el dispositivo los dispuso. Elija la permutación equivocada y obtiene un número terriblemente equivocado o, para un flotante, un NaN. Las páginas de concepto de orden de bytes y de intercambio de palabras describen el mecanismo; la corrección en la práctica es probar las permutaciones contra su valor de referencia.

Para un flotante de 32 bits repartido en dos registros, esto es inevitable porque no hay convención universal de ordenamiento entre fabricantes, así que un flotante que se lee perfecto en un dispositivo puede necesitar las palabras intercambiadas en otro. La señal es un flotante que es sinsentido o NaN a pesar de buenas comunicaciones; la corrección es voltear el orden de palabras en el driver, y si sigue mal, el orden de bytes, hasta que aparezca el valor de referencia. Muchos drivers exponen esto directamente como una elección de tipo de dato, como flotante con intercambio de palabras frente a flotante sin él, y elegir la variante correcta suele ser la corrección completa. La página de concepto dedicada al flotante en dos registros cubre este caso a fondo.

El mismo problema de ordenamiento aplica a los enteros de 32 bits, pero el síntoma se ve distinto porque un entero decodifica a un número de aspecto plausible en vez de NaN. Un contador de horas de operación o un totalizador que abarca dos registros con las palabras intercambiadas puede leerse como un total enorme o negativo que no es obviamente basura, así que es fácil pasarlo por alto. Trate cualquier entero de dos registros igual: confirme el orden de palabras contra un conteo conocido, y solo confíe en el total una vez que la decodificación coincida con el propio valor mostrado del dispositivo. Equivocar el orden de palabras de un totalizador corrompe en silencio datos acumulados, lo cual es mucho más dañino que una lectura obviamente rota.

Signo, escala y datos SCADA confiables

La interpretación con signo frente a sin signo es una falla de decodificación sutil porque ambas lecturas parecen números reales. Un solo registro de dieciséis bits puede representar un valor con signo, que llega a negativos, o un valor sin signo que solo va positivo, y los mismos bits significan dos números distintos según cuál elija. El síntoma clásico es un valor que se lee correcto en la mayor parte de su rango pero salta a un número positivo grande, o a un número negativo, en un extremo. Una temperatura que debería leer un negativo pequeño en invierno pero en su lugar lee un positivo enorme es un valor con signo decodificado como sin signo. Haga coincidir el tipo de dato del driver con lo que especifique el mapa del fabricante, y verifique en un punto donde el signo de verdad importe.

Los errores de escala son los más fáciles de detectar y de corregir una vez que tiene una referencia. Muchos dispositivos envían un entero que representa un valor escalado, así que una presión de 12.34 podría llegar como el entero 1234 con una división implícita entre cien, o un valor podría llevar un multiplicador de unidad de ingeniería que el fabricante documenta. Si su lectura está corrida por un factor limpio de diez, cien o mil respecto a la verdad, el factor de escala está faltante o equivocado, no el orden de bytes. Aplique el multiplicador o divisor que el mapa del fabricante especifique, y confirme que el valor caiga en la referencia. Como los errores de escala producen un número de aspecto plausible, pueden quedar sin detectar hasta que alguien compara contra un manómetro local, que es otra razón por la que una lectura de referencia es el ancla de todo el procedimiento.

Para SCADA y monitoreo en la nube, una falla de valor equivocado es más peligrosa que una falla de comunicaciones obvia precisamente porque el tag se ve bien. Un número corrupto con buena calidad fluye directo a tendencias, alarmas, reportes y cualquier control que lo consuma, y un totalizador silenciosamente intercambiado puede corromper volúmenes acumulados que alimentan la facturación o la conciliación. Una plataforma SCADA en la nube como Merobix almacenará fielmente lo que produzca la decodificación, así que la salvaguarda es validar cada tag escalado o de varios registros contra la propia pantalla del dispositivo en la puesta en marcha y verificar los rangos con sensatez después. Fijar el tipo de dato, el orden de palabras, el signo y la escala antes de que un sitio entre en operación es lo que mantiene confiables los números remotos, ya que ningún operador puede mirar de reojo un manómetro en un sitio que nunca visita.

Preguntas frecuentes