Technisches Wissen

Was ist Modbus RTU / TCP?

Elektroingenieur und Modbus-Experte von esco antriebstechnik vor blauem Hintergrund, daneben Touchpanels, Frequenzumrichter und I/O-Systeme, die eine vernetzte Industrieanlage symbolisieren.

Modbus ist ein herstellerunabhängiges Kommunikationsprotokoll, mit dem Steuerungen, Frequenzumrichter, I/O-Module, Zähler und HMI-Panels Daten austauschen. Es legt fest, wie ein Gerät Anfragen stellt (Client/Master), wie ein anderes Gerät darauf antwortet (Server/Slave) und wie Prozessdaten in Bits und Registern organisiert sind.

  • Modbus RTU ist die klassische, serielle Variante.
    Sie läuft über Schnittstellen wie RS232, RS422 oder RS485 und eignet sich besonders für robuste Feldbusse mit Linienstruktur.
  • Modbus TCP transportiert dasselbe Protokoll über Ethernet und TCP/IP.
    Damit integrieren Sie Antriebe und I/O-Systeme direkt in bestehende Netzwerke, SCADA-Systeme und IT-Infrastrukturen.

Kurz gesagt:

Modbus RTU = Modbus über serielle Leitungen
Modbus TCP = Modbus über Ethernet

Im Folgenden steigen wir tiefer ein – von der Entstehungsgeschichte über Physik und Topologien bis hin zum praktischen Einsatz in der Antriebstechnik mit Komponenten von esco antriebstechnik.

1. Historischer Hintergrund und Einordnung

1979 entwickelte Gould Modicon eine der ersten speicherprogrammierbaren Steuerungen (SPS). Um mehrere Steuerungen effizient über ein gemeinsames Bussystem zu verbinden, entstand das Modbus-Protokoll.

Warum Modbus bis heute so präsent ist:

  • einer der ältesten, noch aktiven Feldbus-Standards,
  • einfacher Aufbau, der eine kostengünstige Implementierung ermöglicht,
  • in einer großen Zahl von Geräten verfügbar:
    Sensoren, Energiezähler, E/A-Module, Aktoren, Bediengeräte, Anzeigen, IPCs und nahezu alle gängigen SPS.

Mit dem Siegeszug von Ethernet kam die Erweiterung auf Modbus TCP. Diese Variante wurde 2007 als Teil der Norm IEC 61158 standardisiert und ist heute in vielen modernen Automatisierungsarchitekturen gesetzt.

Die Pflege und Weiterentwicklung des Standards koordiniert die Modbus-Organisation, ein Zusammenschluss von Herstellern und Anwendern.

2. Protokollgrundlagen und Rollenmodell

Modbus ist ein Anwendungsprotokoll und beschreibt unabhängig vom physikalischen Medium:

  • den Aufbau der Telegramme,
  • das Rollenmodell (Client/Master und Server/Slave),
  • das Datenmodell mit Bits (Coils, Discrete Inputs) und Registern,
  • Funktionscodes zum Lesen und Schreiben.

Rollen

  • Client / Master – stellt Anfragen, liest und schreibt Daten
  • Server / Slave – stellt Daten zur Verfügung und verarbeitet Schreibzugriffe

Bei Modbus RTU arbeitet typischerweise genau ein Master auf einem Bus.
Bei Modbus TCP sind mehrere Clients üblich, die parallel auf einen Server zugreifen.

3. Physik und Übertragungsmedien

3.1 Modbus RTU – serielle Übertragung

Modbus RTU nutzt serielle Standards:

  • RS232 – Punkt-zu-Punkt-Verbindung
  • RS422 / RS485 – differenzielle Übertragung, busfähig mit mehreren Teilnehmern

Baudraten

  • typischer Bereich: 1.200 … 115.200 Baud
  • in der Praxis häufig: 9.600 oder 57.600 Baud, weil hier das Verhältnis von Datenrate zu Leitungslänge günstig ist.

Abschluss und Leitungen

  • Bei RS485 müssen an den Busenden Abschlusswiderstände gesetzt werden.
  • Leitungsqualität und Verdrahtung beeinflussen Signalintegrität und maximale Länge.

