Das Modbus-Protokoll ist ein Kommunikationsprotokoll, das auf einer Master/Slave- bzw. Client/Server-Architektur basiert. Es wurde 1979 von Gould-Modicon für die Kommunikation mit seinen speicherprogrammierbaren Steuerungen ins Leben gerufen. In der Industrie hat sich der Modbus zu einem De-facto-Standard entwickelt, da es sich um ein offenes Protokoll handelt. Seit 2007 ist die Version Modbus TCP Teil der Norm IEC 61158. [Wikipedia]
Wie das folgende Schaubild zeigt, erlaub Modbus die Kommunikation über unterschiedliche Netzwerke:
Modbus unterscheidet die folgenden drei Betriebsarten:
- Modbus ASCII:Im Modbus ASCII wird keine Binärfolge, sondern ASCII-Code übertragen. Dadurch ist es direkt für den Menschen lesbar, allerdings ist der Datendurchsatz im Vergleich zu RTU geringer.
- Modbus RTU:Remote Terminal Unit (RTU) überträgt die Daten in binärer Form. Dies sorgt für einen guten Datendurchsatz, allerdings können die Daten nicht direkt vom Menschen ausgewertet werden, sondern müssen zuvor in ein lesbares Format umgesetzt werden.
- Modbus TCP:Modbus/TCP ist RTU sehr ähnlich, allerdings werden TCP/IP-Pakete verwendet, um die Daten zu übermitteln. Der TCP-Port 502 ist für Modbus/TCP reserviert. [Wikipedia]
Bei Mondus handel es sich um ein PDU (Protocol Data Unit) bzw. Service Data Unit (SDU), welches unabhängig von darunterliegendem Netzwerk-Layer den komplette Satz an Daten und Verwaltungsinformation beinhaltet. Innerhalb des OSI Modells ist das Protokoll auf Schicht 7 angesiedelt. Durch das Mapping von Modbus auf einen speziellen BUS oder Netzwerk können zusätzliche Felder hinzugefügt werden. Diese Erweiterung ist innerhalb der Abbildung als ADU gekennzeichnet.
Die Größe eines Frames ist wie folgt:
Das Modbus Datenmodell unterscheidet vier Datentypen bzw. Registertypen voneinander. 
Dei folgende Liste zeigt eine Übersicht der PDU Funktion-Codes:
Für weitere Informationen zu den einzelnen Register Typen verweise ich auf die Spezifikation.
Die folgende Abbildung veranschaulicht eine fehlerfreie Client/Server Kommunikation:
Im Falle eines Fehlers sieht die Kommunikation wie folgt aus:
Jeder BUS-Teilnehmer besitzt eine eindeutige Adresse. Jeder Teilnehmer darf Nachrichten über den Bus senden. In der Praxis wird die Kommunikation durch den Master initiiert und ein adressierter Slave antwortet.
Bsp.:
Um die Kommunikation zwischen Client (Master) und Server (Slave) zu veranschaulichen, verwende ich die folgenden Anwendungen:
- ModbusPal (Slave Simulator)
- QModMaster (Master Simulator)
Die Abbildung zeigt, wie ein Slave innerhalb des ‚Holding‘ Registers (Register 1 von 65k) ein Wert (24) zur Verfügung stellt.
Der Master verbindet sich via TCP Port 502 mit dem Slave und macht eine ‚Holding‘ Register ‚1‘ Abfrage und erhält den Wert 24 z.B. 24 Grad Celsius.