Modbus

Modbus ist ein Datenkommunikationsprotokoll, das ursprünglich 1979 von Modicon (jetzt Schneider Electric) zur Verwendung mit seinen speicherprogrammierbaren Steuerungen (SPS) veröffentlicht wurde. Modbus hat sich zu einem De-facto-Standard-Kommunikationsprotokoll entwickelt und ist heute ein allgemein verfügbares Mittel zur Verbindung von industriellen elektronischen Geräten. ⓘ

Modbus ist in industriellen Umgebungen beliebt, weil es offen veröffentlicht wird und lizenzfrei ist. Es wurde für industrielle Anwendungen entwickelt, ist im Vergleich zu anderen Standards relativ einfach zu implementieren und zu warten und unterliegt nur wenigen Einschränkungen in Bezug auf das Format der zu übertragenden Daten. ⓘ

Das Modbus-Protokoll verwendet serielle Kommunikationsleitungen, Ethernet oder die Internet-Protokollsuite als Transportschicht. Modbus unterstützt die Kommunikation zu und von mehreren Geräten, die an dasselbe Kabel oder Ethernet-Netzwerk angeschlossen sind. So kann z. B. ein Gerät zur Messung der Temperatur und ein weiteres Gerät zur Messung der Luftfeuchtigkeit an dasselbe Kabel angeschlossen sein, wobei beide Geräte die Messwerte über Modbus an denselben Computer übermitteln. ⓘ

Modbus wird häufig verwendet, um einen Anlagenüberwachungscomputer mit einer Remote Terminal Unit (RTU) in Überwachungs- und Datenerfassungssystemen (SCADA) zu verbinden. Viele der Datentypen haben ihren Namen von der industriellen Steuerung von Fabrikgeräten, wie z. B. der Kontaktplanlogik, da diese zur Steuerung von Relais verwendet wird: Ein physikalischer Ein-Bit-Ausgang wird als Spule bezeichnet, und ein physikalischer Ein-Bit-Eingang wird als diskreter Eingang oder Kontakt bezeichnet. ⓘ

Die Entwicklung und Aktualisierung von Modbus-Protokollen wird seit April 2004, als Schneider Electric die Rechte an diese Organisation übertrug, von der Modbus Organization verwaltet. Die Modbus Organization ist eine Vereinigung von Anwendern und Anbietern von Modbus-kompatiblen Geräten, die sich für die weitere Verwendung der Technologie einsetzt. Modbus Organization, Inc. ist ein Handelsverband zur Förderung und Entwicklung des Modbus-Protokolls. ⓘ

Beschränkungen

• Da Modbus in den späten 1970er Jahren für die Kommunikation mit speicherprogrammierbaren Steuerungen entwickelt wurde, ist die Anzahl der Datentypen auf diejenigen beschränkt, die von den damaligen SPS verstanden wurden. Große binäre Objekte werden nicht unterstützt.
• Es gibt keine Standardmethode für einen Knoten, um die Beschreibung eines Datenobjekts zu finden, z. B. um zu erfahren, dass ein Registerwert eine Temperatur zwischen 30 und 175 Grad darstellt.
• Da es sich bei Modbus um ein Client/Server-Protokoll (früher Master/Slave) handelt, gibt es für ein Feldgerät keine Möglichkeit, Daten über den Event-Handler-Mechanismus abzurufen (außer über Ethernet TCP/IP, genannt Open-MBUS), da der Client-Knoten routinemäßig jedes Feldgerät abfragen und nach Datenänderungen suchen muss. Dies verbraucht Bandbreite und Netzwerkzeit in Anwendungen, bei denen die Bandbreite teuer sein kann, wie z. B. bei einer Funkverbindung mit niedriger Bitrate.
• Modbus ist darauf beschränkt, 247 Geräte auf einer Datenverbindung zu adressieren, was die Anzahl der Feldgeräte, die mit einer übergeordneten Station verbunden werden können, begrenzt (auch hier ist Ethernet TCP/IP eine Ausnahme).
• Das Modbus-Protokoll selbst bietet keine Sicherheit gegen unbefugte Befehle oder das Abfangen von Daten. ⓘ

Modbus-Objekttypen

