Modbus

Modbus ist ein Kommunikationsprotokoll – also ein vereinbarter Satz von Regeln, nach denen zwei Geräte Daten austauschen. Es legt fest, wie eine Anfrage aussieht, wie die Antwort darauf aussehen muss und in welcher Reihenfolge die einzelnen Bytes übertragen werden. Was Modbus nicht festlegt, ist die Bedeutung der einzelnen Werte. Ob in einem bestimmten Register eine Temperatur, eine Drehzahl oder ein Fehlercode steht, steht im Handbuch des jeweiligen Geräts.

Entstanden ist Modbus als firmeneigenes Protokoll für speicherprogrammierbare Steuerungen. Heute ist die Spezifikation offen und frei verfügbar, niemand zahlt Lizenzgebühren dafür. Diese Kombination – einfach, kostenlos, offen dokumentiert – hat dazu geführt, dass praktisch jeder Hersteller von Automatisierungstechnik eine Modbus-Schnittstelle anbietet.

In der Praxis trifft man Modbus überall dort, wo Geräte gelegentlich ein paar Werte austauschen müssen, ohne dass extreme Geschwindigkeit gefragt ist: Energiezähler, die ihren Verbrauch an eine Leitwarte melden. Frequenzumrichter, die Drehzahl-Sollwerte von der Steuerung bekommen. Klimatechnik, Heizungsregler, Wechselrichter in Photovoltaikanlagen. Modbus ist selten die schnellste oder eleganteste Lösung, aber fast immer eine, die funktioniert und die jeder versteht.

Im Vergleich zu modernen Feldbus-Systemen wirkt Modbus schlicht. Es kennt keine aufwändige Geräteverwaltung und keine zyklische Echtzeit-Garantie. Wie sich Modbus genau in die übrige Feldbus-Welt einordnet, ist ein eigenes Thema – hier reicht die Einordnung: Modbus ist der gemeinsame Nenner, auf den sich Geräte verschiedener Hersteller fast immer einigen können.

Modbus folgt einem einfachen Grundprinzip: Ein Gerät gibt den Takt vor, alle anderen warten. Das active Gerät heißt Master, die passiven Geräte heißen Slave. In neueren Spezifikationen werden dieselben Rollen als Client (für den Master) und Server (für die Slaves) bezeichnet – gemeint ist dasselbe.

Der Ablauf ist immer gleich: Der Master schickt eine Anfrage an einen bestimmten Slave. Dieser Slave bearbeitet die Anfrage und schickt eine Antwort zurück. Erst danach darf der Master die nächste Anfrage stellen. Ein Slave wird niemals von sich aus aktiv – er meldet sich nur, wenn er angesprochen wurde. Dieses ständige reihum Abfragen nennt man Polling.

Damit der Master weiß, mit wem er spricht, hat jeder Slave eine eindeutige Slave-Adresse. Gültig sind die Adressen 1 bis 247. Die Adresse 0 ist eine Besonderheit: Sie ist die Broadcast-Adresse. Eine Anfrage an Adresse 0 richtet sich an alle Slaves gleichzeitig – die führen den Befehl aus, antworten aber bewusst nicht, weil sonst alle gleichzeitig auf den Bus sprechen würden.

Eine einzelne Nachricht auf dem Bus – egal ob Anfrage oder Antwort – heißt Telegramm oder Frame. Jedes Telegramm enthält mindestens die Slave-Adresse, die gewünschte Aktion und eine Prüfinformation.

Dieser strenge Anfrage-Antwort-Rhythmus hat eine wichtige Folge: Auf einem Modbus-Strang gibt es nur einen Master. Zwei Master würden sich gegenseitig ins Wort fallen, weil beide gleichzeitig senden wollten. Wer aus einer Anlage zwei Stellen gleichzeitig auf dieselben Geräte zugreifen lassen will, muss sich also etwas überlegen.

Damit Master und Slave dieselben Daten meinen, hat Modbus ein festes Datenmodell. Alle Werte eines Slaves sind in vier Bereiche eingeteilt. Zwei davon arbeiten bitweise, zwei wortweise, und sie unterscheiden sich darin, ob man sie nur lesen oder auch schreiben darf.

Ein Coil ist also ein einzelnes Bit, das man setzen oder zurücksetzen kann – der Name stammt historisch von einer Relaisspule. Ein Register ist ein 16-Bit-Wert, mit dem sich Zahlen von 0 bis 65535 darstellen lassen. Ein Discrete Input und ein Input Register sind reine Leseinformationen vom Slave; ein Holding Register und ein Coil kann der Master auch beschreiben.

Der häufigste Stolperstein: die Adressierung

Hier liegt die größte Fehlerquelle bei Modbus überhaupt. Es gibt zwei Zählweisen, die leicht verwechselt werden.

In der klassischen, aus der Dokumentation bekannten Schreibweise haben die vier Bereiche feste Nummernkreise: Coils beginnen bei 00001, Discrete Inputs bei 10001, Input Registers bei 30001, Holding Registers bei 40001. Diese Nummern sind 1-basiert und enthalten die Bereichskennung in der führenden Ziffer. „Holding Register 40005″ meint also das fünfte Holding Register.

