Diagnostica Modbus: timeout, eccezioni e valori errati

Prima di cambiare un'impostazione, acquisisci i byte grezzi. Un master che mostra soltanto «timeout» o «valore errato» nasconde le prove che distinguono le cause descritte qui sotto. Questa è una lettura di due registri holding dal dispositivo 1 in Modbus RTU, insieme alle due possibili risposte:

L'assenza di risposta è il quarto esito. Ciascuno ha una sezione dedicata qui sotto.

1. Nessuna risposta

Un timeout significa che non è arrivata una risposta valida. La richiesta non ha raggiunto integra il dispositivo, è stata inviata a un indirizzo a cui nessuno risponde, oppure la risposta si è persa o è arrivata dopo che il master aveva smesso di attendere. La specifica del protocollo applicativo (sezione 7) dice che un dispositivo che rileva un errore di parità, LRC o CRC in una richiesta non invia una risposta. Un timeout può quindi indicare una richiesta corrotta oltre che un dispositivo assente.

Su un bus seriale (Modbus RTU), verifica nell'ordine:

1. Imposta la stessa velocità di trasmissione, parità e numero di bit di stop su ogni dispositivo. La specifica della linea seriale (sezione 2.5.1) prevede la parità pari come predefinita e richiede 2 bit di stop quando la parità è disattivata. Alcuni contatori escono di fabbrica senza parità e con 1 bit di stop: configura il master come il contatore.
2. Assegna a ogni dispositivo un indirizzo univoco da 1 a 247. Due dispositivi con lo stesso indirizzo rispondono insieme e corrompono entrambe le risposte. L'indirizzo 0 è broadcast: i dispositivi eseguono una scrittura broadcast ma non rispondono.
3. Scambia i due conduttori di segnale su un dispositivo e riprova. I produttori non etichettano A e B in modo uniforme.
4. Assicurati che il bus venga interrogato da un solo master. Un portatile o un BMS che interroga contemporaneamente causa collisioni.
5. Controlla l'adattatore. Un adattatore USB a 2 fili senza soppressione dell'eco restituisce al master la sua stessa richiesta e alcuni master la interpretano come risposta non valida. Un adattatore che disattiva il proprio driver troppo lentamente dopo una richiesta tronca i primi byte della risposta.
6. Controlla terminazione e polarizzazione. Errori CRC che aumentano con la velocità di trasmissione e la lunghezza del cavo indicano una possibile assenza di terminazione. Errori di framing o un primo byte spurio dopo un periodo di inattività del bus indicano una possibile assenza di polarizzazione. La guida al cablaggio RS-485 tratta entrambi.
7. Imposta un timeout che copra il tempo della risposta sul filo più il tempo di elaborazione del dispositivo. Il calcolo segue questo elenco.

Su Modbus TCP, controlla l'indirizzo IP, la porta (502, salvo che il dispositivo ne usi un'altra), le regole del firewall fra client e dispositivo e l'identificatore di unità. La guida all'implementazione TCP (sezione 4.4.1.2) consiglia l'identificatore di unità 0xFF per un dispositivo connesso direttamente alla rete e accetta anche 0. Dietro un gateway TCP-RTU, l'identificatore seleziona il dispositivo seriale, da 1 a 247. Alcuni dispositivi TCP diretti rispondono solo a un valore specifico: consulta il manuale.

La guida TCP non stabilisce un limite di connessioni: ogni dispositivo ha il proprio. Alcuni contatori accettano una sola connessione per volta. Se un client scompare senza chiuderla, per esempio dopo un'interruzione di alimentazione, la connessione rimane semiaperta e occupa lo slot (sezione 4.2.2). Con i timer TCP keepalive predefiniti citati dalla guida (sezione 4.3.2), la prima prova parte dopo 2 ore di inattività e lo stack rinuncia dopo altre 8 prove a intervalli di 75 s. Lo slot può dunque restare bloccato per oltre 2 ore. Durante questo periodo il dispositivo rifiuta nuove connessioni o non risponde. La guida consiglia al server di chiudere la connessione più vecchia quando arriva un nuovo client e il pool è pieno (sezione 4.2.1.1), ma non tutti i dispositivi lo fanno. Spegni e riaccendi il dispositivo oppure cerca nel manuale un timeout di inattività più breve.

