rtuovertcp: der Unterschied, und was ein Gateway tut

Der Unterschied zwischen echtem Modbus TCP und rtuovertcp steckt in den ersten sieben und in den letzten zwei Bytes: Das eine trägt einen MBAP-Header und keine Prüfsumme, das andere eine Serveradresse und eine CRC-16. Dazwischen steht beide Male exakt dieselbe PDU. Nach dieser Lektion erkennen Sie beide Formen an den Bytes und stellen Ihren Client beim ersten Versuch richtig ein.

Zwei Byteströme, die gleich aussehen

Beide Byteströme unten reisen über Port 502, und beide stellen dieselbe Frage: lies drei Holding-Register ab PDU-Adresse 107, im Datenblatt die 1-basierte Nummer 40108. Oben das serielle Frame, unten dieselbe Anfrage als Modbus TCP.

01 03 00 6B 00 03 74 17
00 01 00 00 00 06 FF 03 00 6B 00 03

Die Antworten darauf verhalten sich genauso. Seriell kommt 01 03 06 02 2B 00 00 00 64 05 7A zurück, 11 Bytes. Über Modbus TCP kommt 00 01 00 00 00 09 FF 03 06 02 2B 00 00 00 64 zurück, 15 Bytes. In der Mitte steht beide Male 03 06 02 2B 00 00 00 64: Funktionscode 03, Byte Count 06, dann die Registerwerte 555, 0 und 100.

Daraus folgt die Regel, kompakt: Die PDU ist transportunabhängig, die Verpackung nicht. RTU setzt 1 Byte davor und 2 Bytes dahinter, Modbus TCP setzt 7 Bytes davor und nichts dahinter.

Was ein Gateway mit Ihrem Frame macht

Ein Gateway packt jede Anfrage aus und wieder ein. Es nimmt Ihr Modbus TCP Frame entgegen, wirft die sieben MBAP-Bytes weg, setzt die Unit-ID als Serveradresse davor, rechnet die CRC-16 über den Rest und hängt sie an, Low Byte zuerst. Das Ergebnis ist Byte für Byte das RTU-Frame aus dem Abschnitt oben.

Die Antwort geht denselben Weg rückwärts. Das Gateway prüft die CRC, entfernt Adressbyte und Prüfsumme, setzt einen MBAP-Header davor und kopiert dabei Transaction-ID, Protocol-ID und Unit-ID aus Ihrer Anfrage. Nur das Length-Feld berechnet es neu, denn die Antwort ist länger als die Anfrage.

Zwei Konsequenzen sind für die Fehlersuche wichtig. Erstens: Hinter einem Gateway trägt die Unit-ID die echte Serveradresse auf dem Bus, gültig sind 1 bis 247, die 0 ist als Broadcast reserviert. Der Wert 0xFF, der bei einem nativen TCP-Gerät empfohlen wird, zeigt hier auf niemanden. Zweitens: Das Gateway ist der Client auf dem RS485-Bus, mit eigenem Timeout und eigenem Poll-Verhalten. Es reicht Ihre Anfragen nicht durch, es stellt sie neu.

Warum es rtuovertcp gibt

Nicht jedes Kästchen mit RJ45 auf der einen und Schraubklemmen auf der anderen Seite übersetzt Protokolle. Ein Teil davon sind serielle Geräteserver: Sie schieben jedes Byte, das über TCP hereinkommt, unverändert auf die serielle Leitung und jedes Byte von dort zurück ins Netz. Das ist billiger zu bauen und funktioniert auch mit Protokollen, die der Hersteller gar nicht kennt.

Für Modbus bedeutet das: Es liegt kein MBAP-Header im Datenstrom, dafür aber eine CRC-16. Ihr Client muss das Adressbyte und die Prüfsumme selbst erzeugen und beim Lesen selbst auswerten. Genau dafür gibt es die Einstellung rtuovertcp.

Ein Punkt fällt dabei unter den Tisch. Auf RS485 markiert eine Stille von 3,5 Zeichenzeiten das Ende einer Nachricht, denn ein RTU-Frame hat kein Längenfeld. Eine TCP-Verbindung überträgt keine Stille. Ihr Client muss deshalb aus Funktionscode und Byte Count ausrechnen, wo eine Antwort endet, und deshalb reagieren manche Werkzeuge auf ein unvollständiges Frame mit einem Timeout statt mit einer Fehlermeldung.

Welche Einstellung wählen Sie im Client?

Sie stellen die Verbindungsart nach dem ein, was das Gerät auf die Leitung legt, nicht nach dem, wo das Kabel eingesteckt ist. Ein natives TCP-Gerät und ein protokollübersetzendes Gateway wollen tcp, ein serieller Geräteserver will rtuovertcp. In Home Assistant sieht das so aus:

modbus:
  - name: gateway
    type: rtuovertcp
    host: 192.168.1.50
    port: 502

Das Symptom der falschen Wahl ist unverwechselbar: Ping antwortet, ein Porttest auf 502 baut eine Verbindung auf, und trotzdem liest kein einziges Register. Wenn beide unteren Schichten nachweislich stehen, ist die Verbindungsart der erste Kandidat und nicht die Firewall.

Wann RTU, wann TCP?

Kurz und ohne Ideologie, sechs Zeilen für die Projektbesprechung. Die ausführliche Gegenüberstellung mit Kosten, Latenz und Diagnose steht in der Übersicht, wann Modbus RTU und wann Modbus TCP passt.

In der Praxis fällt die Entscheidung selten sortenrein aus. RS485 im Feld und ein Gateway zum Netz ist der übliche Kompromiss, und welche Bauart dafür taugt, klärt die Kaufberatung für Modbus Gateways.

Welche Fehlerbilder ein Gateway hinzufügt

