Modbus-TCP

Das Master/Slave-Prinzip

Modbus arbeitet nach dem Master/Slave-Prinzip. Das bedeutet, dass es mindestens einen Master und mindestens einen Slave gibt.

Modbus-Slaves sind z. B. SPS-Steuerungen, Web-IOs oder andere dezentrale IO-Baugruppen für digitale und analoge Signale.

Der Master ist immer der Kommunikationspartner, der die Initiative ergreift, also eine Anfrage bzw. den gewünschten Funktionsaufruf an einen Slave sendet. Jeder Slave hat eine eindeutige Adresse. Der Slave ist im Normalfall rein passiv und antwortet nur dann, wenn er gezielt mit seiner Adresse angesprochen wird.

Master/Slave - Client/Server

Mit der zunehmenden Bedeutung von TCP/IP-Ethernet als Übertragungsmöglichkeit wurde das Modbus-Protokoll nahezu 1:1 von serieller Datenübertragung auf TCP adaptiert.

Modbus-TCP arbeitet nach dem Client/Server-Prinzip, wobei der Master den Part des Clients übernimmt und die Slaves als Server agieren. Der Modbus-Master muss also zu jedem Modbus-Slave eine explizite TCP-Verbindung aufbauen. Diese Verbindung bleibt für die Dauer der Kommunikation bestehen. Es wird nicht für jede Anfrage eine neue Verbindung aufgebaut.

Der standardisierte TCP-Server-Port für Modbus-TCP ist 502.

Register und Variablen

Speicheradressen oder auch Registern durch den Modbus-Master, also den Client.

Man kann sich das so vorstellen, als hätte der Modbus-Slave, also der Server, einen Schrank mit sehr vielen Schubfächern, die alle durchnummeriert sind. Den Schubfächern sind Funktionen zugeteilt.

Will der Modbus-Master bestimmte Informationen abrufen, gibt er in seiner Anfrage die Nummer des entsprechenden Fachs an und bekommt vom Modbus-Slave den Inhalt zurück.

Wenn der Modbus-Master beim Slave etwas auslösen möchte, z. B. einen Schaltausgang bedienen, legt er die notwendige Information in das Fach mit der entsprechenden Nummer.

Wie eingangs beschrieben erfolgt das tatsächlich über entsprechende Speicheradressen (Registeradressen). Es stehen maximal 65536 Adressen zur Verfügung. Welche Funktion sich hinter welcher festgelegt - ist also nicht einheitlich vorgegeben.

In aller Regel ist der Speicher getrennt nach Funktionen in Bereiche aufgeteilt.

Function Codes

Über Function Codes wird innerhalb des Modbus-Protokolls angegeben, auf welchen Datentyp wie zugegriffen werden soll. Hier eine Liste der gängigsten Function Codes:

Modbus Protokollaufbau

Der Modbus-TCP-Protokollrahmen hat folgenden Aufbau:

Transaction ID
Die Transaction ID ist so etwas wie eine Anfragenummer und wird vom Master bei jeder Anfrage um eins hochgezählt. Der Client antwortet mit der gleichen Transaction ID.

Protocol ID
Bei Modbus-TCP immer 0.

Length
Länge der Modbus-Daten in Byte plus zwei.

Unit ID
Beim seriellen Modbus-Protokoll war das die Adresse des Slaves. Das Feld ist aus Kompatibilitätsgründen übernommen worden. Bei Modbus-TCP-erfolgt die eindeutige Adressierung allerdings über die IP-Adresse des Slaves.

Function Code
Das Modbus-Protokoll definiert über durchnummerierte Function Codes, was die vom Master gesendete Anfrage beim Slave auslösen soll.

Modbus Data
Der Modbus Data Bereich wird abhängig vom verwendeten Function Code mit unterschiedlichen Inhalten gefüllt und kann dadurch unterschiedlich groß ausfallen. Auch die Datenrichtung spielt beim Aufbau des Modbus Data Bereichs eine Rolle.

Bei Datenrichtung Master an Slave beinhalten die ersten zwei Bytes immer die anzusprechende Speicheradresse.

Das folgende Beispiel zeigt, wie ein Modbus-TCP Paket beim Abrufen von zwei Registern mit Function Code 3 ab Speicheradresse 0x1020 aussieht.

Das Antwortpaket ist anders aufgebaut. Hier ist im ersten Byte von Modbus Data die Anzahl der übergebenen Register-Bytes kodiert. In den nächsten 4 Bytes sind die Inhalte der angeforderten Register.

Trotz des überschaubaren Protokollaufbaus bietet Modbus-TCP große Flexibilität für die industrielle Kommunikation.

Tipp: Achten Sie darauf, ob der Gerätehersteller bei der Beschreibung der Speicheradressen die Werte dezimal oder hexadezimal angibt.