Die folgenden Objekttypen können von einem Modbus-Server für ein Modbus-Client-Gerät bereitgestellt werden: Die Adressen sind repräsentativ für die ursprüngliche Modicon-Spezifikation. Nach dem aktuellen Standard kann die Adresse 0 - 65535 sein, wobei der Objekttyp durch den Befehl identifiziert wird, der zum Lesen oder Schreiben der Spule oder des Registers. ⓘ

Objekttyp	Zugriff	Größe	Adressraum ⓘ
Spule	Lesen-Schreiben	1 Bit	00001 – 09999
Diskreter Eingang	Nur Lesen	1 Bit	10001 – 19999
Eingangsregister	Nur Lesen	16 Bits	30001 – 39999
Halteregister	Lesen-Schreiben	16 Bits	40001 – 49999

Protokoll-Versionen

Es gibt Versionen des Modbus-Protokolls für serielle Schnittstellen sowie für Ethernet und andere Protokolle, die die Internet-Protokollsuite unterstützen. Es gibt viele Varianten von Modbus-Protokollen:

• Modbus RTU (Remote Terminal Unit) - wird für die serielle Kommunikation verwendet und ist die gängigste Implementierung für Modbus. Modbus RTU verwendet eine kompakte, binäre Darstellung der Daten für die Protokollkommunikation. Das RTU-Format folgt den Befehlen/Daten mit einer zyklischen Redundanzprüfsumme als Fehlerprüfmechanismus, um die Zuverlässigkeit der Daten zu gewährleisten. Eine Modbus-RTU-Nachricht muss kontinuierlich und ohne Zeichenunterbrechungen übertragen werden. Modbus-Nachrichten werden durch Leerlaufperioden (stille Perioden) eingerahmt (getrennt).
• Modbus ASCII - wird in der seriellen Kommunikation verwendet und nutzt ASCII-Zeichen für die Protokollkommunikation. Das ASCII-Format verwendet eine Längsredundanzprüfsumme. Modbus-ASCII-Nachrichten werden durch einen führenden Doppelpunkt (":") und einen abschließenden Zeilenumbruch (CR/LF) eingerahmt.
• Modbus TCP/IP oder Modbus TCP - eine Modbus-Variante, die für die Kommunikation über TCP/IP-Netzwerke verwendet wird und die Verbindung über Port 502 herstellt. Es ist keine Prüfsummenberechnung erforderlich, da niedrigere Schichten bereits einen Prüfsummenschutz bieten.
• Modbus over TCP/IP, Modbus over TCP oder Modbus RTU/IP - eine Variante, die sich von Modbus TCP dadurch unterscheidet, dass eine Prüfsumme in der Nutzlast enthalten ist, wie bei Modbus RTU.
• Modbus over UDP - einige haben mit der Verwendung von Modbus over UDP in IP-Netzwerken experimentiert, wodurch die Overheads von TCP entfallen.
• Modbus Plus (Modbus+, MB+ oder MBP) - Modbus Plus ist eine Eigenentwicklung von Schneider Electric und unterstützt im Gegensatz zu den anderen Varianten die Peer-to-Peer-Kommunikation zwischen mehreren Clients. Es erfordert einen speziellen Coprozessor, um eine schnelle HDLC-ähnliche Token-Rotation zu ermöglichen. Es verwendet Twisted Pair mit 1 Mbit/s und umfasst eine Transformatorisolierung an jedem Knoten, wodurch es übergangs-/flankengetriggert statt spannungs-/pegelgetriggert ist. Für den Anschluss von Modbus Plus an einen Computer ist spezielle Hardware erforderlich, normalerweise eine Karte für den ISA-, PCI- oder PCMCIA-Bus.
• Pemex Modbus - eine Erweiterung des Standard-Modbus mit Unterstützung für historische und Durchflussdaten. Es wurde für das Öl- und Gasunternehmen Pemex zur Verwendung in der Prozesssteuerung entwickelt und hat sich nie allgemein durchgesetzt.
• Enron Modbus - eine weitere Erweiterung des Standard-Modbus, die von Enron entwickelt wurde und 32-Bit-Ganzzahl- und Fließkomma-Variablen sowie historische Daten und Durchflussdaten unterstützt. Die Datentypen werden über Standardadressen abgebildet. Die historischen Daten dienen dazu, einen Industriestandard des American Petroleum Institute (API) zu erfüllen, wie Daten gespeichert werden sollten. ⓘ