Mit einem Gateway im Pfad bekommen Sie zwei Exception-Codes, die es vorher nicht gab, und beide kommen vom Gateway und nicht vom Endgerät.

Exception 0B, Gateway Target Device Failed To Respond, heißt: Die Anfrage lag auf dem Bus, dort hat niemand geantwortet. Prüfen Sie in dieser Reihenfolge Unit-ID, Serveradresse am Gerät, Baudrate und Parität. Exception 0A, Gateway Path Unavailable, heißt: Das Gateway konnte intern keinen Weg von der IP-Seite zur seriellen Seite freimachen. Das ist eine Konfigurations- oder Überlastmeldung, typischerweise bei zu vielen gleichzeitigen Abfragen.

Über TCP sieht eine Exception so aus, hier auf die Anfrage von oben, wenn eines der drei Register nicht existiert:

00 01 00 00 00 03 FF 83 02

Das Length-Feld steht auf 3, der Funktionscode ist 0x83, also 0x03 mit gesetztem höchstem Bit, und 02 ist der Exception-Code. Dasselbe seriell: 01 83 02 C0 F1, mit Serveradresse davor und CRC dahinter. Ein Frame, das über TCP mit zwei zusätzlichen Bytes endet, ist ein Hinweis auf einen Tunnel und nicht auf einen Fehler.

Häufige Fehler

1. tcp einstellen, wo rtuovertcp gehört. Ping antwortet, der Port ist offen, und trotzdem liest kein Register. Das ist die Signatur dieses Fehlers. Stellen Sie die Verbindungsart um und ändern Sie sonst nichts, dann wissen Sie hinterher, woran es lag.
2. Unit-ID 255 hinter einem Gateway eintragen. Der Wert 0xFF gilt für native TCP-Geräte. Hinter einem Gateway gehört dort die echte Serveradresse zwischen 1 und 247 hinein, sonst kommt Exception 0B oder gar nichts zurück.
3. Das Gateway für unsichtbar halten. Es ist der Client auf dem Bus, mit eigenem Timeout und eigenem Poll-Verhalten. Zu viele gleichzeitige Abfragen quittiert es mit Exception 0A, und die kommt nicht vom Endgerät.
4. RTU durch TCP ersetzen und den Bus liegen lassen. Ein Gateway löst ein Reichweitenproblem, kein Verkabelungsproblem. Ein schlecht terminierter Bus bleibt schlecht terminiert, auch wenn davor jetzt Ethernet liegt.

Selbst ausprobieren

Ziel: Sie sehen mit eigenen Augen, dass dieselbe Frage in zwei Verpackungen stecken kann. Die ersten drei Schritte brauchen keine Hardware.

1. 1

   Die Anfrage seriell aufschreiben

   Notieren Sie "lies drei Holding-Register ab PDU-Adresse 107 bei Serveradresse 1" als RTU-Frame: 01 03 00 6B 00 03 74 17. Markieren Sie, welche Bytes die PDU sind.

2. 2

   Dieselbe Anfrage als Modbus TCP aufschreiben

   Daneben kommt 00 01 00 00 00 06 FF 03 00 6B 00 03. Markieren Sie auch hier die PDU. Es müssen dieselben fünf Bytes sein.

3. 3

   Nachzählen und erklären

   8 Bytes gegen 12 Bytes. Rechnen Sie die Differenz vor: 7 Bytes Header statt 1 Byte Adresse ergibt 6 mehr, die zwei fehlenden CRC-Bytes ziehen 2 wieder ab, bleiben 4.

4. 4

   Mit Gateway: beide Verbindungsarten testen

   Konfigurieren Sie Ihren Client einmal als tcp und einmal als rtuovertcp, ändern Sie sonst nichts, und notieren Sie, welche der beiden liest.

5. 5

   Eine Unit-ID abfragen, die es nicht gibt

   Fragen Sie eine Adresse ab, die auf dem Bus nicht vergeben ist. Notieren Sie, ob Exception 0B kommt oder ein Timeout. Der Unterschied verrät, ob das Gateway übersetzt oder nur durchreicht.

Ohne Gateway. Für Schritt 4 und 5 legen Sie stattdessen die Bytes aus Schritt 1 und 2 in die Werkzeuge der vorigen Lektionen: den Decoder in der Lektion zum RTU-Frame und der CRC und den Builder in der Lektion zum MBAP-Header und der Unit-ID. Benennen Sie zu jedem Byte, welche Rolle es hat.

Erwartetes Ergebnis: zwei Frames nebeneinander mit derselben markierten PDU, eine nachgerechnete Differenz von 4 Bytes, und das Wissen, welche Verbindungsart Ihr Gateway will. Wie Sie ein Gateway von Grund auf aufsetzen, zeigt die Anleitung zum Einrichten eines Modbus TCP Gateways.

Zusammenfassung

• Echtes Modbus TCP legt sieben MBAP-Bytes vor die PDU und hängt nichts an, ein getunneltes RTU-Frame legt ein Adressbyte davor und zwei CRC-Bytes dahinter.
• Dieselbe Anfrage ist als RTU-Frame 8 Bytes und als Modbus TCP Frame 12 Bytes lang; die fünf PDU-Bytes in der Mitte sind identisch.
• Ein Gateway tauscht nur die Verpackung: Es entfernt den MBAP-Header, macht die Unit-ID zur Serveradresse und rechnet die CRC-16 neu, während Funktionscode und Daten unverändert bleiben.
• Hinter einem Gateway gehört die echte Serveradresse von 1 bis 247 in das Unit-ID-Feld, nicht der für native TCP-Geräte empfohlene Wert 0xFF.
• Exception 0A und Exception 0B kommen immer vom Gateway und nie vom Endgerät, und sie bedeuten Überlast beziehungsweise keine Antwort auf dem Bus.