Modbus-Fehlersuche: Timeouts, Ausnahmen und falsche Werte

Erfassen Sie die Rohbytes, bevor Sie eine Einstellung ändern. Eine Master-Anzeige mit nur „Timeout“ oder „falscher Wert“ verbirgt die Hinweise, mit denen sich die Ursachen unterscheiden lassen. Hier sehen Sie eine Modbus-RTU-Abfrage von zwei Halteregistern an Gerät 1 und zwei mögliche Antworten:

Die vierte Möglichkeit ist gar keine Antwort. Jeder Fall wird unten getrennt behandelt.

1. Keine Antwort

Ein Timeout bedeutet, dass keine gültige Antwort eingetroffen ist. Die Anfrage erreichte das Gerät nicht unbeschädigt, ging an eine Adresse ohne Gerät oder die Antwort ging verloren beziehungsweise kam nach Ablauf der Wartezeit an. Laut Abschnitt 7 der Anwendungsspezifikation antwortet ein Gerät nicht auf eine Anfrage mit Paritäts-, LRC- oder CRC-Fehler. Ein Timeout kann daher ebenso eine beschädigte Anfrage wie ein fehlendes Gerät anzeigen.

Prüfen Sie bei einem seriellen Bus mit Modbus RTU diese Punkte in der angegebenen Reihenfolge:

1. Stellen Sie an allen Geräten dieselbe Baudrate, Parität und Stoppbitzahl ein. Die Spezifikation für serielle Leitungen (Abschnitt 2.5.1) nennt gerade Parität als Standard und verlangt ohne Parität 2 Stoppbits. Manche Zähler werden mit keiner Parität und 1 Stoppbit ausgeliefert. Stellen Sie den Master passend zum Zähler ein.
2. Vergeben Sie für jedes Gerät eine eindeutige Adresse von 1 bis 247. Zwei Geräte mit derselben Adresse antworten gleichzeitig und beschädigen beide Antworten. Adresse 0 ist Broadcast: Geräte führen einen Broadcast-Schreibbefehl aus, antworten aber nicht.
3. Vertauschen Sie die beiden Signalleiter an einem Gerät und testen Sie erneut. Hersteller bezeichnen A und B nicht einheitlich.
4. Stellen Sie sicher, dass nur ein Master den Bus abfragt. Ein Laptop oder eine Gebäudeleittechnik, die gleichzeitig abfragt, verursacht Kollisionen.
5. Prüfen Sie den Adapter. Ein Zweidraht-USB-Adapter ohne Echo-Unterdrückung liefert dem Master dessen eigene Anfrage zurück; manche Master deuten das als fehlerhafte Antwort. Schaltet der Adapter seinen Sender nach der Anfrage zu langsam ab, fehlen die ersten Bytes der Antwort.
6. Prüfen Sie Abschlusswiderstände und Bias. CRC-Fehler, die mit Baudrate und Kabellänge zunehmen, weisen auf fehlende Terminierung hin. Framing-Fehler oder ein zusätzliches erstes Byte nach einer Buspause weisen auf fehlenden Bias hin. Der Leitfaden zur RS-485-Verdrahtung erläutert beides.
7. Wählen Sie einen Timeout, der die Übertragungszeit der Antwort und die Verarbeitungszeit des Geräts abdeckt. Die Rechnung folgt unten.

Prüfen Sie bei Modbus TCP die IP-Adresse, den Port (normalerweise 502), Firewallregeln zwischen Client und Gerät sowie die Unit-ID. Der TCP-Leitfaden (Abschnitt 4.4.1.2) empfiehlt für ein direkt am Netz angeschlossenes Gerät die Unit-ID 0xFF und erlaubt auch 0. Hinter einem TCP-RTU-Gateway wählt die Unit-ID das serielle Gerät mit Adresse 1 bis 247. Manche direkten TCP-Geräte antworten nur auf einen bestimmten Wert; prüfen Sie deren Handbuch.

Der TCP-Leitfaden legt keine Verbindungsgrenze fest. Jedes Gerät hat seine eigene. Manche Zähler akzeptieren nur eine Verbindung zugleich. Verschwindet ein Client beispielsweise bei einem Stromausfall, ohne die Verbindung zu schließen, kann sie halboffen bleiben und den Platz belegen (Abschnitt 4.2.2). Bei den im Leitfaden genannten Standardzeiten für TCP-Keepalive (Abschnitt 4.3.2) folgt die erste Prüfung nach 2 Stunden Inaktivität, danach gibt der Stack erst nach weiteren 8 Prüfungen in Abständen von 75 s auf. Der Platz kann also länger als 2 Stunden blockiert sein. Währenddessen verweigert das Gerät neue Verbindungen oder beantwortet sie nicht. Der Leitfaden empfiehlt, dass ein Server bei vollem Verbindungspool die älteste Verbindung schließt, sobald ein neuer Client ankommt (Abschnitt 4.2.1.1). Nicht alle Geräte tun das. Starten Sie das Gerät neu oder entnehmen Sie dem Handbuch einen kürzeren Inaktivitäts-Timeout.

