Das Modbus RTU Frame Byte für Byte, plus CRC

Ein Modbus RTU Frame besteht aus vier Feldern in fester Reihenfolge: Serveradresse, Funktionscode, Daten und CRC-16. Mehr ist es nicht, und genau deshalb erkennen Sie ein fehlerhaftes Frame nach kurzer Übung mit bloßem Auge. Nach dieser Lektion zerlegen Sie ein Frame aus einer Aufzeichnung Byte für Byte, sagen die Länge der Antwort voraus und prüfen die CRC nach.

Ein echtes Frame, Byte für Byte

Hier ist eine vollständige Anfrage, wie sie auf einer RS485-Leitung liegt: drei Holding-Register ab PDU-Adresse 107 von dem Gerät mit der Serveradresse 1.

01 03 00 6B 00 03 74 17

Dasselbe Register heißt in der Datenblattzählung 40108. Auf der Leitung steht die 1-basierte Nummer nie, dort liegt immer die 0-basierte PDU-Adresse.

Daraus ergibt sich der allgemeine Aufbau: ein Byte Adresse, ein Byte Funktionscode, die Daten, zwei Byte CRC. Was zwischen Funktionscode und CRC steht, hängt allein vom Funktionscode ab. Wie dieser Rahmen zum Transport insgesamt passt, steht in der Übersicht Modbus RTU erklärt.

Die Antwort auf dasselbe Frame

Das angesprochene Gerät antwortet mit elf Byte:

01 03 06 02 2B 00 00 00 64 05 7A

Zwei Dinge lesen Sie sofort ab. Der Funktionscode ist unverändert 03, also keine Exception. Und das dritte Byte ist ein Byte Count, keine Registeranzahl: Bei drei Registern steht dort 6.

Daraus folgt die Längenregel für jede FC03- oder FC04-Antwort: 5 plus 2 mal die Anzahl der Register. Welche Codes es sonst gibt und welche Grenzen für sie gelten, steht in der Referenz der Modbus Funktionscodes.

Wo beginnt und endet ein Frame?

Ein RTU-Frame hat weder ein Startzeichen noch ein Längenfeld. Anfang und Ende bestimmt allein die Stille auf der Leitung. Ein Frame gilt als beendet, wenn mindestens 3,5 Zeichenzeiten lang nichts gesendet wird, und es gilt als kaputt, sobald innerhalb des Frames eine Lücke von mehr als 1,5 Zeichenzeiten auftritt.

Ein Zeichen ist dabei immer 11 Bit lang, unabhängig von der Parität. Bei 19200 Baud, der von der Norm vorgeschriebenen Standardbaudrate, dauert ein Zeichen 0,573 ms. Daraus werden 0,859 ms für t1,5 und 2,005 ms für t3,5.

Aus dem fehlenden Längenfeld folgt auch die Obergrenze: Ein RTU-Frame ist maximal 256 Byte lang. Davon gehen 1 Byte Adresse und 2 Byte CRC ab, es bleiben also höchstens 252 Byte Daten und eine PDU von 253 Byte. Die Rechnung dahinter und die Baudratentabelle finden Sie in der Lektion zu Baudrate, Parität und Timing.

Was die CRC ist, und was sie nicht fängt

Die CRC-16 ist eine Prüfsumme über die gesamte Nachricht: über das Adressbyte, den Funktionscode und alle Datenbytes. Nicht über sich selbst, und nicht über Start-, Stopp- oder Paritätsbits.

Dahinter steckt ein 16-Bit-Register, das mit 0xFFFF vorbelegt wird und pro Byte achtmal nach rechts schiebt; bei gesetztem niederwertigstem Bit kommt das Polynom 0xA001 per XOR dazu. 0xA001 ist die gespiegelte Schreibweise, 0x8005 dasselbe Polynom andersherum notiert. Wer beide mischt, bekommt Unsinn. Einen Abschluss-XOR gibt es nicht.

