Antes de cambiar un ajuste, capture los bytes sin procesar. Un maestro que solo muestra «tiempo de espera agotado» o «valor incorrecto» oculta las pruebas que permiten distinguir las causas siguientes. Estos son una lectura de dos registros de retención del dispositivo 1 mediante Modbus RTU y las dos respuestas posibles:
| Trama | Bytes (hexadecimales) | Significado |
|---|---|---|
| Petición | 01 03 00 00 00 02 C4 0B | Dispositivo 1, función 03, dirección inicial 0, 2 registros, CRC |
| Respuesta normal | 01 03 04 43 5C 80 00 4E 65 | 4 bytes de datos. Como flotante de 32 bits en orden ABCD, 435C 8000 representa 220,5 |
| Respuesta de excepción | 01 83 02 C0 F1 | Función 03 + 0x80, excepción 02 (dirección de datos no válida) |
La ausencia total de respuesta es el cuarto resultado. Cada resultado tiene su propia sección a continuación.
1. Sin respuesta
Un tiempo de espera agotado significa que no llegó ninguna respuesta válida. La petición no llegó intacta al dispositivo, se dirigió a una dirección a la que nadie responde, o la respuesta se perdió o llegó después de que el maestro dejara de esperar. La especificación del protocolo de aplicación (apartado 7) indica que un dispositivo no responde a una petición con error de paridad, LRC o CRC. Por tanto, un tiempo de espera agotado también puede indicar una petición dañada, no solo un dispositivo ausente.
En un bus serie (Modbus RTU), compruebe estos puntos en este orden:
- Configure la misma velocidad en baudios, paridad y bits de parada en todos los dispositivos. La especificación de la línea serie (apartado 2.5.1) establece la paridad par como valor predeterminado y exige 2 bits de parada si se desactiva la paridad. Algunos contadores vienen configurados sin paridad y con 1 bit de parada; configure el maestro para que coincida con el contador.
- Asigne a cada dispositivo una dirección única de 1 a 247. Dos dispositivos con la misma dirección responden a la vez y corrompen ambas respuestas. La dirección 0 es de difusión: los dispositivos ejecutan una escritura de difusión, pero nunca responden.
- Intercambie los dos conductores de señal en un dispositivo y vuelva a probar. Los fabricantes no utilizan de forma uniforme las etiquetas A y B.
- Asegúrese de que solo un maestro sondee el bus. Un portátil o BMS que sondea al mismo tiempo provoca colisiones.
- Compruebe el adaptador. Un adaptador USB de dos hilos sin supresión de eco devuelve al maestro su propia petición, que algunos maestros interpretan como una respuesta incorrecta. Si el adaptador tarda demasiado en desactivar su transmisor después de la petición, corta los primeros bytes de la respuesta.
- Compruebe la terminación y la polarización. Los errores CRC que aumentan con la velocidad en baudios y la longitud del cable apuntan a una terminación ausente. Los errores de trama o un primer byte espurio tras un periodo de inactividad del bus apuntan a una polarización ausente. La guía de cableado RS-485 explica ambas.
- Configure un tiempo de espera que cubra la duración de la respuesta en el cable más el tiempo de procesamiento del dispositivo. El cálculo sigue a esta lista.
En Modbus TCP, compruebe la dirección IP, el puerto (502 salvo que el dispositivo utilice otro), las reglas del cortafuegos entre el cliente y el dispositivo, y el identificador de unidad. La guía de implementación TCP (apartado 4.4.1.2) recomienda el identificador de unidad 0xFF para un dispositivo conectado directamente a la red y también admite 0. Detrás de una pasarela TCP a RTU, el identificador de unidad selecciona el dispositivo serie, de 1 a 247. Algunos dispositivos TCP directos solo responden a un valor concreto; consulte su manual.
La guía TCP no establece un límite de conexiones; cada dispositivo tiene el suyo. Algunos contadores admiten una sola conexión a la vez. Si un cliente desaparece sin cerrarla, por ejemplo tras un corte de alimentación, la conexión queda semiabierta y ocupa su plaza (apartado 4.2.2). Con los temporizadores TCP keepalive predeterminados que cita la guía (apartado 4.3.2), la primera sonda se envía tras 2 horas de inactividad y la pila desiste después de 8 sondas más separadas por 75 s. La plaza puede permanecer bloqueada más de 2 horas. Mientras tanto, el dispositivo rechaza conexiones nuevas o no responde a ellas. La guía recomienda que el servidor cierre su conexión más antigua cuando llega un cliente nuevo y el conjunto está lleno (apartado 4.2.1.1), pero no todos los dispositivos lo hacen. Reinicie la alimentación del dispositivo o consulte su manual para configurar un tiempo de inactividad menor.
Pruebe con la petición más pequeña que debería funcionar: un registro que exista según el mapa, utilizando la función (03 o 04) indicada en él. Utilice la calculadora CRC y LRC de Modbus para comprobar una trama RTU capturada.
Cálculo del tiempo de espera
En modo RTU, cada byte ocupa 11 bits en el cable: un bit de inicio, 8 bits de datos, un bit de paridad (o un segundo bit de parada) y un bit de parada. A 9.600 baudios, un byte tarda 1,15 ms. La lectura más grande es de 125 registros (función 03 o 04) y su respuesta contiene 255 bytes: dirección, función, número de bytes, 250 bytes de datos y CRC de 2 bytes. Esa respuesta tarda 292 ms en el cable. La petición tarda otros 9 ms y el dispositivo necesita tiempo para preparar la respuesta. Por tanto, un tiempo de espera de 200 ms falla en todas las lecturas de bloques completos, aunque el dispositivo responda correctamente.
La especificación de la línea serie (apartado 2.4.1) indica un tiempo de espera de respuesta habitual de 1 s a varios segundos a 9.600 baudios. Empiece con 1 s, mida el tiempo real de respuesta y, después, reduzca el tiempo de espera si lo requiere el presupuesto del ciclo de sondeo.
La temporización de las tramas también importa. Una trama RTU termina tras un silencio de 3,5 tiempos de carácter, equivalente a 4,0 ms a 9.600 baudios. Un intervalo de más de 1,5 tiempos de carácter dentro de una trama hace que el receptor la descarte por incompleta. Por encima de 19.200 baudios, la especificación recomienda valores fijos de 1,75 ms para el intervalo entre tramas y 750 µs para el intervalo dentro de una trama (apartado 2.5.1.1). Un maestro o convertidor que hace una pausa dentro de una trama provoca un tiempo de espera agotado sin otro síntoma. La calculadora de tiempos de Modbus RTU calcula estos valores para otras velocidades en baudios y tamaños de bloque.
2. Respuesta de excepción
Una respuesta de excepción demuestra que el dispositivo recibió la petición intacta y la rechazó. La respuesta contiene el código de función más 0x80, seguido de un código de excepción. La respuesta 83 02 significa «función 03, excepción 02»:
| Código | Nombre | Causa habitual |
|---|---|---|
| 01 | Función no válida | El dispositivo no implementa ese código de función. Algunos solo implementan 03 o solo 04 para las lecturas. Si 03 devuelve 01, pruebe 04 |
| 02 | Dirección de datos no válida | La dirección no existe, o el bloque sobrepasa el final del mapa o cruza un hueco. Un dispositivo que implementa 03 y 04, pero guarda el valor en la otra tabla, también devuelve 02 |
| 03 | Valor de datos no válido | La petición está mal formada, por ejemplo, una lectura de más de 125 registros. La especificación indica que 03 no significa que un valor escrito quede fuera del rango de la aplicación |
| 04 | Fallo del dispositivo servidor | El dispositivo falló al procesar la petición |
| 06 | Dispositivo servidor ocupado | El dispositivo está ocupado con una operación larga. Vuelva a enviar la petición más tarde |
| 0A | Ruta de pasarela no disponible | La pasarela no pudo encaminar la petición. Suele deberse a una configuración incorrecta o a una sobrecarga |
| 0B | El dispositivo de destino de la pasarela no respondió | La pasarela envió la petición, pero el dispositivo serie conectado detrás no respondió |
La especificación ofrece un ejemplo de la excepción 02. Un dispositivo con 100 registros (direcciones de 0 a 99) acepta una lectura de 4 registros desde la dirección 96. Rechaza una lectura de 5 registros desde la dirección 96, porque el registro 100 no existe. Compruebe primero la convención de direcciones (el registro 40001 corresponde a la dirección de protocolo 0) y después la longitud del bloque. Muchos contadores también rechazan un bloque que cruza un hueco en su mapa. Divida el bloque en ese punto.
No envíe la misma petición repetidamente en un bucle: el dispositivo dará siempre la misma respuesta. La excepción es el código 06: el dispositivo está ocupado y la misma petición puede funcionar más tarde.
Una escritura puede tener éxito a nivel de protocolo sin cambiar el dispositivo. Una respuesta normal a la función 06 es un eco de la petición; una respuesta normal a la función 16 (0x10) contiene la dirección inicial y la cantidad. Ninguna de las dos confirma que el dispositivo haya aplicado el valor. Vuelva a leer el registro después de escribirlo.
3. Un valor que parece correcto, pero no lo es
Una respuesta válida solo demuestra que la conexión funciona. No demuestra que el valor se haya decodificado correctamente. Si un valor es verosímil pero no coincide con la pantalla del dispositivo, compare las palabras de registro sin procesar con el mapa:
| Síntoma | Causa probable |
|---|---|
| Los valores corresponden al registro contiguo al correcto | Convención de direcciones: se han mezclado direcciones que empiezan en uno y en cero |
| Un número muy grande o un flotante próximo a cero | Se ha intercambiado el orden de las palabras de un valor de 32 bits |
| 65.526 en lugar de -10 | Un valor con signo se ha leído como valor sin signo |
| 10, 100 o 1.000 veces mayor o menor | Falta el factor de escala o se ha aplicado dos veces |
| Magnitud correcta, signo incorrecto | Convención de signos para importación y exportación |
| Valor fijo de 65.535, -1, 32.768 o -32.768, o NaN en un flotante | Un código de dato no disponible (0xFFFF, 0x8000 o 0x7FC00000) se ha interpretado como dato |
La trama al comienzo de esta guía muestra por qué es fácil pasar por alto un orden de palabras intercambiado. Las palabras 435C 8000 se decodifican como 220,5 en orden ABCD. En orden CDAB (palabras intercambiadas), se decodifican como -2,4 × 10⁻⁴¹, valor que la mayoría de las pantallas muestra como 0. Una tensión de 0 parece indicar un contador sin alimentación. En un entero, el error es evidente: un valor de 10 con las palabras intercambiadas se lee como 655.360.
El decodificador de registros Modbus muestra un par de registros en los cuatro órdenes de bytes (ABCD, CDAB, BADC y DCBA). La guía de mapas de registros explica cada campo de un mapa.
Compruebe también la corrección en un segundo estado de funcionamiento, por ejemplo, con una carga encendida y apagada, o con un valor que se vuelve negativo. Una lectura de exactamente 0 se decodifica igual en todos los órdenes de bytes; no demuestra cuál es el correcto.
4. Valores que se congelan o saltan
Si la conexión y la decodificación son correctas, pero los valores se congelan, saltan o faltan, la causa está en el sondeo.
Una pasarela puede devolver el último valor leído después de que deje de responder el dispositivo conectado detrás. Compruebe si la pasarela tiene configurado un tiempo de caducidad para los valores obsoletos. Consulte también la frecuencia de actualización del propio dispositivo en su manual. Si un registro se actualiza una vez por segundo, un sondeo más rápido devuelve el mismo valor varias veces.
Un contador de 32 bits leído en dos peticiones separadas puede combinar la palabra alta de un momento con la palabra baja del siguiente. El total salta entonces 65.536 y vuelve a su valor. Lea ambos registros en una sola petición.
En Modbus TCP, el identificador de transacción MBAP empareja cada respuesta con su petición. La guía TCP (apartado 4.4.1.3) indica que el cliente debe descartar las respuestas cuyo identificador de transacción no coincida con ninguna petición pendiente. Un cliente que ignora ese identificador puede aceptar una respuesta tardía como si fuera la de su siguiente petición. Así, el valor de un punto aparece ocasionalmente en otro.
Se producen huecos regulares cuando el ciclo de sondeo dura más que el intervalo de envío de datos. Un dispositivo desconectado empeora la situación: cada sondeo dirigido a él espera a que se agote todo el tiempo de espera, además de cada reintento. Por ejemplo, diez contadores en un bus a 9.600 baudios, cada uno leído con una petición de 60 registros, tardan unos 210 ms por contador. Ese tiempo incluye 143 ms de respuesta, 9 ms de petición, los intervalos entre tramas y 50 ms supuestos de procesamiento del dispositivo. El ciclo dura unos 2,1 s. Si un contador se desconecta con un tiempo de espera de 1 s y 2 reintentos, añade 3 s. El ciclo llega a 5,1 s y un intervalo de envío de 5 s presenta entonces huecos para los diez contadores. La guía de sondeo y reintentos explica cómo fijar este presupuesto.
Los registros duplicados o tardíos suelen originarse en la ruta de datos posterior a la pasarela. Compare el registro local de la pasarela con el sistema receptor. Un reintento también puede duplicar una lectura en el lado Modbus si la respuesta original llega después de agotarse el tiempo de espera.
Cerrar la incidencia con pruebas
Una vez corregido el fallo, registre:
- el síntoma, junto con la petición y respuesta sin procesar;
- la causa encontrada y el único cambio realizado;
- la prueba que después funcionó, en dos estados de funcionamiento;
- una prueba con un dispositivo apagado, para demostrar que los demás siguen enviando datos.
Consérvelo en el acta de aceptación de la guía de puesta en marcha de Modbus RS-485.
Diagnóstico en Edge
Edge comprueba una conexión Modbus por etapas. Para Modbus TCP, la prueba de conexión hace ping al equipo, resuelve su nombre y abre una conexión TCP al puerto; muestra el resultado y la latencia de cada paso. El resultado del ping es orientativo, porque muchos dispositivos y cortafuegos bloquean ICMP. La prueba se supera cuando se abre la conexión TCP. Para una conexión serie, comprueba que el puerto serie existe y que es un dispositivo serie. No demuestra que responda un dispositivo del bus. Eso lo comprueba la prueba del sensor: envía una lectura real con el identificador de unidad, el código de función (01 a 04) y la dirección introducidos, y espera hasta 5 s por la respuesta. Después aplica las opciones de intercambio de palabras y bytes y muestra el valor decodificado, de modo que pueda comparar los órdenes de bytes con la pantalla del dispositivo. Una vez añadido el dispositivo, cada sensor muestra una cifra de calidad de datos: el porcentaje de lecturas esperadas que llegaron en los últimos 15 minutos. Utilice las tres pruebas en ese orden. La primera que falla indica dónde está el problema.
Esta guía forma parte de la serie sobre Modbus y RS-485.
Preguntas frecuentes
¿Por qué no responde mi dispositivo Modbus?
En un bus serie, las causas habituales son una velocidad en baudios, paridad o bits de parada incorrectos; una dirección de dispositivo incorrecta; conductores A/B intercambiados; un segundo maestro en el bus; o una trama dañada: el dispositivo no responde a una trama con error CRC. Un tiempo de espera del maestro menor que la duración de la respuesta también parece silencio. En Modbus TCP, compruebe la dirección IP, el puerto 502, las reglas del cortafuegos, el identificador de unidad y el límite de conexiones del dispositivo.
¿Qué significa el código de excepción Modbus 02?
Dirección de datos no válida. El dispositivo no tiene ningún registro en la dirección solicitada, o el bloque solicitado sobrepasa el final del mapa de registros o cruza un hueco. Compruebe la convención de direcciones (el registro 40001 es la dirección de protocolo 0) y la cantidad de registros de la petición.
¿Qué significa la excepción Modbus 0B?
El dispositivo de destino de la pasarela no respondió. La pasarela recibió la petición, pero el dispositivo serie conectado detrás no respondió. Diagnostique el lado serie: dirección, ajustes y cableado.
¿Por qué parece incorrecto un valor Modbus?
La conexión funciona, pero la decodificación no coincide con el mapa de registros. Compare las palabras sin procesar con el mapa: convención de direcciones, tipo de dato, orden de palabras y factor de escala.