Im eigentlichen Telegramm wird aber 0-basiert adressiert, und die Bereichskennung fällt weg. Das fünfte Holding Register (Doku: 40005) wird im Telegramm als Adresse 4 übertragen. Diese Verschiebung um 1 und das Weglassen der führenden Ziffer sind die Ursache für unzählige Inbetriebnahmen, bei denen „der falsche Wert“ gelesen wird.

Werte über mehrere Register

Ein einzelnes Register fasst nur 16 Bit – das reicht für ganze Zahlen bis 65535. Für größere Zahlen oder für Kommazahlen werden zwei aufeinanderfolgende Register zu einem 32-Bit-Wert kombiniert. So überträgt man etwa eine Gleitkommazahl nach IEEE 754 oder einen Zählerstand, der über 65535 hinausgeht.

Dabei lauert die nächste Falle: die Reihenfolge der beiden Register. Das ist eine Frage der Endianness. Manche Geräte legen das höherwertige Wort zuerst ab (Big-Endian), andere das niederwertige (Little-Endian). Liest man die Register in der falschen Reihenfolge zusammen, kommt ein völlig sinnloser Wert heraus. Welche Reihenfolge ein Gerät verwendet, steht im Handbuch – und muss in der auslesenden Steuerung passend eingestellt werden.

Man erkennt die Logik: Die Lesebefehle 01 bis 04 decken die vier Datenbereiche ab. Geschrieben werden kann nur in die beschreibbaren Bereiche – Coils und Holding Registers. Code 05 und 06 schreiben einen einzelnen Wert, 15 und 16 schreiben gleich mehrere auf einmal.

Aufbau einer Anfrage

Eine typische Lese-Anfrage besteht aus wenigen Angaben: an welchen Slave (Adresse), was tun (Funktionscode), ab welcher Adresse (Startadresse) und wie viele Werte (Anzahl). Eine Anfrage „Lies ab Holding Register 0 zehn Register aus Slave 2″ enthält also Slave-Adresse 2, Funktionscode 03, Startadresse 0 und Anzahl 10. Der Slave antwortet mit demselben Funktionscode und liefert die zehn Registerwerte zurück.

Wenn etwas schiefgeht: die Fehlerantwort

Kann ein Slave eine Anfrage nicht ausführen – etwa weil die angefragte Adresse bei ihm gar nicht existiert –, schickt er keine normale Antwort, sondern eine Exception. Daran erkennt man sie: Im Funktionscode der Antwort ist das höchstwertige Bit gesetzt. Aus Funktionscode 03 (hexadezimal 0x03) wird so 0x83. Der Master sieht am gesetzten Bit sofort, dass etwas nicht stimmt.

Zusätzlich liefert die Exception einen Exception-Code, der den Grund nennt. Die wichtigsten:

Bis hierher ging es um den Inhalt der Telegramme – Adressen, Funktionscodes, Register. Wie diese Telegramme tatsächlich über die Leitung gehen, hängt von der Übertragungsart ab. Davon gibt es drei.

Modbus RTU ist die mit Abstand häufigste Variante. Die Telegramme werden binär und damit sehr kompakt übertragen, meist über eine serielle RS485-Verbindung. RTU ist sparsam, schnell genug für die meisten Anwendungen und der Standardfall in der Industrie.

Modbus ASCII überträgt dieselben Informationen als lesbare Textzeichen. Das macht die Telegramme etwa doppelt so lang und damit langsamer. ASCII ist heute selten und spielt fast nur in Altanlagen oder bei besonderen Anforderungen eine Rolle.

Modbus TCP läuft über ein normales Ethernet-Netzwerk. Die Modbus-Telegramme werden dabei in TCP/IP-Pakete verpackt und über den festgelegten Port 502 übertragen. TCP nutzt die vorhandene Netzwerkinfrastruktur und erlaubt größere Entfernungen sowie höhere Geschwindigkeiten als die serielle Variante.

Telegrammaufbau: RTU gegen TCP

Der inhaltliche Kern – Slave-Adresse, Funktionscode, Daten – ist bei allen Varianten gleich. Unterschiedlich ist, was außen herum kommt.

Bei RTU sichert eine CRC-Prüfsumme das Telegramm ab. CRC steht für Cyclic Redundancy Check, also zyklische Redundanzprüfung. Vereinfacht gesagt rechnet der Sender aus allen Bytes des Telegramms nach einem festen Verfahren eine Kontrollzahl aus und hängt sie ans Ende. Der Empfänger rechnet dieselbe Zahl noch einmal aus und vergleicht. Stimmen beide nicht überein, wurde unterwegs mindestens ein Bit verfälscht, und das Telegramm wird verworfen. Die CRC erkennt also Übertragungsfehler auf Bitebene, ohne dass man die zugrundeliegende Mathematik im Detail kennen muss.