Wichtiger als das Verfahren ist die Arbeitsteilung mit der Parität. Die Parität sichert jedes Zeichen einzeln ab und erkennt nur eine ungerade Anzahl gekippter Bits pro Zeichenrahmen. Die CRC sichert die Nachricht als Ganzes ab: zwei Netze mit unterschiedlicher Maschenweite.

Was die CRC nicht leistet: Sie sagt nichts über den Inhalt. Ein Frame mit korrekter CRC kann einen Wert tragen, den Sie im falschen Datenblock gelesen haben.

Warum die CRC umgedreht im Frame steht

Alle anderen Zweibyte-Felder eines RTU-Frames gehen High Byte zuerst über die Leitung. Die Startadresse 107 wird zu 00 6B, die Anzahl 3 wird zu 00 03, der Registerwert 555 wird zu 02 2B. Die CRC ist die einzige Ausnahme: Der CRC-Wert 0x1774 liegt als 74 17 auf der Leitung, Low Byte zuerst.

Das steht so in der Norm: Das niederwertige Byte wird zuerst angehängt, das höherwertige ist das letzte Byte der Nachricht.

Der Trick, den Empfänger nutzen

Ein Empfänger muss die CRC nicht neu berechnen und anschließend vergleichen. Er rechnet einfach über das komplette Frame, die beiden CRC-Bytes eingeschlossen. Stimmt alles, kommt 0x0000 heraus.

Das gilt für 01 03 00 6B 00 03 74 17 genauso wie für 01 03 00 00 00 0A C5 CD. Diese Eigenschaft ist der Grund, warum die CRC-Prüfung in einem Gerät fast nichts kostet: eine Schleife, ein Vergleich mit null, fertig.

Was passiert, wenn die CRC nicht stimmt

Nichts. Genau das ist die Pointe. Der Server verwirft das Telegramm, führt es nicht aus und baut keine Antwort. Es gibt keine Exception, keine Fehlermeldung und kein Echo. Ihr Client wartet, bis sein Timeout abläuft.

Ein Timeout hat damit immer mindestens drei mögliche Ursachen: falsche Serveradresse, keine Verbindung, oder eine Leitung, die so viele Bitfehler erzeugt, dass die CRC reihenweise scheitert. Eine Exception schließt alle drei aus, ein Timeout keine einzige.

Deshalb ist ein Timeout in einem Protokoll-Log kein Beweis dafür, dass das Gerät fehlt. Wie Sie diese drei Ursachen in der richtigen Reihenfolge auseinandersortieren, ist Thema der Lektion zur Fehlersuche bei Modbus RTU.

Häufige Fehler

1. Die CRC-Bytes vertauschen. Der CRC-Wert 0x1774 steht als 74 17 im Frame. Wer ihn als 17 74 schreibt, baut ein Frame, das jedes Gerät ignoriert. Adressen und Anzahlen gehen sehr wohl High Byte zuerst, die CRC ist die einzige Ausnahme.
2. Byte Count und Registeranzahl verwechseln. In der Antwort steht ein Byte Count, keine Registeranzahl. Bei drei Registern steht dort 6. Wer die 6 als Anzahl liest, sucht sechs Werte in einem Frame, das nur drei enthält.
3. Einen CRC-Fehler für einen Protokollfehler halten. Ein CRC-Fehler erzeugt Stille. Wer im Log einen Timeout sieht, darf daraus nicht ableiten, dass das Gerät nicht vorhanden ist.
4. Eine kurze Pause mitten im Frame für harmlos halten. Mehr als 1,5 Zeichenzeiten Lücke zwischen zwei Zeichen machen das Frame ungültig. Das passiert zum Beispiel mit einem USB-Adapter, der seine Puffer in Stücken weiterreicht, und sieht dann aus wie ein Kabelproblem.

Selbst ausprobieren