Die Datenmodelle und Funktionsaufrufe sind bei den ersten vier oben aufgeführten Varianten identisch, nur die Kapselung ist unterschiedlich. Die Varianten sind jedoch nicht interoperabel, ebenso wenig wie die Rahmenformate. ⓘ

Kommunikation und Geräte

Jedes Gerät, das über einen Modbus kommuniziert (d. h. Daten überträgt), erhält eine eindeutige Adresse. ⓘ

Bei Modbus RTU, Modbus ASCII und Modbus Plus (die alle RS-485-Einkabel-Multidrop-Netzwerke sind) kann nur der als Client zugewiesene Knoten einen Befehl initiieren. Alle anderen Geräte sind Server und antworten auf Anfragen und Befehle. ⓘ

Bei den Protokollen, die Ethernet verwenden, wie z. B. Modbus TCP, kann jedes Gerät einen Modbus-Befehl senden und somit können alle Geräte als Client fungieren, obwohl normalerweise nur ein Gerät diese Rolle hat. ⓘ

Viele Modems und Gateways unterstützen Modbus, da es sich um ein einfaches und oft kopiertes Protokoll handelt. Einige von ihnen wurden speziell für dieses Protokoll entwickelt. Verschiedene Implementierungen verwenden drahtgebundene oder drahtlose Kommunikation, z. B. im ISM-Funkband, und sogar Short Message Service (SMS) oder General Packet Radio Service (GPRS). Eines der gängigsten Konzepte für drahtlose Netze ist das Mesh Networking. Zu den typischen Problemen, die die Entwickler zu bewältigen haben, gehören hohe Latenzzeiten und Zeitprobleme. ⓘ

Befehle

Modbus-Befehle können ein Modbus-Gerät anweisen,:

• den Wert in einem seiner Register zu ändern, der in die Coil- und Holding-Register geschrieben wird
• einen E/A-Anschluss zu lesen: Daten von einem diskreten Eingang oder von einer Spule zu lesen
• dem Gerät befehlen, einen oder mehrere Werte aus seinen Coil- und Holding-Registern zurückzusenden ⓘ

Ein Modbus-Befehl enthält die Modbus-Adresse des Geräts, für das er bestimmt ist (1 bis 247). Nur das adressierte Gerät antwortet auf den Befehl und führt ihn aus, auch wenn andere Geräte ihn empfangen können (eine Ausnahme sind bestimmte broadcastfähige Befehle, die an Knoten 0 gesendet werden, die zwar ausgeführt, aber nicht bestätigt werden). ⓘ

Alle Modbus-Befehle enthalten Prüfsummeninformationen, damit der Empfänger Übertragungsfehler erkennen kann. ⓘ

Rahmenformate

Ein Modbus-"Rahmen" besteht aus einer Anwendungsdateneinheit (ADU), die eine Protokolldateneinheit (PDU) einkapselt:

• ADU = Adresse + PDU + Fehlerprüfung.
• PDU = Funktionscode + Daten. ⓘ

In Modbus-Datenrahmen wird das höchstwertige Byte eines Multi-Byte-Wertes vor den anderen gesendet. ⓘ

Alle Modbus-Varianten verwenden eines der folgenden Rahmenformate. ⓘ

Modbus-RTU-Rahmenformat

Dieses Format wird hauptsächlich auf asynchronen seriellen Datenleitungen wie RS-485/EIA-485 verwendet. Sein Name bezieht sich auf eine Fernbedienungseinheit. ⓘ

Bezeichnung	Länge (Bits)	Funktion ⓘ
Beginn	3.5 x 8	Mindestens 3+1⁄2 Zeichen mal (28 Bits) Stille (Markierungsbedingung)
Adresse	8	Stationsadresse
Funktion	8	Gibt den Funktionscode an, z. B. "Spulen lesen".
Daten	n × 8	Daten + Länge werden je nach Nachrichtentyp aufgefüllt
CRC	16	Zyklische Redundanzprüfung
Ende	3.5 x 8	Mindestens 3+1⁄2 Zeichenzeiten (28 Bits) Stille (Markierungsbedingung) zwischen Rahmen

CRC-Berechnung:

