Modbus RTU Fehlersuche: vom Symptom zur Ursache

Bei der Modbus RTU Fehlersuche sagt Ihnen das Symptom, wo Sie suchen müssen, noch bevor Sie einen Schraubendreher in die Hand nehmen. Stille, ein CRC-Fehler und eine Exception entstehen an drei verschiedenen Stellen im Ablauf. Nach dieser Lektion ordnen Sie jedes dieser drei Fehlerbilder einem Suchbereich zu und grenzen den Rest ein, indem Sie immer nur eine Größe ändern.

Drei Fehlerbilder, drei verschiedene Welten

Stille, eine Exception und ein falscher Wert entstehen an drei verschiedenen Stellen, denn die Spezifikation kennt für eine Anfrage genau vier Ausgänge: Der Server antwortet sauber, er empfängt nichts, er erkennt einen Übertragungsfehler und schweigt, oder er versteht die Anfrage und kann sie nicht ausführen. Aus Sicht des Clients fallen die mittleren beiden Fälle zusammen, beide sehen aus wie ein Timeout. Daraus folgt der wichtigste Satz dieser Lektion: Ein CRC-Fehler erzeugt keine Exception, sondern Stille.

Die Nachschlagetabelle zu Rahmenaufbau, Zeitverhalten und Funktionscodes finden Sie in der Übersicht zu Modbus RTU. Hier geht es um die Reihenfolge, in der Sie vorgehen.

Wenn gar nichts zurückkommt

Dann prüfen Sie in der Reihenfolge von billig nach teuer, denn drei der fünf häufigsten Ursachen kosten Sie keine Schraube.

1. Serveradresse. Ab Werk steht fast jedes Gerät auf 1. Gültig sind 1 bis 247, die 0 ist Broadcast und 248 bis 255 sind reserviert. Wenn Ihr Werkzeug es kann, scannen Sie den Bus, statt zu raten.
2. Busparameter. Die Spezifikation schreibt 19200 mit gerader Parität als Vorgabe vor, und kaum ein Hersteller hält sich daran. Probieren Sie bei einem unbekannten Gerät zuerst 9600 8N1.
3. D0 und D1 vertauscht. Messen Sie, bevor Sie tauschen. Das kostet zehn Sekunden und Sie ändern dabei nichts.
4. Common fehlt. Ein Zweidraht-Bus nach Modbus hat drei Leiter: das Adernpaar und einen gemeinsamen Bezug. Ohne ihn verlässt der Bus irgendwann den zulässigen Gleichtaktbereich.
5. Keine Spannung oder Schnittstelle nicht freigegeben. Manche Geräte brauchen eine eigene Versorgung der Schnittstelle oder eine Freigabe im Menü.

Wenn etwas kommt, aber falsch ist

CRC-Fehler heißen, dass Bits unterwegs beschädigt werden, und dafür gibt es eine überschaubare Liste von Ursachen. Reflexionen an einer Sterntopologie oder an zu langen Stichleitungen stehen ganz oben, dicht gefolgt von der Terminierung: erlaubt sind höchstens zwei Abschlusswiderstände, an den beiden Enden der Hauptleitung und niemals auf einer Stichleitung. Welche Werte wohin gehören, steht im Leitfaden zur RS485-Verkabelung.

Daran hängt die dritte Ursache, das Kabel selbst.

Dazu kommen Länge und Tempo: 1000 m gelten bei 9600 Baud mit AWG26 oder dicker, mit Cat5-Kabel sind es 600 m. Und schließlich sieht eine doppelt vergebene Adresse aus wie ein Kabelproblem, weil zwei Server gleichzeitig senden. Wie Sie das nachweisen, steht in der Lektion über mehrere Geräte an einem Bus.

Wenn das Gerät höflich nein sagt

Dann haben Sie die halbe Fehlersuche schon gewonnen. Hier ist eine Anfrage nach drei Holding-Registern ab PDU-Adresse 107, also ab der Datenblattnummer 40108: 01 03 00 6B 00 03 74 17.

Das Gerät antwortet mit fünf Bytes: 01 83 02 C0 F1.

Daraus folgt die Regel: Eine Exception-Antwort ist der Funktionscode plus 0x80, gefolgt von genau einem Byte Exception-Code. In einer Hex-Ausgabe erkennen Sie sie am zweiten Byte, so wie in der Lektion zum RTU-Rahmen und zur CRC.