Prova con la richiesta più piccola che dovrebbe funzionare: un registro presente secondo la mappa, con la funzione (03 o 04) indicata dalla mappa. Usa il calcolatore CRC e LRC Modbus per verificare un frame RTU acquisito.

Calcolo del timeout

In modalità RTU, ogni byte occupa 11 bit sul filo: un bit di start, 8 bit di dati, un bit di parità (oppure un secondo bit di stop) e un bit di stop. A 9600 baud, un byte richiede 1,15 ms. La lettura più grande è di 125 registri (funzione 03 o 04) e la sua risposta è lunga 255 byte: indirizzo, funzione, numero di byte, 250 byte di dati e CRC da 2 byte. La risposta richiede 292 ms sul filo. La richiesta richiede altri 9 ms e il dispositivo ha bisogno di tempo per preparare la risposta. Un timeout di 200 ms fallisce quindi per ogni lettura di un blocco completo, anche quando il dispositivo risponde correttamente.

La specifica della linea seriale (sezione 2.4.1) indica un timeout di risposta tipico fra 1 s e diversi secondi a 9600 baud. Inizia con 1 s, misura il tempo di risposta reale e poi riduci il timeout se il budget di interrogazione lo richiede.

Conta anche la temporizzazione dei frame. Un frame RTU termina dopo un silenzio di 3,5 tempi di carattere, pari a 4,0 ms a 9600 baud. Una pausa superiore a 1,5 tempi di carattere all'interno di un frame induce il destinatario a scartarlo come incompleto. Oltre 19.200 baud, la specifica raccomanda valori fissi di 1,75 ms per l'intervallo fra frame e 750 µs per quello interno al frame (sezione 2.5.1.1). Un master o convertitore che fa una pausa all'interno di un frame provoca un timeout senza altri sintomi. Il calcolatore dei tempi Modbus RTU calcola questi valori per altre velocità e dimensioni dei blocchi.

2. Una risposta di eccezione

Una risposta di eccezione dimostra che il dispositivo ha ricevuto integra la richiesta e l'ha rifiutata. La risposta contiene il codice funzione più 0x80, seguito da un codice di eccezione. Una risposta 83 02 significa «funzione 03, eccezione 02»:

La specifica fornisce un esempio calcolato per l'eccezione 02. Un dispositivo con 100 registri (indirizzi da 0 a 99) accetta la lettura di 4 registri dall'indirizzo 96. Rifiuta la lettura di 5 registri dallo stesso indirizzo, perché il registro 100 non esiste. Verifica prima la convenzione degli indirizzi (il registro 40001 è l'indirizzo di protocollo 0), poi la lunghezza del blocco. Molti contatori rifiutano anche un blocco che attraversa un vuoto nella mappa. Dividi il blocco in quel punto.

Non inviare la stessa richiesta ripetutamente in un ciclo: il dispositivo restituisce ogni volta la stessa risposta. Fa eccezione il codice 06: il dispositivo è occupato e la stessa richiesta può riuscire più tardi.

Una scrittura può riuscire a livello di protocollo senza modificare il dispositivo. Una risposta normale alla funzione 06 ripete la richiesta e una risposta normale alla funzione 16 (0x10) contiene l'indirizzo iniziale e la quantità. Nessuna delle due conferma che il dispositivo abbia applicato il valore. Rileggi il registro dopo la scrittura.

3. Un valore plausibile ma errato

Una risposta valida dimostra soltanto che il collegamento funziona. Non dimostra che il valore sia stato decodificato correttamente. Se è plausibile ma non coincide con il display del dispositivo, confronta le word grezze dei registri con la mappa:

Il frame all'inizio della guida mostra perché è facile non accorgersi di un ordine delle word scambiato. Le word 435C 8000 si decodificano come 220,5 nell'ordine ABCD. Nell'ordine CDAB (word scambiate) diventano -2,4 × 10⁻⁴¹, che la maggior parte dei display mostra come 0. Una tensione pari a 0 sembra indicare un contatore senza alimentazione. Con un intero, l'errore è evidente: un valore di 10 con le word scambiate diventa 655.360.

Il decoder dei registri Modbus mostra una coppia di registri in tutti e quattro gli ordini dei byte (ABCD, CDAB, BADC e DCBA). La guida alle mappe dei registri spiega ogni campo di una mappa.

Dimostra la correzione anche in un secondo stato operativo, per esempio con un carico acceso e spento oppure con un valore che diventa negativo. Una lettura esattamente pari a 0 si decodifica allo stesso modo con ogni ordine dei byte e quindi non dimostra nulla sull'ordine.

4. Valori bloccati o che saltano

Se il collegamento e la decodifica sono corretti ma i valori si bloccano, saltano o mancano, la causa è nell'interrogazione.

Un gateway può restituire l'ultimo valore letto dopo che il dispositivo dietro di esso smette di rispondere. Verifica il timeout dei valori obsoleti del gateway. Controlla anche nel manuale la frequenza di aggiornamento del dispositivo. Se un registro si aggiorna una volta al secondo, un'interrogazione più rapida restituisce più volte lo stesso valore.

Un contatore a 32 bit letto con due richieste separate può combinare la word più significativa di un istante con quella meno significativa dell'istante successivo. Il totale fa allora un salto di 65.536 e torna indietro. Leggi entrambi i registri in una sola richiesta.

In Modbus TCP, l'identificatore di transazione MBAP associa ogni risposta alla richiesta corrispondente. La guida TCP (sezione 4.4.1.3) dice che il client deve scartare una risposta il cui identificatore non corrisponde a una richiesta in attesa. Se ignora l'identificatore, può accettare una risposta tardiva come risposta alla richiesta successiva. Il valore di un punto compare allora di tanto in tanto in un altro punto.

I vuoti regolari si verificano quando il ciclo di interrogazione dura più dell'intervallo di rendicontazione. Un dispositivo offline peggiora la situazione: ogni interrogazione attende l'intero timeout e tutti i nuovi tentativi. Per esempio, 10 contatori su un bus a 9600 baud, ciascuno letto con una richiesta da 60 registri, richiedono circa 210 ms ciascuno. Sono inclusi 143 ms per la risposta, 9 ms per la richiesta, gli intervalli fra frame e un tempo di elaborazione del dispositivo ipotizzato di 50 ms. Il ciclo dura circa 2,1 s. Se un contatore va offline con timeout di 1 s e 2 tentativi ulteriori, aggiunge 3 s. Il ciclo diventa 5,1 s e un intervallo di rendicontazione di 5 s presenta vuoti per tutti e 10 i contatori. La guida a interrogazione e nuovi tentativi spiega come impostare questo budget.

I record duplicati o tardivi di solito provengono dal percorso dei dati dopo il gateway. Confronta il record locale del gateway con il sistema destinatario. Un nuovo tentativo può anche duplicare una lettura sul lato Modbus se la risposta originale arriva dopo il timeout.

Chiudere il guasto con le prove

Quando il guasto è risolto, registra:

• il sintomo, con richiesta e risposta grezze;
• la causa trovata e l'unica modifica effettuata;
• la prova riuscita successivamente, in due stati operativi;
• una prova con un dispositivo spento, per mostrare che gli altri continuano a trasmettere.

Conserva il tutto nel verbale di accettazione della guida alla messa in servizio Modbus RS-485.

Diagnostica in Edge

Edge verifica una connessione Modbus per fasi. Per Modbus TCP, la prova della connessione esegue un ping dell'host, ne risolve il nome e apre una connessione TCP alla porta; mostra esito e latenza di ogni fase. Il risultato del ping è indicativo, perché molti dispositivi e firewall bloccano ICMP. La prova riesce quando si apre la connessione TCP. Per una connessione seriale, controlla che la porta esista e sia un dispositivo seriale. Questo non dimostra che un dispositivo sul bus risponda. Lo verifica la prova del sensore: invia una vera richiesta di lettura con identificatore di unità, codice funzione (da 01 a 04) e indirizzo inseriti dall'utente e attende la risposta per 5 s. Applica poi le opzioni di scambio delle word e dei byte e mostra il valore decodificato, così puoi confrontare gli ordini dei byte con il display del dispositivo. Dopo aver aggiunto il dispositivo, ogni sensore mostra un indicatore di qualità dei dati: la percentuale di letture attese arrivate negli ultimi 15 minuti. Usa le tre prove in quest'ordine. La prima che fallisce indica dove si trova il guasto.

Questa guida fa parte della serie Modbus e RS-485.