Ziel: Sie zerlegen ein Frame auf Papier und kontrollieren Ihr Ergebnis erst danach mit dem Werkzeug. Diese Reihenfolge ist der eigentliche Lerneffekt.

1. 1

   Frame notieren und selbst deuten

   Nehmen Sie 01 03 00 00 00 0A C5 CD und schreiben Sie zu jedem Byte auf, was es bedeutet, bevor Sie irgendwo nachschlagen.

2. 2

   Die vier Angaben bestimmen

   Notieren Sie Serveradresse, Funktionscode, Startadresse und Anzahl der Register. Die Startadresse und die Anzahl stehen jeweils in zwei Byte, High Byte zuerst.

3. 3

   Die Antwortlänge vorausberechnen

   Rechnen Sie vor: 1 Byte Adresse plus 1 Byte Funktionscode plus 1 Byte Byte Count plus 10 mal 2 Datenbytes plus 2 Byte CRC ergibt 25 Byte.

4. 4

   Mit dem Decoder vergleichen

   Fügen Sie das Frame in den Decoder unten ein und halten Sie Ihre Notizen daneben. Abweichungen sind interessanter als Treffer.

5. 5

   Ein Byte kaputt machen

   Ändern Sie ein einzelnes Byte, etwa die Anzahl von 00 0A auf 00 0B, und lesen Sie, welchen CRC-Wert der Decoder jetzt erwartet.

6. 6

   Am eigenen Bus nachsehen

   Wenn Sie Hardware haben: Starten Sie mbpoll mit dem Schalter -v. Das Werkzeug ist kostenlos nutzbar, auch geschäftlich, und zeigt die gesendeten und empfangenen Byte an. Vergleichen Sie sie mit Ihrer Zerlegung. Oder öffnen Sie den Protocol Analyzer in ModbusCloud Diagnostics, der dieselben Bytes nach Frame-Bestandteil einfärbt und eine kurze Beschreibung dazu setzt.

Fügen Sie ein RTU-Frame in Hex ein

Anfrage FC03Antwort FC03Exception 02Kaputte CRC

CRC stimmt

01

0

03

1

00

2

6B

3

00

4

03

5

74

6

17

7

• Serveradresse
• Funktionscode
• Daten
• CRC-16

Feld	Hex	Dezimal	Bedeutung
Serveradresse	01	1
Funktionscode	03	3	Read Holding Registers
Startadresse	00 6B	107
Anzahl	00 03	3
CRC-16	74 17	6004

Ohne Hardware. Die Schritte 1 bis 5 brauchen kein Gerät und keine Leitung, nur das Frame und den Decoder.

Erwartetes Ergebnis: eine Zerlegung, die mit dem Decoder übereinstimmt, und ein absichtlich verfälschtes Frame, bei dem der Decoder den erwarteten CRC-Wert nennt. Wenn Sie beides haben, lesen Sie ab jetzt jede Buscaptur mit anderen Augen. Wie Sie einen ganzen Bus systematisch abklopfen, zeigt die Anleitung zum Modbus Netzwerk scannen.

Zusammenfassung

• Ein RTU-Frame hat vier Felder in fester Reihenfolge: 1 Byte Serveradresse, 1 Byte Funktionscode, bis zu 252 Byte Daten, 2 Byte CRC-16, zusammen höchstens 256 Byte.
• Eine Leseantwort ist 5 plus 2 mal die Anzahl der Register lang, und ihr drittes Byte ist der Byte Count, nicht die Registeranzahl.
• Alle Zweibyte-Felder gehen High Byte zuerst über die Leitung, nur die CRC nicht: Der Wert 0x1774 liegt als 74 17 auf dem Bus.
• Anfang und Ende eines Frames markiert allein die Stille: mindestens 3,5 Zeichenzeiten zwischen zwei Frames, höchstens 1,5 Zeichenzeiten Lücke darin.
• Ein CRC-Fehler erzeugt keine Exception, sondern gar keine Antwort, weshalb Sie beim Client einen Timeout sehen.