• Polynom: x¹⁶ + x¹⁵ + x² + 1 (CRC-16-ANSI auch bekannt als CRC-16-IBM, normales hexadezimales algebraisches Polynom ist 8005 und umgekehrt A001).
• Anfangswert: 65.535.
• Beispiel eines Frames in Hexadezimal: 01 04 02 FF FF B8 80 (CRC-16-ANSI-Berechnung für die 5 Bytes von 01 bis FF ergibt 80B8, das niedrigstwertige Byte wird zuerst übertragen). ⓘ

Modbus-ASCII-Rahmenformat

Wird hauptsächlich auf asynchronen seriellen 7-Bit- oder 8-Bit-Leitungen verwendet. ⓘ

Bezeichnung	Länge (Bytes)	Funktion ⓘ
Beginn	1	Doppelpunkt: (ASCII-Wert 3A16)
Adresse	2	Stationsadresse
Funktion	2	Gibt den Funktionscode an, z. B. "Spulen lesen".
Daten	n × 2	Daten + Länge werden je nach Nachrichtentyp aufgefüllt
LRC	2	Prüfsumme (Längsredundanzprüfung)
Ende	2	Paar aus Wagenrücklauf und Zeilenvorschub (CR/LF) (ASCII-Werte 0D16 und 0A16)

Adresse, Funktion, Daten und LRC sind hexadezimal kodierte ASCII-Werte, wobei 8-Bit-Werte (0-255) als zwei für Menschen lesbare ASCII-Zeichen aus den Bereichen 0-9 und A-F kodiert werden. Ein Wert von 122 (7A₁₆) wird beispielsweise als zwei ASCII-Zeichen, "7" und "A", kodiert und als zwei Bytes, 55 (37₁₆, ASCII-Wert für "7") und 65 (41₁₆, ASCII-Wert für "A"), übertragen. ⓘ

LRC wird als Summe von 8-Bit-Werten (ohne Start- und Endzeichen) berechnet, negiert (Zweierkomplement) und als 8-Bit-Wert kodiert. Wenn z. B. Adresse, Funktion und Daten 247, 3, 19, 137, 0 und 10 sind, ist das Zweierkomplement ihrer Summe (416) -416; auf 8 Bits gekürzt ist dies 96 (256 × 2 - 416 = 60₁₆), was den folgenden 17-ASCII-Zeichenrahmen ergibt: :F7031389000A60␍␊. LRC ist nur für die Verwendung als Prüfsumme spezifiziert: Da sie auf den kodierten Daten und nicht auf den übertragenen Zeichen berechnet wird, ist ihre "Längs"-Charakteristik nicht für die Verwendung mit Paritätsbits zur Lokalisierung von Einzelbitfehlern verfügbar. ⓘ

Protokollaufbau ⓘ

Im ASCII-Modus beginnen Nachrichten mit einem vorangestellten Doppelpunkt, das Ende der Nachricht wird durch die Zeichenfolge Carriage return – Line feed (CRLF) markiert. ⓘ

Modbus-TCP-Rahmenformat

Wird in erster Linie in Ethernet-Netzwerken verwendet. ⓘ

Bezeichnung	Länge (Bytes)	Funktion ⓘ
Transaktionsbezeichner	2	Für die Synchronisation zwischen Nachrichten von Server und Client
Protokoll-Identifikator	2	0 für Modbus/TCP
Feld Länge	2	Anzahl der verbleibenden Bytes in diesem Rahmen
Einheitskennung	1	Server-Adresse (255, wenn nicht verwendet)
Funktionscode	1	Funktionscodes wie in anderen Varianten
Datenbytes	n	Daten als Antwort oder Befehle

Unit Identifier wird bei Modbus/TCP-Geräten verwendet, die aus mehreren Modbus-Geräten zusammengesetzt sind, z. B. Modbus/TCP zu Modbus RTU Gateways. In einem solchen Fall ist der Unit Identifier die Serveradresse des Geräts hinter dem Gateway. Nativ Modbus/TCP-fähige Geräte ignorieren normalerweise den Unit Identifier. ⓘ

