¿Qué causa un Modbus función ilegal (excepción 01)?

Síntoma: el esclavo no implementa esa función

El síntoma es que el esclavo responde, pero su respuesta es un rechazo que lleva el código de excepción 01. En la respuesta el dispositivo repite su código de función con el bit alto activado y devuelve 01, lo que significa específicamente que no reconoce o no implementa el código de función que envió. Note que sí respondió, así que la comunicación, el cableado, la dirección de unidad y el armado de tramas funcionan lo bastante bien para que el dispositivo conteste; el dispositivo solo se niega a hacer la operación particular que solicitó. Esto acota el problema de forma tajante al propio código de función y no al enlace ni al destino.

Esto es lo que separa a la excepción 01 de las otras excepciones comunes con las que la gente la confunde. La excepción 02, dirección de datos ilegal, significa que la función es soportada pero el registro que pidió no es válido en el dispositivo. La excepción 03, valor de datos ilegal, significa que la función y la dirección están bien pero el valor o la cantidad que suministró está fuera de rango. La excepción 01 es más fundamental que cualquiera de las dos: el dispositivo ni siquiera llega a la cuestión de qué registro o qué valor, porque no realiza la función que nombró en absoluto. Así que si ve 01, revisar el mapa de registros por la dirección correcta o recortar su valor está fuera de lugar, ya que lo que se rechaza es la operación misma.

Como el dispositivo sí respondió, vale la pena confirmar que en verdad está hablando con el dispositivo previsto antes de suponer que la función no es soportada. Una petición mal enrutada, donde el identificador de unidad cae en un dispositivo distinto del que espera, puede producir una excepción 01 si ese otro dispositivo no soporta la función aunque el previsto sí lo haría. Esto es especialmente fácil de encontrar detrás de un gateway o en una línea serial compartida con varios esclavos. Así que parte de leer bien el síntoma es verificar que la respuesta viene del dispositivo de cuyo soporte de función usted depende, y no de un vecino que casualmente responde a ese ID de unidad.

Disparadores comunes: función de lectura equivocada, de escritura equivocada y gateways

El disparador clásico es sondear con la función de lectura equivocada para el tipo de registro. Modbus separa los registros de retención, leídos con el código de función 03, de los registros de entrada, leídos con el código de función 04, y un dispositivo que expone sus datos como registros de entrada rechazará un sondeo con el código de función 03 con excepción 01, y viceversa. Un sondeador configurado para 03 contra un dispositivo que solo tiene registros de entrada, o para 04 contra un dispositivo que solo tiene registros de retención, produce un rechazo limpio de función ilegal aunque los datos estén justo ahí bajo la otra función. Esta es una de las causas reales más frecuentes y es fácil de corregir una vez que conoce el tipo de registro que usa el dispositivo.

Las escrituras tienen su propia versión del mismo problema. Modbus ofrece escrituras de un registro con el código de función 06 y escrituras de varios registros con el código de función 16, y no todo dispositivo implementa ambas. Un dispositivo que solo acepta escrituras de un registro rechazará una escritura múltiple del código de función 16 con excepción 01, así que un maestro que siempre usa 16, incluso para escribir un registro, falla contra ese dispositivo. Lo mismo aplica a las funciones de bobina, donde un dispositivo podría soportar la escritura de una bobina 05 pero no la escritura de varias bobinas 15, o podría no implementar el acceso a bobinas en absoluto. Elegir una función de escritura que el dispositivo no implementa da una función ilegal siempre, sin importar la dirección o el valor.

Los gateways de protocolo son el tercer disparador común y el más engañoso, porque el dispositivo detrás del gateway puede soportar la función perfectamente mientras que el gateway no la deja pasar. Un gateway Modbus TCP a serial, un convertidor serial o un puente de protocolo puede estar configurado o construido para reenviar solo un subconjunto de códigos de función, filtrando o rechazando el resto, de modo que una petición que tendría éxito si se enviara directo al dispositivo regresa como excepción 01 desde el gateway. Vale la pena sospecharlo cada vez que una función que la documentación del dispositivo claramente soporta es sin embargo rechazada, porque el rechazo puede venir de la caja intermedia y no del dispositivo mismo.

Ruta de decisión y autoselección de la función correcta en una plataforma

Trabájelo en orden. Primero, abra el mapa de registros del dispositivo y anote qué funciones soporta y qué tipo de registro usa cada bloque de datos, porque ese documento es la autoridad sobre qué funcionará y qué no. Si sus datos están en registros de entrada, sondee con el código de función 04; si están en registros de retención, sondee con el 03; y haga coincidir las lecturas de bobinas y entradas discretas de la misma manera. Segundo, si la petición que falla es una escritura, revise si el dispositivo implementa la función de escritura que usa, y cambie una escritura múltiple del código de función 16 por una escritura de un registro del código de función 06 si el dispositivo solo soporta escrituras de un registro. Con solo alinear el código de función al conjunto soportado por el dispositivo se resuelve la gran mayoría de los casos de excepción 01.

Si alinear el código de función no lo corrige, verifique el enrutamiento y la trayectoria. Confirme que el identificador de unidad está llegando al dispositivo que usted cree, ya que una petición mal enrutada puede provocar una excepción 01 de un esclavo distinto que carece de la función. Si hay un gateway o convertidor en la trayectoria, revise si reenvía el código de función que necesita, y pruebe hablando con el dispositivo tan directamente como su montaje lo permita para ver si el rechazo sigue al dispositivo o se queda con el gateway. Si la trayectoria directa funciona y la del gateway no, el filtrado de funciones del gateway es su culpable, y la solución está en la configuración del gateway y no en el dispositivo ni en el sondeo.

La forma de no elegir nunca códigos de función a mano es dejar que la plataforma los elija a partir del tipo de registro, que es lo que hace un SCADA en la nube bien diseñado. En una plataforma como Merobix, los drivers seleccionan el código de función correcto por tipo de registro de forma automática, usando el código de función 04 para registros de entrada y el 03 para registros de retención en las lecturas, y eligiendo una función de escritura apropiada para el registro, de modo que un ingeniero define qué es un punto en vez de qué función cruda enviar. Eso elimina la fuente más común de excepción 01, ya que el desajuste entre la función que envió y el tipo de registro simplemente no surge, y mantiene la configuración legible porque los puntos se describen por lo que representan y no por la mecánica del protocolo. Hacer coincidir la función con el dispositivo a mano corrige el rechazo inmediato, y dejar que la plataforma autoseleccione la función evita que los errores de función ilegal regresen.

Preguntas frecuentes