Steckverbinder und Verdrahtung

  • RS232: häufig 9-polige Sub-D-Stecker/Buchsen mit genormter Belegung
    • Pin 2: RxD (Empfang)
    • Pin 3: TxD (Senden)
    • Pin 5: GND Für Punkt-zu-Punkt-Verbindungen nutzt man oft Null-Modem-Kabel, bei denen Sende- und Empfangsleitung gekreuzt sind.
  • RS422/RS485: Sub-D oder Schraubklemmen; entscheidend ist eine saubere, verdrillte Leitungsführung.

Medienwandler und Modems

Serielle Modbus-Kommunikation lässt sich über:

  • Medienwandler,
  • Modems,
  • Funkstrecken

auf andere Übertragungswege und sogar über das Internet verlängern. Wichtig ist, dass die von Modbus definierten Zeitbedingungen (Pausen zwischen Telegrammen und Zeichen) eingehalten bleiben.

3.2 Modbus TCP – Ethernet und WLAN

Bei Modbus TCP wird das Modbus-Protokoll über:

  • Ethernet 10/100 Base-TX,
  • den TCP-Layer, üblicherweise Port 502,

übertragen. Datenraten von 10 bzw. 100 Mbit/s sind standardmäßig verfügbar.
Über WLAN lässt sich Modbus TCP ebenfalls einsetzen, sofern die Netzqualität ausreichend ist.

Damit nutzt Modbus TCP die vorhandene Ethernet-Infrastruktur inklusive Switches, Router und Firewalls und fügt sich gut in bestehende IT-Netze ein.

4. Topologie und Adressierung

4.1 Modbus RTU

Je nach Schnittstelle ergeben sich unterschiedliche Topologien:

  • RS232 → Punkt-zu-Punkt (ein Master, ein Slave)
  • RS422 / RS485 → Linienstruktur (Bus), Mehrpunkt-Verbindung

Eigenschaften:

  • Ein Modbus-RTU-Netz hat einen Master und mindestens einen Slave.
  • Der Master fragt die Slaves entsprechend Bedarf nacheinander ab (Polling).
  • Jeder Slave besitzt eine eindeutige Adresse im Bereich 1 bis 247.

4.2 Modbus TCP

Modbus TCP übernimmt die Topologie des Ethernet-Netzes:

  • Stern-, Linien-, Ring-Topologien, VLANs und redundante Strukturen sind möglich.
  • Teilnehmer besitzen Client- oder Server-Funktionalität; ein Gerät kann auch beides kombinieren.

Adressierung:

  • primär über die IP-Adresse des Servers,
  • zusätzlich eine Unit-ID (Modbus-Adresse innerhalb des TCP-Telegramms).

Viele Geräte ignorieren die Unit-ID, solange sie nicht als Gateway zu einer RTU-Strecke arbeiten. Bei Gateways nutzt man die Unit-ID, um einen bestimmten RTU-Slave hinter dem Gateway anzusprechen.

Das Protokoll verwendet standardmäßig TCP-Port 502. Über Router können Sie Modbus TCP in andere Subnetze und – mit geeigneten Sicherheitsmaßnahmen – auch über das Internet übertragen.

5. Das Modbus-Datenmodell

Modbus unterscheidet aus Sicht des Slaves vier Datentypen:

Datentyp Beschreibung Zugriff
Discrete Input Eingangs-Bit nur lesbar
Coil Ausgangs-Bit les- und schreibbar
Input Register Eingangsregister (16-Bit-Wort) nur lesbar
Holding Register Ausgangsregister (16-Bit-Wort) les- und schreibbar

Größere Datentypen (z. B. 32- oder 64-Bit-Werte, Fließkommazahlen) bilden Sie über mehrere aufeinanderfolgende Register oder Bits ab. Pro Modbus-Telegramm können maximal 252 Bytes Nutzdaten übertragen werden.

5.1 Funktionscodes (Function Codes)

Funktionscodes steuern:

  • ob gelesen oder geschrieben wird,
  • und auf welchen Datentyp zugegriffen wird.

Gängige Funktionscodes:

  • FC 01 – Read Coils
  • FC 02 – Read Discrete Inputs
  • FC 03 – Read Holding Registers
  • FC 04 – Read Input Registers
  • FC 05 – Write Single Coil
  • FC 06 – Write Single Register