Im Oktober 2018 wurde eine sichere Variante Modbus/TCP Protokoll auf Basis Transport Layer Security (TLS) veröffentlicht. Diese nutzt X.509v3 digitale Zertifikate zur Authentifizierung von Server und Client. Damit sollen Angriffe auf vernetzte Modbus/TCP-Komponenten (z. B. Man-in-the-Middle-Angriffe) verhindert werden. Das sichere Modbus/TCP bietet auch eine rollenbasierte Zugriffssteuerung. Es nutzt den TCP-Port 802. Das Protokoll wird in der MODBUS/TCP Security Protocol Specification beschrieben. ⓘ

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. Modbus/TCP ist seit 2007 in der Norm IEC 61158 festgelegt und wird in IEC 61784-2 als CPF 15/1 referenziert. ⓘ

Protokollaufbau ⓘ

Dadurch, dass hier keine CRC-Prüfsummenbytes zu berechnen sind, ist die Implementierung eines Treibers für die TCP-Schnittstelle einfacher als für die serielle Schnittstelle, sofern man auf eine vorhandene TCP-Implementierung aufsetzen kann. ⓘ

Funktionen und Befehle

Zu den wichtigsten konzeptionellen Einheiten in einem Modbus-Server gehören die folgenden:

• Spulen: lesbar und schreibbar, 1 Bit (aus/ein)
• Diskrete Eingänge: nur lesbar, 1 Bit (aus/ein)
• Eingangsregister: nur lesbare Messungen und Zustände, 16 Bit (0-65.535)
• Holding-Register: lesbare und schreibbare Konfigurationswerte, 16 Bits (0-65.535) ⓘ

Die Befehle zum Lesen und Schreiben dieser Einheiten sind in der folgenden Tabelle zusammengefasst. Die primitivsten Lese- und Schreibbefehle sind fett gedruckt. ⓘ

Einige Quellen verwenden eine vom Standard abweichende Terminologie, z. B. Force Single Coil anstelle von Write Single Coil. ⓘ

Modbus-Funktionscodes ⓘ

Funktionstyp			Name der Funktion	Funktionscode	Kommentar
Daten Zugriff	Bit-Zugriff	Physikalisch Diskrete Eingänge	Diskrete Eingänge lesen	2
		Interne Bits oder physikalische Spulen	Lesen von Spulen	1
			Schreiben einer einzelnen Spule	5
			Schreiben mehrerer Spulen	15
	16-Bit-Zugriff	Physikalische Eingaberegister	Lesen von Eingangsregistern	4
		Interne Register oder physikalische Ausgaberegister	Mehrere Holding-Register lesen	3
			Schreiben eines einzelnen Holding Registers	6
			Mehrere Holding-Register schreiben	16
			Lesen/Schreiben von mehreren Registern	23
			Register schreiben maskieren	22
			FIFO-Warteschlange lesen	24
	File Record Zugriff		Dateisatz lesen	20
			Dateisatz schreiben	21
Diagnose			Ausnahmestatus lesen	7	nur seriell
			Diagnose	8	nur seriell
			Com-Ereigniszähler abrufen	11	nur seriell
			Com-Ereignisprotokoll abrufen	12	nur seriell
			Server-ID melden	17	nur seriell
			Geräteidentifikation lesen	43
Andere			Gekapselte Schnittstelle Transport	43

Format der Anfragen und Antworten

Anfragen und Antworten folgen den oben beschriebenen Rahmenformaten. In diesem Abschnitt werden die Datenformate der am häufigsten verwendeten Funktionscodes näher erläutert. ⓘ

Funktionscodes 1 (Spulen lesen) und 2 (diskrete Eingänge lesen)

Abfrage:

• Adresse der ersten zu lesenden Spule/des ersten diskreten Eingangs (16 Bit)
• Anzahl der zu lesenden Spulen/Diskreteingänge (16-Bit) ⓘ

Normale Antwort:

• Anzahl der Bytes der zu folgenden Spulen-/Diskreteingangswerte (8-Bit)
• Spulen-/Diskreteingangswerte (8 Spulen/Diskreteingänge pro Byte) ⓘ

Der Wert jeder Spule/jedes diskreten Eingangs ist binär (0 für Aus, 1 für Ein). Die erste angeforderte Spule/der erste diskrete Eingang wird als niederwertigstes Bit des ersten Bytes der Antwort gespeichert. Wenn die Anzahl der Spulen/Diskreteingänge kein Vielfaches von 8 ist, wird das höchstwertige Bit des letzten Bytes mit Nullen aufgefüllt. ⓘ