Ein zweites Beispiel, das sich in genau einem Punkt unterscheidet: Schicken Sie dasselbe Telegramm mit 04 statt 03 an ein Gerät, das FC04 gar nicht kennt, kommt Exception 01 zurück statt 02. Die beiden CRC-Bytes ändern sich dadurch mit.

Drei Codes decken den Alltag ab. Exception 01 heißt, das Gerät kennt diesen Funktionscode nicht. Exception 02 heißt, Startadresse oder Startadresse plus Anzahl liegen außerhalb der Registertabelle, und das ist fast immer die Verwechslung zwischen Datenblattnummer und PDU-Adresse. Exception 03 heißt, ein Wert im Datenfeld ist unzulässig, etwa mehr als 125 Register in einer FC03-Anfrage. In der Praxis antworten viele Geräte auf diesen Fall allerdings mit 02.

Wenn die Zahl plausibel, aber falsch ist

Dann stimmt der Transport, aber nicht die Interpretation. Vier Verdächtige, in dieser Reihenfolge: das Register liegt um eins daneben, Sie lesen den falschen Block (FC03 statt FC04), der Skalierungsfaktor fehlt, oder ein vorzeichenbehafteter Wert wird vorzeichenlos gelesen.

Der schnellste Test ist eine Größe, deren Größenordnung Sie kennen. Die Netzfrequenz liegt um 50 Hz; steht im Feld 5001, fehlt ein Skalierungsfaktor von -2. Eine Außentemperatur von -5,0 Grad steht als s16 mit 0xFFCE im Register, vorzeichenlos gelesen wird daraus 65486 und geteilt durch 10 also 6548,6 Grad. Ein Temperaturwert, der im Winter auf mehrere tausend springt, ist immer dieser Fehler. Werte über zwei Register hinweg haben zusätzlich das Thema Word Order, das später im Kurs eine eigene Lektion bekommt.

Fehler suchen, ohne den Bus zu zerstören

Eine Änderung pro Versuch, eine Notiz pro Änderung, und zurückdrehen, was nichts gebracht hat. Wer Adresse, Parität und Adernpaar in einem Rutsch verstellt, weiß bei Erfolg nicht, was geholfen hat.

Dazu kommt ein Werkzeug, das kaum jemand nutzt: FC08 liest Diagnosezähler aus, ohne dass Sie eine Klemme lösen. Unterfunktion 0x0A löscht alle Zähler. 0x0B liefert die Anzahl der Telegramme, die das Gerät auf dem Bus gesehen hat, wobei Telegramme mit falscher CRC nicht mitzählen. 0x0C liefert die Anzahl der CRC-Fehler, und 0x0D die Anzahl der Exceptions, die dieses Gerät selbst zurückgeschickt hat.

Wenn es an der Umgebung liegt

Das erkennen Sie am Zeitmuster, nicht am Fehlercode. Die Lücken liegen immer dann, wenn eine Maschine anläuft: ein Frequenzumrichter, ein Aufzug, ein Kompressor. In Schaltschränken der Gebäudeautomation liegt die Busleitung oft im selben Kanal wie die Motorleitung, und das reicht.

Protokollieren Sie die Fehler darum mit Zeitstempel, bevor Sie messen. Zwei Muster gehören in dieselbe Kategorie: eine Terminierung, die bei Zimmertemperatur trägt und bei 40 Grad im Schrank nicht mehr, und eine Erdschleife, weil der Schirm an beiden Enden aufliegt oder der Common zwei Gebäudeteile mit unterschiedlichem Erdpotenzial verbindet.

Dieses Protokollieren muss nicht von Hand geschehen. Der Data Logger in ModbusCloud Diagnostics zeichnet mehrere Register über die Zeit auf und exportiert nach CSV, und der Fehlerzähler im Protocol Analyzer zählt die fehlgeschlagenen Transaktionen mit. So legen Sie den Zeitpunkt des Ausfalls neben den Einschaltmoment, statt ihn zu vermuten.

Häufige Fehler

Bei einem Timeout sofort an der Verkabelung ziehen. Eine falsche Serveradresse erzeugt genau dasselbe Bild und ist in dreißig Sekunden ausgeschlossen. Machen Sie die billigen Tests zuerst.