Erweiterte Funktionen:

  • FC 15 – Write Multiple Coils
  • FC 16 – Write Multiple Registers
  • FC 23 – Read/Write Multiple Registers

Nicht jedes Gerät unterstützt alle Codes; maßgeblich ist die jeweilige Dokumentation.

5.2 0X/1X/3X/4X-Adressnotation

In vielen Unterlagen – insbesondere älteren aus dem Schneider-Umfeld – begegnet man der klassischen Notation:

  • 0xxxx → Coils
  • 1xxxx → Discrete Inputs
  • 3xxxx → Input Registers
  • 4xxxx → Holding Registers

Beispiele:

  • 00001 → erstes Coil
  • 10001 → erster Discrete Input
  • 30001 → erstes Input Register
  • 40001 → erstes Holding Register

Andere Hersteller geben Startadressen als dezimale oder hexadezimale Offsets (beginnend bei 0 oder 1) an. Hier entstehen häufig Off-by-One-Fehler, weil Master und Dokumentation einen unterschiedlichen Startindex annehmen.

5.3 Speicherorganisation im Slave

Es existieren zwei grundsätzliche Modelle:

  1. Getrennte Speicherblöcke

  • pro Datentyp eigener Block und eigener Adressbereich,
  • Zugriff ausschließlich mit passendem Funktionscode,
  • Fehladressierungen fallen früh auf.
  1. Kombinierter Speicherblock

  • alle Datentypen teilen sich einen Adressraum; die Sicht hängt vom Funktionscode ab,
  • höhere Flexibilität, aber mehr Gefahr für Fehlzuordnungen.

In kombinieren Modellen kann es vorkommen, dass Eingänge über Register-Zugriffe gelesen oder sogar beschrieben werden können, wenn der Hersteller dies so umgesetzt hat. Eine sorgfältige Auswertung der Dokumentation ist daher Pflicht.

5.4 Exception Responses

Reagiert ein Slave auf eine Anfrage mit einem Fehler, liefert er eine Exception Response mit Code, z. B.:

  • 01 – Illegal Function (Funktionscode nicht unterstützt)
  • 02 – Illegal Data Address (Adresse ungültig)
  • 03 – Illegal Data Value (z. B. unzulässiger Schreibwert)

Diese Rückmeldungen sind wichtige Diagnosewerkzeuge bei Inbetriebnahme und Service.

6. Konfiguration von Modbus-Systemen

6.1 Modbus RTU

Bei Modbus RTU konfigurieren Sie typischerweise:

  • am Slave
    • Geräteadresse (DIP-Schalter, Drehschalter oder Software),
    • Kommunikationsparameter (Baudrate, Datenbits, Parität, Stopbits).
  • am Master
    • Liste der Slaves mit ihren Adressen,
    • unterstützte Funktionscodes,
    • Startadressen und Anzahl der Register/Bits.

Die Master-Konfiguration erfolgt meist in der Engineering-Software der SPS oder des HMI.

6.2 Modbus TCP

Zusätzlich zu Adressen und Funktionscodes benötigen Sie:

  • IP-Adresse, Subnetzmaske, ggf. Gateway des Servers,
  • verwendeten Port (Standard: 502).

Client und Server müssen sich im selben IP-Segment befinden oder per Routing erreichbar sein. Die Konfiguration des Clients erfolgt über Software oder einen integrierten Webserver.

7. Varianten des Modbus-Protokolls

Neben RTU und TCP existieren weitere Varianten:

  • Modbus ASCII
    – Übertragung des Protokolls als ASCII-Zeichen statt binärer Frames. Funktional ähnlich zu RTU, heute selten.
  • Modbus Plus
    – proprietäre Erweiterung auf RS485-Basis mit HDLC-Layer (ISO/IEC 3309).
    Datenrate 1 Mbit/s, Kombination aus zyklischen „Global Data“ und azyklischen Telegrammen.
    Vor allem in bestimmten Schneider-Electric-Systemen anzutreffen.

8. Modbus in der Antriebstechnik mit esco-Produkten