Wenn zum Beispiel elf Spulen angefordert werden, sind zwei Bytes mit Werten erforderlich. Angenommen, die Zustände dieser aufeinanderfolgenden Spulen sind ein, aus, ein, aus, aus, ein, ein, ein, aus, ein, ein, dann lautet die Antwort 02 E5 06 in hexadezimaler Darstellung. ⓘ

Da die in der Antwortnachricht zurückgegebene Bytezahl nur 8 Bit breit ist und der Protokoll-Overhead 5 Byte beträgt, können maximal 2008 (251 x 8) diskrete Eingänge oder Spulen auf einmal gelesen werden. ⓘ

Funktionscode 5 (Erzwingen/Schreiben einer einzelnen Spule)

Abfrage:

• Adresse der Spule (16-Bit)
• Zu erzwingender/zu schreibender Wert: 0 für aus und 65.280 (FF00 in Hexadezimal) für an

Normale Antwort: wie bei der Anfrage. ⓘ

Funktionscode 15 (mehrere Spulen erzwingen/schreiben)

Abfrage:

• Adresse der ersten zu erzwingenden/schreibenden Spule (16 Bit)
• Anzahl der zu erzwingenden/schreibenden Spulen (16-Bit)
• Anzahl der Bytes der zu folgenden Spulenwerte (8-Bit)
• Spulenwerte (8 Spulenwerte pro Byte)

Der Wert jeder Spule ist binär (0 für Aus, 1 für Ein). Die erste angeforderte Spule wird als niederwertigstes Bit des ersten Bytes in der Anfrage gespeichert. Wenn die Anzahl der Spulen nicht ein Vielfaches von 8 ist, sollte(n) das/die höchstwertige(n) Bit(s) des letzten Bytes mit Nullen aufgefüllt werden. Siehe Beispiel für die Funktionscodes 1 und 2. ⓘ

Normale Antwort:

• Adresse der ersten Spule (16-Bit)
• Anzahl der Spulen (16-Bit) ⓘ

Funktionscodes 4 (Lesen von Eingangsregistern) und 3 (Lesen von Halteregistern)

Abfrage:

• Adresse des ersten zu lesenden Registers (16-Bit)
• Anzahl der zu lesenden Register (16-Bit)

Normale Antwort:

• Anzahl der Bytes der zu folgenden Registerwerte (8 Bit)
• Registerwerte (16 Bit pro Register)

Da die maximale Länge einer Modbus-PDU 253 beträgt (abgeleitet von der maximalen Modbus-ADU-Länge von 256 auf RS485), können bis zu 125 Register auf einmal angefordert werden, wenn das RTU-Format verwendet wird, und bis zu 123 über TCP. ⓘ

Funktionscode 6 (Voreinstellen/Schreiben eines einzelnen Holdingregisters)

Abfrage:

• Adresse des zu setzenden/schreibenden Holdingregisters (16 Bit)
• Neuer Wert des Holdingregisters (16 Bit)

Normale Antwort: wie bei der Anfrage. ⓘ

Funktionscode 16 (Voreinstellen/Schreiben mehrerer Holdingregister)

Abfrage:

• Adresse des ersten zu setzenden/schreibenden Holdingregisters (16-Bit)
• Anzahl der zu setzenden/schreibenden Holding-Register (16-Bit)
• Anzahl der Bytes der zu folgenden Registerwerte (8 Bit)
• Neue Werte der Holding-Register (16 Bit pro Register)

Da die maximale Länge einer Modbus-PDU 253 beträgt (abgeleitet von der maximalen Modbus-ADU-Länge von 256 bei RS485), können bis zu 123 Register auf einmal geschrieben werden. ⓘ

Normale Antwort:

• Adresse des ersten voreingestellten/beschriebenen Holdingregisters (16 Bit)
• Anzahl der voreingestellten/beschriebenen Holding-Register (16-Bit) ⓘ

Ausnahmereaktionen

Bei einer normalen Antwort wiederholt der Server den Funktionscode. Wenn ein Server einen Fehler melden möchte, antwortet er mit dem angeforderten Funktionscode plus 128 (hex 0x80) (3 wird zu 131 = hex 0x83) und enthält nur ein Byte Daten, den so genannten Ausnahmecode. ⓘ

Wichtigste Modbus-Ausnahmecodes

