¿Qué es un código de excepción Modbus?

Volver al glosario

Cómo se construye una respuesta de excepción

Una respuesta Modbus normal repite el código de función de la petición y lleva los datos solicitados. Una respuesta de excepción es a propósito distinguible de una normal: el dispositivo activa el bit alto del código de función de modo que, por ejemplo, una petición con código de función 03 regresa en su forma marcada como excepción, y la sigue con un solo byte de código de excepción en lugar de datos. Un maestro que decodifica respuestas puede detectar una excepción de inmediato por ese código de función marcado y luego leer la razón de un byte.

Este diseño significa que una excepción es una respuesta positiva, no un tiempo agotado. El dispositivo sí recibió la petición, la entendió lo bastante bien para rechazarla, y le dijo al maestro por qué - lo cual es fundamentalmente distinto de no obtener respuesta alguna. Una no respuesta por lo general apunta a un problema de cableado, direccionamiento o comunicaciones: la petición nunca alcanzó un dispositivo, o alcanzó al equivocado, o la respuesta se perdió. Una excepción apunta hacia adentro, al contenido de la petición, porque el dispositivo está presente y hablando y declinando específicamente lo que se le pidió.

Mantener clara esa distinción es el primer paso en la resolución de problemas. Si un sondeo simplemente agota el tiempo, el técnico mira la capa física y el direccionamiento que enruta la petición a un dispositivo. Si el sondeo devuelve una excepción, el técnico en cambio mira qué se pidió - el código de función, la dirección, la cantidad, o la salud del dispositivo - porque la excepción es la propia explicación del dispositivo de por qué la petición fue inaceptable. Los cuatro códigos de excepción comunes cada uno estrechan esa explicación a una causa específica.

Decodificar los códigos de excepción comunes

La excepción 01, función ilegal, significa que el dispositivo no soporta el código de función que se envió. La petición alcanzó un dispositivo real que entendió la trama pero no tiene implementación para esa operación - por ejemplo, emitir un código de escritura de múltiples registros a un dispositivo que solo implementa escrituras de un solo registro, o enviar una función que el dispositivo simplemente no ofrece. La solución es usar un código de función que el dispositivo soporte, que su documentación o mapa de registros debería listar. Esta excepción dice que el verbo estaba mal, no la dirección.

La excepción 02, dirección de datos ilegal, significa que la dirección solicitada no existe en el dispositivo, o que el rango solicitado se sale del final de lo que el dispositivo implementa. Esta es una de las excepciones más comunes durante la puesta en marcha, y por lo general apunta a un hueco genuino - el registro que el mapa prometía no está realmente ahí - o a un corrimiento por uno entre el número de registro humano y el desplazamiento del protocolo en el cable. La excepción 03, valor de datos ilegal, es distinta: la dirección está bien, pero el valor o la cantidad en la petición está fuera del rango que el dispositivo acepta, como pedir demasiados registros a la vez o escribir un valor que el dispositivo rechaza. La excepción 03 es sobre la carga útil, no sobre la ubicación.

La excepción 04, falla del dispositivo esclavo, significa que el dispositivo intentó procesar la petición pero topó con un problema interno - una falla de hardware, un sensor fallado detrás del registro, o un error irrecuperable en el dispositivo mismo. A diferencia de 01, 02 y 03, que apuntan a la petición, la excepción 04 apunta al dispositivo: la petición era legítima pero el dispositivo no pudo llevarla a cabo. Cuando un sondeo que funcionaba ayer empieza a devolver excepción 04, el dispositivo de campo en lugar del mapa Modbus es el lugar donde mirar, porque el dispositivo está reportando que algo dentro de él salió mal.

Usar las excepciones para diagnosticar un sondeo muerto en el campo

Los códigos de excepción convierten la resolución de problemas de adivinanza en un árbol de decisión, y eso es especialmente valioso en sitios remotos de petróleo y gas donde un técnico puede estar leyendo el error desde un cuarto de control en lugar de estar parado en la RTU. Si el sondeo devuelve excepción 01, el mapa tiene el código de función equivocado y la solución está en la configuración del SCADA. Si devuelve 02, la dirección está mal o no existe, lo que manda al técnico de vuelta a conciliar la lista de registros del fabricante con lo que el maestro está sondeando. Si devuelve 03, la petición está pidiendo demasiado o escribiendo un valor inválido, así que la cantidad o el valor escrito necesita ajuste. Si devuelve 04, el dispositivo de campo mismo ha fallado y necesita atención en sitio.

Una plataforma SCADA en la nube hace ese diagnóstico remoto e inmediato. Cuando Merobix sondea un dispositivo de campo por Modbus y recibe una excepción, puede hacer aflorar qué código regresó, así que la persona que resuelve el problema sabe si el problema está en la configuración del tag, el mapa de registros, los parámetros de la petición, o el hardware del dispositivo - sin un viaje en camioneta para averiguarlo. Esa distinción es la diferencia entre arreglar un error de mapeo desde un teclado y despachar a un técnico por un dispositivo que genuinamente ha fallado.

El hábito práctico es tratar el código de excepción como la primera pista en lugar de reiniciar el sondeo a ciegas. Los códigos 01, 02 y 03 casi siempre se arreglan en la configuración - el verbo equivocado, la dirección equivocada, o el valor equivocado - y un técnico puede resolverlos editando el mapa y resondeando. El código 04 es el que por lo general significa intervención física, porque el dispositivo está reportando su propia falla. Leer el código antes de actuar ahorra el esfuerzo desperdiciado de revisar de nuevo el cableado cuando el dispositivo claramente está respondiendo, o de editar un mapa cuando el problema real es un sensor fallado en el campo.

Preguntas frecuentes