Als esco antriebstechnik gmbh mit Sitz in Troisdorf (Raum Köln/Bonn, NRW) setzen wir Modbus RTU und Modbus TCP in vielen Projekten der DACH-Region ein. Typische Konstellationen:

8.1 Frequenzumrichter mit Modbus

Viele unserer Frequenzumrichter – z. B. von TOSHIBA, INVT oder escodrives – unterstützen Modbus RTU und/oder Modbus TCP.

Über Modbus:

  • stellen Sie Sollfrequenz, Rampen und Betriebsarten ein,
  • lesen Sie Istwerte wie Strom, Drehzahl, Leistung oder Energie,
  • werten Sie Fehler- und Warncodes aus.

WooCommerce-Platzhalter – Frequenzumrichter

8.2 Dezentrale I/O-Systeme (Weintek, EAP, INVT)

Dezentrale I/O-Module bringen digitale und analoge Signale direkt an der Maschine ins Netz.

Vorteile:

  • geringere Verdrahtung im Schaltschrank,
  • kurze Wege zu Sensoren und Aktoren,
  • klar strukturierte Adressen statt großer Klemmenlisten.

WooCommerce-Platzhalter – I/O-Systeme

8.3 HMI- und Touchpanels

WEINTEK-Touchpanels besitzen Modbus-Treiber für RTU und TCP bereits ab Werk. Sie können:

  • Antriebe und I/O-Systeme direkt bedienen und beobachten,
  • einfache Steuerungsaufgaben übernehmen,
  • Daten an übergeordnete Systeme weiterreichen.

WooCommerce-Platzhalter – Touchpanels


So entsteht eine schlanke, leistungsfähige Architektur aus HMI als Modbus-Client und Feldgeräten als Server.

9. Migration und Kombination von RTU und TCP

Viele Bestandsanlagen arbeiten bereits mit Modbus RTU auf RS485-Basis, während neue Anlagenteile auf Ethernet setzen. Statt „entweder oder“ wählen Betreiber daher häufig eine hybride Lösung:

  • RTU-Stränge bleiben unverändert im Feld,
  • Gateways stellen diese Teilnehmer als Modbus-TCP-Server im Ethernet zur Verfügung,
  • Leitsysteme, SCADA oder Cloud-Plattformen greifen über Ethernet zu.

So modernisieren Sie Ihre Anlage schrittweise, ohne funktionierende Komponenten sofort ersetzen zu müssen.

Smart Building Anwendung Esco

10. Anwendungsgebiete

Modbus RTU und Modbus TCP werden heute in einer Vielzahl von Branchen eingesetzt. Typische Anwendungsgebiete sind:

  • Maschinenbau
    Anbindung von Frequenzumrichtern, Softstartern, dezentralen I/O-Systemen und Sensorik in Fördertechnik, Verpackungsanlagen, Werkzeugmaschinen, Prozess- und Verfahrenstechnik.
  • Gebäudeautomatisierung
    Einbindung von Heizungs-, Lüftungs- und Klimageräten (HLK), Energiezählern, Pumpen, Ventilatoren, Brandmelde- und Sicherheitssystemen in zentrale Gebäudeleittechnik.
  • Hausautomatisierung
    Steuerung und Überwachung von Wärmepumpen, kleinen Energiemanagementsystemen, Heizkreisverteilern und Messgeräten in gehobenen Wohn- und Zweckbauten.
  • Messtechnik und Energiedaten-Erfassung
    Auslesen von Strom-, Energie- und Betriebsstundenzählern, Temperatur- und Drucksensoren sowie Datenkonzentratoren, oft in Kombination mit übergeordneten Leitsystemen oder Cloud-Plattformen.
  • Infrastruktur- und Versorgungstechnik
    Wasser- und Abwasseranlagen, Fernwärme, Pumpstationen und andere verteilte Systeme, bei denen robuste Kommunikation über größere Entfernungen erforderlich ist.

Für esco antriebstechnik stehen insbesondere Anwendungen im Maschinen- und Anlagenbau im Fokus – etwa in:

  • Förder- und Lagertechnik,
  • Verpackungs- und Abfüllanlagen,
  • Pumpen- und Lüfterapplikationen,
  • Dosier- und Mischanlagen.