Code	Text	Einzelheiten ⓘ
1	Unerlaubte Funktion	Der in der Abfrage empfangene Funktionscode wird vom Server nicht erkannt oder ist nicht zulässig.
2	Unzulässige Datenadresse	Die Datenadressen einiger oder aller erforderlichen Entitäten sind nicht zulässig oder existieren nicht auf dem Server.
3	Unzulässiger Datenwert	Der Wert wird vom Server nicht akzeptiert
4	Server-Geräte-Fehler	Ein nicht behebbarer Fehler ist aufgetreten, während der Server versucht hat, die angeforderte Aktion durchzuführen.
5	Bestätigen Sie	Der Server hat die Anfrage akzeptiert und verarbeitet sie, aber es wird eine längere Zeit benötigt. Diese Antwort wird zurückgesendet, um zu verhindern, dass beim Client ein Timeout-Fehler auftritt. Der Client kann als Nächstes eine Nachricht Poll Program Complete ausgeben, um festzustellen, ob die Verarbeitung abgeschlossen ist.
6	Server-Gerät beschäftigt	Der Server ist mit der Verarbeitung eines Befehls von langer Dauer beschäftigt. Der Client sollte es später erneut versuchen.
7	Negatives Acknowledge	Server kann die Programmierfunktionen nicht ausführen. Client sollte Diagnose- oder Fehlerinformationen vom Server anfordern
8	Speicher-Paritätsfehler	Der Server hat einen Paritätsfehler im Speicher festgestellt. Der Client kann die Anforderung wiederholen, aber möglicherweise ist eine Wartung des Servergeräts erforderlich.
10	Gateway-Pfad nicht verfügbar	Speziell für Modbus-Gateways. Weist auf ein falsch konfiguriertes Gateway hin
11	Gateway-Zielgerät hat nicht geantwortet	Speziell für Modbus-Gateways. Wird gesendet, wenn der Server nicht antwortet

Entitätsnummern und Adressen

Die Modbus-Organisation erwähnt das Folgende im Modbus-Anwendungsprotokoll v1.1b:

• Das Modbus-Anwendungsprotokoll definiert die PDU-Adressierungsregeln: In einer PDU wird jedes Datenelement von 0 bis 65535 adressiert.
• Es definiert auch ein MODBUS-Datenmodell, das aus vier Blöcken besteht, die mehrere von 1 bis n nummerierte Elemente umfassen.
• Im Modbus-Datenmodell ist jedes Element innerhalb eines Datenblocks von 1 bis n durchnummeriert. ⓘ

Einige Konventionen regeln, wie Modbus-Elemente (Spulen, diskrete Eingänge, Eingangsregister, Halteregister) referenziert werden. ⓘ

Es ist wichtig, zwischen Entitätsnummer und Entitätsadresse zu unterscheiden:

• Entitätsnummern kombinieren Entitätstyp und Entitätsort innerhalb ihrer Beschreibungstabelle
• Die Entitätsadresse ist die Startadresse, ein 16-Bit-Wert im Datenteil des Modbus-Rahmens, der von 0 bis 65.535 (0000 bis FFFF in den Paketen) reicht. ⓘ

In der traditionellen Konvention beginnen Entity-Nummern mit einer Ziffer, die den Entity-Typ angibt, gefolgt von vier Ziffern, die den Standort des Entity angeben:

• Coil-Nummern beginnen mit 0 und reichen von 00001 bis 09999,
• die Nummern der diskreten Eingänge beginnen mit 1 und reichen von 10001 bis 19999,
• Die Nummern der Holdingregister beginnen mit 4 und reichen von 40001 bis 49999.

Für die Datenkommunikation wird die Entity-Position (1 bis 9.999) in eine 0-basierte Entity-Adresse (0 bis 9.998) übersetzt, indem 1 abgezogen wird. Um z. B. Holding-Register ab Nummer 40001 zu lesen, enthält der Datenrahmen den Funktionscode 3 (wie oben dargestellt) und die Adresse 0. Bei den Registern, die mit der Nummer 40100 beginnen, lautet die Adresse 99. ⓘ

Dies begrenzt die Anzahl der Adressen auf 9.999 für jede Einheit. Ein De-facto-Standard erweitert diese Zahl auf 65.536, indem er der vorherigen Liste eine Ziffer hinzufügt:

• Coil-Nummern reichen von 000001 bis 065536,
• die Nummern der diskreten Eingänge reichen von 100001 bis 165536,
• die Nummern der Eingangsregister reichen von 300001 bis 365536,
• Die Nummern der Holding-Register reichen von 400001 bis 465536.

Bei Verwendung der erweiterten Referenzierung müssen alle Nummernreferenzen genau 6 Ziffern haben, um Verwechslungen zwischen Spulen und anderen Einheiten zu vermeiden. Um beispielsweise zwischen dem Holding-Register #40001 und der Spule #40001 zu unterscheiden, muss die Spule #40001, wenn sie das Ziel ist, als #040001 erscheinen. ⓘ

Eine andere Möglichkeit, die Datenadressen zu notieren, ist die Verwendung des Hexadezimalwerts, der die Verwendung der vier Ziffern in der zuvor erwähnten traditionellen Konvention verdeutlicht.

• Spulennummern reichen von 0x0000 bis 0xFFFF
• die Nummern der diskreten Eingänge reichen von 1x0000 bis 1xFFFF
• Eingangsregisternummern reichen von 3x0000 bis 3xFFFF
• Die Nummern der Halteregister reichen von 4x0000 bis 4xFFFF

Der Vorteil dieser Notation ist, dass bei der Dekodierung von Modbus-Paketen dieselben Nummern gefunden werden. ⓘ

JBUS-Zuordnung

Ein weiteres de facto-Protokoll, das eng mit Modbus verwandt ist, tauchte später auf und wurde vom SPS-Hersteller April Automates definiert. Es war das Ergebnis einer Zusammenarbeit zwischen den französischen Unternehmen Renault Automation und Merlin Gerin et Cie im Jahr 1985: JBUS. Die damaligen Unterschiede zwischen Modbus und JBUS (Anzahl der Entitäten, Server-Stationen) sind heute irrelevant, da dieses Protokoll mit der April-SPS-Serie, die 1994 von AEG Schneider Automation aufgekauft und dann überflüssig gemacht wurde, fast verschwunden ist. Der Name JBUS hat jedoch bis zu einem gewissen Grad überlebt. ⓘ

JBUS unterstützt die Funktionscodes 1, 2, 3, 4, 5, 6, 15 und 16 und damit alle oben beschriebenen Einheiten, obwohl die Nummerierung unterschiedlich ist:

• Nummer und Adresse stimmen überein: Entität #x hat die Adresse x im Datenrahmen.
• Folglich enthält die Entitätsnummer nicht den Entitätstyp. Zum Beispiel ist das Holding-Register #40010 im Modbus das Holding-Register #9 an der Adresse 9 im JBUS.
• Die Nummer 0 (und damit die Adresse 0) wird nicht unterstützt. Der Server sollte keine realen Daten unter dieser Nummer und Adresse implementieren, und er kann einen Nullwert zurückgeben oder einen Fehler auslösen, wenn er dazu aufgefordert wird. ⓘ

Implementierungen

Fast jede Implementierung hat Abweichungen vom offiziellen Standard. Verschiedene Varianten kommunizieren möglicherweise nicht korrekt zwischen Geräten verschiedener Anbieter. Einige der häufigsten Abweichungen sind:

• Datentypen
  • IEEE 754 Gleitkommazahl
  • 32-Bit-Ganzzahl
  • 8-Bit-Daten
  • Gemischte Datentypen
  • Bitfelder in Ganzzahlen
  • Multiplikatoren zur Umwandlung von Daten in/aus Ganzzahlen. 10, 100, 1000, 256, ...
• Protokoll-Erweiterungen
  • 16-Bit-Server-Adressen
  • 32-Bit-Datengröße (1 Adresse = 32 Bit zurückgegebene Daten)
  • Word-swapped Daten ⓘ

Modbus Plus

Trotz des Namens ist Modbus Plus keine Variante von Modbus. Es handelt sich um ein anderes Protokoll, das Token-Passing beinhaltet. Es handelt sich um eine proprietäre Spezifikation von Schneider Electric, die allerdings nicht patentiert, sondern unveröffentlicht ist. Es wird normalerweise mit einem kundenspezifischen Chipsatz implementiert, der nur für Partner von Schneider erhältlich ist. ⓘ