Eine Exception als Störung behandeln. Eine Exception ist eine gelungene Transaktion mit einer inhaltlichen Antwort. Ab diesem Moment ist die Verkabelung kein Verdächtiger mehr, und wer trotzdem den Schaltschrank öffnet, verliert eine Stunde.

Mehrere Dinge gleichzeitig ändern und dann feststellen, dass es läuft. Sie wissen jetzt nicht, was es war, und beim nächsten Mal stehen Sie wieder bei null.

Einem billigen Patchkabel vertrauen, weil es zufällig acht Adern hat. Netzwerkkabel hat rund 100 Ohm Wellenwiderstand gegen etwa 120 Ohm einer RS485-Leitung. Auf kurzen Strecken merken Sie nichts, auf langen kommt es als CRC-Fehler zurück.

Selbst ausprobieren

1. 1

   Einen Wert lesen, der funktioniert

   mbpoll -m rtu -a 1 -b 9600 -P none -t 4 -r 1 -c 2 -1 /dev/ttyUSB0, wie beim ersten Auslesen eines Geräts. Notieren Sie die Abfragestatistik. mbpoll steht unter GPLv3 und ist frei nutzbar, auch geschäftlich.

2. 2

   Fehlerbild 1: D0 und D1 tauschen

   Erneut lesen. Erwartung: gesendete Telegramme steigen, empfangene bleiben bei null. Danach zurücktauschen.

3. 3

   Fehlerbild 2: falsche Serveradresse

   Dasselbe Kommando mit einer Adresse, die auf Ihrem Bus nicht vergeben ist, etwa -a 9. Gleiches Bild, nur kommt mit der richtigen Adresse sofort wieder eine Antwort. Damit haben Sie den Suchbereich halbiert.

4. 4

   Fehlerbild 3: ein Register anfragen, das es nicht gibt

   Wählen Sie eine Adresse weit außerhalb der Registertabelle, etwa -r 60000 -c 2. Jetzt sehen Sie Exception 02, und das beweist Verkabelung, Busparameter und Serveradresse in einem Schritt.

5. 5

   Die drei Beobachtungen nebeneinanderlegen

   Eine Tabelle mit drei Zeilen: was Sie geändert haben, was Sie gesehen haben, welchen Bereich Sie daraus ableiten.

6. 6

   Optional: die Diagnosezähler mitlaufen lassen

   Zähler mit FC08 Unterfunktion 0x0A löschen, Fehlerbild 1 wiederholen und 0x0C erneut lesen. Kontrolle: der Zähler ist gestiegen.

Ohne Hardware. Fehlerbild 3 läuft gegen den Simulator: python -m pip install "pymodbus[serial,simulator]==3.15.0", starten mit pymodbus.simulator --modbus_server server --modbus_device device auf Port 5020, dann -m tcp -p 5020 127.0.0.1 statt der seriellen Argumente. pymodbus steht unter der BSD-3-Lizenz und ist frei nutzbar, auch geschäftlich. Fehlerbild 1 und 2 lassen sich über einen falschen Port und eine falsche Unit-ID nachstellen, aber der Mechanismus ist ein anderer: über TCP verweigert die Verbindung, auf RS485 verschwindet das Telegramm im Kabel.

Erwartetes Ergebnis: drei Fehlerbilder in einer Tabelle, je Zeile ein Suchbereich.

Zusammenfassung

• Stille, eine Exception und ein unplausibler Wert sind drei Fehlerbilder, die auf drei verschiedene Bereiche zeigen, und diese Zuordnung machen Sie vor jedem Handgriff.
• Ein CRC-Fehler erzeugt keine Exception, sondern einen Timeout, weshalb Stille immer mehrere Ursachen offen lässt.
• Eine Exception beweist, dass Verkabelung, Busparameter und Serveradresse stimmen, und verlegt die Suche in den Inhalt der Anfrage.
• Beim Eingrenzen ändern Sie genau eine Größe pro Versuch und notieren die Wirkung, sonst wissen Sie am Ende nicht, was geholfen hat.
• Mit FC08 lesen Sie die Diagnosezähler eines Geräts aus, und das Verhältnis von CRC-Fehlern zu gesehenen Telegrammen trennt ein physikalisches Problem von einem Konfigurationsproblem.