Hier verbindet Modbus RTU / TCP Frequenzumrichter, I/O-Systeme und Touchpanels zu einer durchgängigen Automatisierungs- und Diagnoselösung.

11. Fazit

  • Modbus RTU / TCP bietet ein robustes, einfaches und herstellerübergreifendes Kommunikationsprotokoll für Antriebstechnik und Automation.
  • RTU überzeugt bei serieller Feldkommunikation mit langen Leitungswegen und geringem Hardwareaufwand.
  • TCP spielt seine Stärken in Ethernet-Netzen mit mehreren Clients, Leitsystem-Integration und Remote-Zugriff aus.
  • Durch das einfache Datenmodell mit Coils und Registern eignet sich Modbus ideal, um Frequenzumrichter, I/O-Systeme und Touchpanels in Maschinen und Anlagen zu verknüpfen.

Mit der Kombination aus technisch sauberen Grundlagen und praxisnahen Komponenten (Frequenzumrichter, I/O-Systeme, HMI-Panels) bietet esco antriebstechnik eine durchgängige Plattform, um Modbus RTU und TCP in Industrie- und Gebäudeanwendungen erfolgreich einzusetzen.

Die Zykluszeit hängt ab von:

  • Baudrate, Anzahl der Teilnehmer und Umfang der Abfragen bei RTU,
  • Netzwerklast, Switches und Anzahl paralleler Verbindungen bei TCP.

In vielen Anwendungen bewegen sich Pollzeiten im Bereich weniger Millisekunden bis zu Sekunden, abhängig davon, ob es um schnelle Regelung oder eher Diagnose und Monitoring geht. Entscheidend ist eine sinnvolle Planung der Abfragefrequenzen.

Bewährt haben sich:

  • strukturierte Slave-Adressbereiche bei RTU (z. B. 1–20 Antriebe, 21–40 I/O),
  • klar definierte IP-Adresspläne und Subnetze bei TCP,
  • zentrale Registerlisten, die Adressen und Funktionscodes dokumentieren.

Eine saubere Adressplanung spart in der Inbetriebnahme mehr Zeit als jede „automatische Suche“.

Modbus TCP selbst besitzt keine integrierten Sicherheitsmechanismen (keine Verschlüsselung, keine Authentifizierung). Sicherheit entsteht durch:

  • Netzwerksegmentierung (Produktionsnetz vs. Büronetz),
  • Firewalls und definierte Übergangspunkte,
  • VPN-Zugänge für Remote-Service,
  • klare Berechtigungskonzepte in HMI/SCADA.

Modbus TCP sollte daher als Protokoll innerhalb eines geschützten Netzes betrachtet werden, nicht als Sicherheitslösung selbst.

  • Nutzen Sie Geräte, die aussagekräftige Status- und Fehlerregister bereitstellen.
  • Visualisieren Sie Klartextmeldungen auf HMI/SCADA.
  • Loggen Sie relevante Werte (z. B. Strom, Temperatur, Betriebszustand) über die Zeit.
  • Auswertungen der Exceptioncodes helfen, Kommunikationsfehler schnell einzugrenzen.

So wird Modbus vom einfachen Feldbus zum diagnostischen Werkzeug.

Häufige Ursachen:

  • falsche Baudrate oder Parität,
  • fehlende oder falsche Abschlusswiderstände,
  • doppelt vergebene Slave-Adressen,
  • vertauschte A/B-Leiter bei RS485.

Vorgehen:

  1. Kommunikationsparameter auf allen Geräten abgleichen.
  2. Bus physikalisch prüfen (Abschluss, Verdrahtung).
  3. Teilnehmer schrittweise zuschalten.
  4. Bei Bedarf Protokollanalyse einsetzen.

Typische Probleme:

  • IP-Adresskonflikte oder falsche Subnetze,
  • blockierter Port 502 durch Firewalls,
  • Überlastung oder Fehlkonfiguration von Switches,
  • zu viele gleichzeitige Verbindungen zu einem Gerät.

Auch hier hilft ein strukturiertes Vorgehen: IP-Konfiguration prüfen, Punkt-zu-Punkt-Verbindung testen, dann Netzwerkinfrastruktur einbeziehen.