Testen Sie mit der kleinsten Anfrage, die funktionieren muss: ein laut Registertabelle vorhandenes Register und die dort angegebene Funktion 03 oder 04. Prüfen Sie einen aufgezeichneten RTU-Frame mit dem Modbus-CRC- und LRC-Rechner.

Timeout berechnen

Im RTU-Modus benötigt jedes Byte 11 Bit auf der Leitung: Startbit, 8 Datenbits, Paritätsbit (oder zweites Stoppbit) und Stoppbit. Bei 9600 Baud dauert ein Byte 1,15 ms. Die größte Leseanfrage umfasst 125 Register (Funktion 03 oder 04); ihre Antwort hat 255 Byte: Adresse, Funktion, Bytezahl, 250 Datenbytes und 2 CRC-Bytes. Diese Antwort belegt die Leitung 292 ms. Die Anfrage benötigt weitere 9 ms, zusätzlich zur Verarbeitungszeit des Geräts. Ein Timeout von 200 ms scheitert daher bei jeder vollständigen Blockabfrage, auch wenn das Gerät korrekt antwortet.

Die Spezifikation für serielle Leitungen (Abschnitt 2.4.1) nennt bei 9600 Baud als typischen Antwort-Timeout 1 s bis mehrere Sekunden. Beginnen Sie mit 1 s, messen Sie die tatsächliche Antwortzeit und verkürzen Sie den Timeout erst, falls das Abfragebudget es erfordert.

Auch die Frame-Zeit ist wichtig. Ein RTU-Frame endet nach einer Ruhezeit von 3,5 Zeichenlängen, bei 9600 Baud also 4,0 ms. Eine Lücke von mehr als 1,5 Zeichenlängen innerhalb eines Frames lässt den Empfänger diesen als unvollständig verwerfen. Oberhalb von 19.200 Baud empfiehlt die Spezifikation feste Werte von 1,75 ms zwischen Frames und 750 µs innerhalb eines Frames (Abschnitt 2.5.1.1). Pausiert ein Master oder Konverter innerhalb eines Frames, kann ein Timeout ohne weiteres Symptom entstehen. Der Modbus-RTU-Zeitrechner berechnet diese Werte für andere Baudraten und Blockgrößen.

2. Ausnahmeantwort

Eine Ausnahmeantwort beweist, dass das Gerät die Anfrage unbeschädigt erhalten und abgelehnt hat. Die Antwort enthält den Funktionscode plus 0x80 und danach einen Ausnahmecode. 83 02 bedeutet „Funktion 03, Ausnahme 02“:

Die Spezifikation enthält ein Beispiel für Ausnahme 02. Ein Gerät mit 100 Registern (Adressen 0 bis 99) akzeptiert 4 Register ab Adresse 96. Es lehnt 5 Register ab Adresse 96 ab, weil Register 100 nicht existiert. Prüfen Sie zuerst die Adresskonvention (Register 40001 entspricht Protokolladresse 0), dann die Blocklänge. Viele Zähler lehnen auch einen Block ab, der eine Lücke ihrer Registertabelle überquert. Teilen Sie ihn an der Lücke.

Wiederholen Sie dieselbe Anfrage nicht endlos. Das Gerät wird jedes Mal gleich antworten. Ausnahme 06 ist anders: Das Gerät ist beschäftigt und dieselbe Anfrage kann später gelingen.

Ein Schreibzugriff kann auf Protokollebene erfolgreich sein, ohne das Gerät zu verändern. Bei Funktion 06 ist die normale Antwort ein Echo der Anfrage; bei Funktion 16 (0x10) enthält sie Startadresse und Anzahl. Beides bestätigt nicht, dass das Gerät den Wert angewendet hat. Lesen Sie das Register nach dem Schreiben erneut.

3. Plausibler, aber falscher Wert

Eine gültige Antwort beweist nur, dass die Verbindung funktioniert. Sie beweist keine korrekte Dekodierung. Ist ein Wert plausibel, stimmt aber nicht mit der Geräteanzeige überein, vergleichen Sie die rohen Registerwörter mit der Registertabelle:

Der Frame am Anfang zeigt, warum eine vertauschte Wortreihenfolge leicht unbemerkt bleibt. Die Wörter 435C 8000 ergeben in ABCD-Reihenfolge 220,5. In CDAB-Reihenfolge, mit vertauschten Wörtern, entsteht -2,4 × 10⁻⁴¹, was die meisten Anzeigen als 0 darstellen. Eine Spannung von 0 sieht aus wie ein Zähler ohne Versorgung. Bei ganzen Zahlen fällt der Fehler auf: Ein Wert von 10 wird nach Worttausch als 655.360 gelesen.

Der Modbus-Registerdecoder zeigt ein Registerpaar in den vier Byte-Reihenfolgen ABCD, CDAB, BADC und DCBA. Der Leitfaden zu Registertabellen erklärt deren Felder.

