Cómo corregir un Modbus valor de datos ilegal (excepción 03)

Síntoma: qué significa realmente la excepción 03

El síntoma es preciso: el esclavo recibió y entendió su petición, reconoció el código de función, aceptó la dirección, y luego rechazó la petición porque un valor de su campo de datos no estaba permitido. En la respuesta de excepción Modbus el esclavo repite el código de función con su bit alto activado y devuelve el código de excepción 03. La palabra clave es valor. El dispositivo le está diciendo que algo en el contenido numérico de la petición está fuera del rango que permite, no que no pudo encontrar el registro y no que no soporte la operación.

Por esto la excepción 03 se confunde tan seguido con la excepción 02, dirección de datos ilegal. Ambas regresan como un rechazo a una lectura o escritura, y ambas pueden verse idénticas desde afuera si usted solo observa que la petición falla. Pero significan cosas opuestas. La excepción 02 dice que la dirección o el rango de direcciones que pidió no es válido en este dispositivo, así que el problema es hacia dónde apunta. La excepción 03 dice que la dirección estaba bien pero el valor o la cantidad que suministró no es aceptable, así que el problema es qué envía. Corregir una excepción 03 rastreando el mapa de registros por la dirección correcta, como haría con una 02, no lleva a ningún lado, porque la dirección nunca fue el problema.

Ayuda notar qué peticiones tienden a producir cada código. La excepción 03 aparece más en escrituras, en especial en escrituras de un solo registro con el código de función 06 y en escrituras de varios registros con el código de función 16, porque estas llevan un valor o una cantidad que el esclavo valida contra sus propios límites. Una lectura que pide demasiados registros a la vez también puede provocar una excepción 03 en algunos dispositivos, porque la cantidad solicitada excede lo que el protocolo o el dispositivo permite en una transacción. En todos los casos el código apunta al contenido numérico de la petición, así que ahí debe enfocarse la investigación.

Causas probables: valores fuera de rango, conteos de bytes y orden de palabras

La causa más directa es escribir un valor fuera del mínimo o máximo permitido del registro. Muchos registros de dispositivo aceptan solo un rango definido, como un setpoint que debe quedar entre límites de ingeniería, un registro de modo que acepta solo un puñado de códigos enumerados, o un porcentaje que debe ir de cero a cien. Envíe algo fuera de ese rango, incluso un valor perfectamente válido como número, y un esclavo bien portado lo rechaza con excepción 03 en vez de aceptar un ajuste inválido. Esto es común cuando un sistema de nivel superior empuja un setpoint que el operador ingresó sin recortarlo a lo que el dispositivo de campo aceptará.

Una segunda causa es una petición de escritura múltiple mal formada, con más frecuencia en el código de función 16. Esa función lleva tanto una cantidad de registros como un conteo de bytes, y el conteo de bytes tiene que ser igual al doble de la cantidad para registros de dieciséis bits. Si esos discrepan, o si la cantidad es cero o mayor de la que el dispositivo permite en una escritura, el esclavo ve una petición inconsistente o fuera de rango y devuelve excepción 03. Esto puede venir de un error de driver, una trama construida a mano, o un desfase de uno en cómo se empaca un valor, y es fácil de pasar por alto porque la dirección es correcta y solo el armado de los datos está mal.

Una causa más sutil es el orden de palabras, o endianness, en valores de varios registros. Un valor de treinta y dos bits abarca dos registros, y si el maestro envía las dos palabras en el orden que el dispositivo no espera, un valor que debería ser pequeño puede quedar reensamblado por el esclavo en un número enorme muy fuera del rango del registro. La escritura falla entonces con excepción 03 aunque su valor previsto fuera perfectamente razonable, porque el dispositivo valida el valor deformado que en realidad recibió. Lo mismo pasa con valores de punto flotante repartidos en registros cuando el orden de bytes o de palabras está mal. Por eso un setpoint que se ve bien en su pantalla puede aun disparar un valor de datos ilegal: el número en el bus no es el número que usted cree.

Pasos para aislarla y configurar límites de escritura en un SCADA en la nube

Empiece leyendo el registro de vuelta antes de intentar escribirlo. Leer el valor actual le dice que el registro existe y es accesible, lo cual descarta de inmediato un problema de dirección y confirma que se trata de un problema de valor, y a menudo le muestra la escala y el formato que usa el dispositivo. Si la lectura tiene éxito y solo la escritura falla con excepción 03, ha probado que la dirección es buena y que el valor es el problema, que es lo más útil que puede establecer primero porque separa la 03 de la 02 de forma concluyente. Luego encuentre la especificación de rango del dispositivo en su mapa de registros o manual: el mínimo, el máximo y cualquier código enumerado permitido para ese registro, para saber exactamente qué aceptará.

Enseguida, pruebe un valor conocido como bueno. Escriba un valor que usted esté seguro de que está en rango, un setpoint de media escala o un código válido documentado, y vea si es aceptado. Si el valor conocido como bueno funciona y el suyo original no, el problema es que su valor está fuera de rango, y necesita recortarlo o corregir la escala. Si incluso el valor conocido como bueno falla, sospeche del armado: revise el conteo de bytes y la cantidad en una escritura de código de función 16, y revise el orden de palabras escribiendo un valor y leyéndolo de vuelta para ver si el dispositivo lo reensambló como usted pretendía. Un valor que se lee de vuelta como un número muy distinto o enorme es la huella de un problema de orden de palabras, e intercambiar el orden de palabras suele resolverlo.

La solución duradera es evitar que valores malos lleguen al dispositivo de campo en primer lugar, y ahí es donde configurar límites de escritura en una plataforma SCADA en la nube rinde. En una plataforma como Merobix usted puede definir el rango aceptable, la escala y el orden de palabras de cada registro una vez, de modo que un setpoint ingresado por un operador o empujado por lógica se valida y recorta antes de enviar cualquier comando, y el orden de bytes correcto se aplica de manera automática. Eso convierte la excepción 03 de una falla en tiempo de ejecución en el dispositivo en algo que la plataforma atrapa o previene por adelantado, y significa que los mismos límites se aplican de forma consistente sin importar quién o qué emita la escritura. Aislar la causa inmediata pone a funcionar la escritura actual, y codificar los límites reales del registro en la plataforma evita que los valores de datos ilegales vuelvan a ocurrir.

Preguntas frecuentes