Bei TCP entfällt die CRC. Die Fehlersicherung übernimmt bereits das darunterliegende TCP/IP. Stattdessen bekommt das Telegramm einen kurzen Zusatz vorangestellt, den MBAP-Header (Modbus Application Header). Er enthält unter anderem eine laufende Nummer, mit der sich Anfrage und Antwort eindeutig zuordnen lassen, und die Länge des Telegramms.

Das Timing bei RTU: warum die 3,5-Zeichen-Pause zählt

Ein RTU-Telegramm hat keine festen Start- oder Endbytes. Es gibt also kein Zeichen, das sagt „hier fängt ein neues Telegramm an“ oder „hier ist es zu Ende“. Stattdessen erkennt der Empfänger das Ende eines Telegramms allein an einer Pause auf der Leitung: Schweigt der Bus für die Dauer von mindestens 3,5 Zeichen, gilt das Telegramm als abgeschlossen. Eine kürzere Lücke von etwa 1,5 Zeichen markiert dagegen einen ungewöhnlich großen Abstand innerhalb eines Telegramms und gilt als Fehler.

Diese Zeiten sind keine festen Millisekunden-Werte, sondern hängen von der Baudrate ab. Bei langsamer Übertragung dauert ein Zeichen länger, also auch die Pause. Bei schneller Übertragung wird beides kürzer. Genau deshalb muss man beim Einstellen von Timeout-Zeiten in einer Steuerung wissen, wie lang die Pause bei der gewählten Baudrate tatsächlich ist.

Ein Zeichen umfasst auf der seriellen Leitung üblicherweise 11 Bit: 1 Startbit, 8 Datenbits, 1 Paritätsbit und 1 Stoppbit. Daraus lassen sich die Zeiten direkt berechnen.

Die meisten Modbus-Probleme tauchen bei der Inbetriebnahme einer RTU-Strecke auf. Die gute Nachricht: Es sind fast immer dieselben paar Ursachen. Wer sie der Reihe nach abklopft, findet den Fehler meist schnell.

Die Fehler lassen sich in zwei Gruppen teilen. Die einen betreffen die Protokollebene – also Adressierung, Datentypen, Funktionscodes. Die anderen betreffen die physikalische Ebene – die RS485-Verdrahtung selbst. Die physikalische Seite (Wellenwiderstand, Terminierung, Leitungsführung) gehört ausführlich zum Thema der seriellen Schnittstellen und wird hier nur als Checkliste angerissen. Der Schwerpunkt liegt auf den protokollspezifischen Fehlern, die typisch für Modbus sind.

Checkliste Protokollebene (Modbus-spezifisch)

• Adress-Offset: Wird 1-basiert dokumentiert, aber 0-basiert adressiert? Das ist der mit Abstand häufigste Fehler. Eine Exception mit Code 02 ist ein deutlicher Hinweis.
• Falscher Datenbereich: Holding Register statt Input Register angesprochen, Lese- statt Schreibcode verwendet.
• Endianness: 32-Bit-Werte über zwei Register in falscher Wortreihenfolge zusammengesetzt – Werte wirken sinnlos, obwohl die Kommunikation läuft.
• Funktionscode nicht unterstützt: Nicht jeder Slave kennt jeden Code. Exception-Code 01 weist darauf hin.
• Doppelte Slave-Adresse: Zwei Geräte mit derselben Adresse am selben Strang antworten gleichzeitig – das Ergebnis ist unbrauchbar.

Checkliste physikalische Ebene (nur kurz – Details bei den seriellen Schnittstellen)

• Baudrate und Parität an allen Geräten gleich eingestellt? Schon eine Abweichung verhindert jede Kommunikation.
• A und B vertauscht? Die beiden Datenadern von RS485 müssen an allen Teilnehmern gleich angeschlossen sein.
• Busabschluss an den beiden Enden vorhanden? Fehlende oder falsche Terminierung führt zu Reflexionen und sporadischen Fehlern.

Wie A/B-Verdrahtung, Wellenwiderstand und korrekte Terminierung im Detail funktionieren, ist Thema der seriellen Schnittstellen – dort werden die physikalischen Grundlagen von RS485 ausführlich behandelt. Für die Modbus-Fehlersuche genügt es zu wissen, dass diese Punkte zu prüfen sind.

Vorgehen bei der Inbetriebnahme

Bewährt hat sich ein schrittweises Vorgehen. Zuerst die physikalischen Basics: gleiche Baudrate und Parität, korrekte A/B-Verdrahtung, Abschluss an beiden Enden. Dann mit einer einfachen Modbus-Master-Software am Laptop eine einzelne Anfrage an ein einzelnes Gerät schicken – bevor die SPS überhaupt ins Spiel kommt. Antwortet das Gerät, ist die halbe Miete eingefahren. Antwortet es mit einer Exception, grenzt der Exception-Code den Fehler schon ein. Kommt gar keine Antwort, liegt es meist an Verdrahtung, Baudrate oder einer falschen Slave-Adresse.

Für tiefergehende Analysen hilft ein Busmonitor oder Protokollanalysator, der den kompletten Datenverkehr mitschneidet. Damit sieht man genau, welches Telegramm gesendet und was geantwortet wurde – unverzichtbar, wenn zwei Geräte sich partout nicht verstehen.