Bestätigen Sie die Korrektur auch in einem zweiten Betriebszustand, etwa mit ein- und ausgeschalteter Last oder einem negativen Wert. Genau 0 ergibt in jeder Byte-Reihenfolge dasselbe und beweist daher nichts über die Reihenfolge.

4. Eingefrorene oder springende Werte

Funktionieren Verbindung und Dekodierung, aber Werte frieren ein, springen oder fehlen, liegt die Ursache im Abfrageverhalten.

Ein Gateway kann nach Ausfall eines nachgeschalteten Geräts weiterhin dessen letzten gelesenen Wert liefern. Prüfen Sie den Timeout für veraltete Werte am Gateway. Prüfen Sie außerdem im Gerätehandbuch die Aktualisierungsrate. Wird ein Register nur einmal je Sekunde erneuert, liefert eine schnellere Abfrage denselben Wert mehrfach.

Liest ein Client die beiden Wörter eines 32-Bit-Zählers in getrennten Anfragen, kann er das höherwertige Wort eines Zeitpunkts mit dem niederwertigen des nächsten kombinieren. Der Gesamtwert springt dann um 65.536 und wieder zurück. Lesen Sie beide Register in einer Anfrage.

Bei Modbus TCP ordnet die MBAP-Transaktionskennung jede Antwort ihrer Anfrage zu. Der TCP-Leitfaden (Abschnitt 4.4.1.3) verlangt, eine Antwort ohne passende noch offene Anfrage zu verwerfen. Ignoriert ein Client die Kennung, kann er eine späte Antwort als Antwort auf die nächste Anfrage annehmen. Dann erscheint gelegentlich der Wert eines Datenpunkts bei einem anderen.

Regelmäßige Lücken entstehen, wenn ein Abfragedurchlauf länger als das Meldeintervall dauert. Ein ausgefallenes Gerät verschärft dies, weil jede seiner Abfragen den vollen Timeout und alle Wiederholungen abwartet. Beispiel: 10 Zähler an einem Bus mit 9600 Baud, jeder mit einer Anfrage über 60 Register gelesen, benötigen etwa 210 ms je Zähler. Darin enthalten sind 143 ms für die Antwort, 9 ms für die Anfrage, die Frame-Ruhezeiten und angenommene 50 ms Geräteverarbeitung. Der Durchlauf dauert etwa 2,1 s. Fällt ein Zähler mit 1 s Timeout und 2 Wiederholungen aus, kommen 3 s hinzu. Aus dem Durchlauf werden 5,1 s; bei einem 5-s-Meldeintervall entstehen dann Lücken für alle 10 Zähler. Der Leitfaden zu Abfragen und Wiederholungen erläutert die Planung dieses Zeitbudgets.

Doppelte oder verspätete Datensätze entstehen meist im Datenpfad hinter dem Gateway. Vergleichen Sie dessen lokale Aufzeichnung mit dem empfangenden System. Auch auf der Modbus-Seite kann eine Wiederholung einen Lesevorgang duplizieren, wenn die ursprüngliche Antwort erst nach dem Timeout eintrifft.

Fehler mit Nachweisen abschließen

Halten Sie nach der Behebung fest:

• das Symptom mit roher Anfrage und Antwort;
• die gefundene Ursache und die eine vorgenommene Änderung;
• den bestandenen Test in zwei Betriebszuständen;
• einen Test mit einem abgeschalteten Gerät, der zeigt, dass die übrigen Geräte weiter melden.

Nutzen Sie dafür das Abnahmeprotokoll aus dem Leitfaden zur Modbus-RS-485-Inbetriebnahme.

Diagnose in Edge

Edge prüft eine Modbus-Verbindung stufenweise. Bei Modbus TCP pingt der Verbindungstest den Host, löst seinen Namen auf und öffnet eine TCP-Verbindung zum Port. Er zeigt Ergebnis und Latenz jedes Schritts. Das Ping-Ergebnis dient nur als Hinweis, da viele Geräte und Firewalls ICMP blockieren. Der Test gilt als bestanden, wenn sich die TCP-Verbindung öffnen lässt. Bei einer seriellen Verbindung prüft er, ob der serielle Port existiert und ein serielles Gerät ist. Das beweist nicht, dass ein Gerät am Bus antwortet. Dafür dient der Sensortest: Er sendet einen echten Lesezugriff mit Unit-ID, eingegebenem Funktionscode (01 bis 04) und Adresse und wartet 5 s auf die Antwort. Anschließend wendet er die Optionen zum Wort- und Bytetausch an und zeigt den dekodierten Wert, damit Sie die Byte-Reihenfolgen mit der Geräteanzeige vergleichen können. Nach dem Hinzufügen des Geräts zeigt jeder Sensor eine Datenqualitätskennzahl: den Prozentsatz erwarteter Messungen, die in den letzten 15 Minuten eingetroffen sind. Nutzen Sie diese drei Prüfungen in genau dieser Reihenfolge. Die erste fehlgeschlagene Prüfung zeigt, wo der Fehler liegt.

Dieser Leitfaden gehört zur Reihe über Modbus und RS-485.