Modbus Inbetriebnahme: Checkliste und Spickzettel

Eine Modbus-Inbetriebnahme-Checkliste listet auf, was eine laufende Anlage gerade nicht beweist. Der Bus kann sauber pollen, während Adressplan, Skalierung und Poll-Intervall nur in Ihrem Kopf stehen. Diese Lektion gibt Ihnen drei Checklisten, einen Spickzettel für die Werkzeugkiste und einen Abschlusstest, der jeden Fehler auf eine bestimmte Lektion zurückführt.

Was Sie übergeben, wenn alles läuft

Sie übergeben nicht einen laufenden Bus, sondern die Angaben, mit denen jemand anders ihn übernehmen kann. Konkret gehören acht Dinge in das Dossier:

1. Adressplan. Welches Gerät trägt welche Serveradresse, und wo hängt es physisch.
2. Serielle Parameter. Baudrate, Parität und Stoppbits pro Segment, einmal notiert statt dreimal ermittelt.
3. Netzwerkdaten. IP-Adresse, Port und Unit-ID pro Gerät.
4. Registertabelle pro Gerät. Register, Zählweise, Datentyp, Word Order, Skalierung und Sentinelwerte.
5. Poll-Intervalle mit Begründung. Die gemessene Zykluszeit und die Buslast, die daraus folgt.
6. Alarmregeln. Schwelle, Empfänger und das Datum, an dem die Regel einmal wirklich ausgelöst hat.
7. Topologie. Wo die Linie beginnt und endet, und an welchen zwei Punkten die Terminierung sitzt.
8. Offene Punkte. Was bewusst nicht gemacht wurde, mit dem Grund dahinter.

Steht ein Gateway zwischen Bus und Netzwerk, gehören auch dessen Grenzen dazu: wie viele gleichzeitige Verbindungen es verträgt und wie es Serveradressen auf Unit-IDs abbildet. Welche Bauformen es gibt und worauf Sie beim Kauf achten, steht in der Kaufberatung für Modbus-Gateways.

Punkt 5 und 6 lassen sich leichter zeigen als behaupten. Eine Logsitzung aus ModbusCloud Diagnostics exportiert nach CSV oder JSON, und diese Datei legen Sie unverändert ins Dossier, als die Messung, auf der Ihre Intervalle und Schwellen beruhen.

Die Checkliste für die Physik

Die Physik haken Sie in der Reihenfolge ab, in der die Fehler dort entstehen: Topologie, Terminierung, Länge, Anzahl der Geräte, Beschriftung.

• Eine Linie, kein Stern. RS485 verträgt keine Sternverkabelung. Wer aus KNX oder aus der 230-V-Installation kommt, hält das für eine Formalie, und genau daher kommt der Bus, der mit drei Geräten läuft und beim vierten aussteigt.
• Stichleitungen kurz halten. Die Spezifikation nennt 20 m als Obergrenze für eine Stichleitung, bei einer Abzweigung mit n Stichen entsprechend 40 geteilt durch n Meter.
• Genau zwei Terminierungen. An den beiden physischen Enden, sonst nirgends. Die Spezifikation nennt 150 Ohm als einfache Variante und 120 Ohm mit 1 nF in Reihe als bessere.
• Biasing bewusst setzen. Vorgesehen sind 450 bis 650 Ohm gegen 5 V. Diese Beschaltung kostet Sie 4 der 32 Geräte, die ohne Repeater erlaubt sind.
• Länge und Querschnitt. Bis 1000 m bei 9600 Baud, wenn die Leitung AWG26 oder dicker ist. Für Cat5 nennt die Spezifikation 600 m.
• Drei Leiter, nicht zwei. Ein Two-wire-Bus führt D0, D1 und einen Common. Der dritte Leiter fehlt in der Praxis am häufigsten.
• Ruhepegel messen. In Ruhe liegt D1 (B, D+) positiver als D0 (A, D-). Dreht die Messung das Vorzeichen um, ist das Adernpaar vertauscht.
• Beschriftung. Baudrate, Parität und Serveradresse auf ein Etikett an der Klemmenleiste, solange Sie die Werte noch im Kopf haben.

Die Checkliste für das Protokoll

Beim Protokoll geht es um zwei Fragen: Kommt Ihre Anfrage an, und bedeutet die Antwort das, was Sie denken.

• Serveradressen eindeutig. 1 bis 247 für einzelne Geräte, 0 ist Broadcast, 248 bis 255 sind reserviert.
• Zählweise notieren. Zu jedem Register gehört die Angabe, ob die Zahl aus dem Datenblatt 1-basiert ist oder ob es die 0-basierte PDU-Adresse ist. Der Unterschied beträgt genau 1 und ist die häufigste Ursache für Werte, die um ein Feld verrutscht sind.
• Block und Funktionscode. Holding-Register lesen Sie mit FC03, Input-Register mit FC04. Ein Gerät, das beide Blöcke führt, antwortet auf den falschen Funktionscode mit Exception 02 oder mit einem völlig fremden Wert.
• Anzahl pro Anfrage. 125 Register lesen, 123 schreiben, 2000 Coils lesen, 1968 schreiben. Wer darüber geht, bekommt Exception 03.
• Datentyp und Word Order. Innerhalb eines Registers ist die Reihenfolge big-endian und festgelegt, zwischen zwei Registern nicht. Welche der vier Kombinationen Ihr Gerät verwendet, gehört ins Dossier; die Herleitung steht in der Lektion zu Datentypen und Word Order.
• Erst filtern, dann skalieren. Sentinelwerte wie 0x8000 für int16, 0x80000000 für int32 und 0xFFFF für uint16 bedeuten nicht belegt. Wer sie skaliert, erzeugt Messwerte, die nach einem Defekt aussehen.

Die Checkliste für das Netzwerk

Im Netzwerk prüfen Sie, wer das Gerät erreichen kann und unter welcher Kennung es antwortet.

• Feste IP-Adresse außerhalb des DHCP-Bereichs, im Dossier notiert.
• Port. 502 ist der registrierte Port und muss erreichbar bleiben, auch wenn zusätzlich ein anderer konfiguriert ist. Port 802 gehört zu Modbus/TCP Security.
• Unit-ID. Bei einem nativen TCP-Gerät ist 0xFF empfohlen, 0x00 ebenfalls erlaubt. Hinter einem Gateway steht dort die echte Serveradresse aus dem Bereich 1 bis 247. Das ist die Stelle, an der eine Anlage funktioniert, bis jemand ein zweites Gerät hinter dasselbe Gateway hängt.
• Verbindungen zählen. Der Implementation Guide nennt 1 bis 16 gleichzeitige Transaktionen; ist der Vorrat erschöpft, antwortet der Server mit Exception 06. Zwei Clients, die dasselbe Gerät abfragen, sind einen Eintrag im Dossier wert.
• Verbindungsform. Eine ausgehende Verbindung braucht keine Portweiterleitung. Alles, was von außen hereinkommt, ist eine bewusste Entscheidung und gehört begründet ins Dossier.
• Buslast unter 50 Prozent. Das ist die Faustregel dieses Kurses und keine Vorgabe der Spezifikation: Das Poll-Intervall beträgt mindestens die doppelte gemessene Zykluszeit. Wer später etwas ergänzt, sieht so sofort, wie viel Luft noch da ist.

Der Spickzettel für unterwegs

Alles, was Sie auf der Baustelle wirklich nachschlagen, passt auf eine Karte: die Obergrenzen pro Anfrage, die Codes, die zurückkommen, und die Verdrahtungsregeln.

Drucken Sie die Karte aus und legen Sie sie in die Werkzeugkiste. Die beiden Quellen dahinter, die Application Protocol Specification und der Serial Line Guide, stehen bei der Modbus Organization.

Was Sie jetzt können, und was bleibt

Fünf Sätze tragen alles, was in diesem Kurs steht. Modbus ist ein Frage-Antwort-Protokoll ohne eingebaute Bedeutung: Was ein Register bedeutet, legt der Hersteller fest, nicht das Protokoll. Ein Register ist 16 Bit breit, alles Größere ist eine Vereinbarung darüber, wie man Register aneinanderhängt. RTU und TCP transportieren dieselbe PDU in einer anderen Hülle. Die meisten Störungen sind keine Protokollfehler, sondern Physik und Adressierung. Und die zwei Zählweisen, Datenblattnummer gegen 0-basierte PDU-Adresse, sind die häufigste Ursache dafür, dass jemand Unsinn ausliest.

Der Satz, den Sie behalten sollten: Bevor Sie bei einer Störung irgendetwas anfassen, stellen Sie fest, ob Sie Stille, eine Exception oder einen falschen Wert vor sich haben. Diese Unterscheidung schließt zwei von drei Suchbereichen aus, und sie kostet weder Zeit noch Werkzeug. Ausführlich steht sie in der Lektion zur RTU-Fehlersuche.

Bewusst außen vor geblieben sind Modbus ASCII, Modbus Plus, Modbus über UDP sowie BACnet, M-Bus, KNX und OPC UA. Das sind eigene Protokolle mit eigenen Regeln. Für den Übergang zwischen ihnen brauchen Sie ein Gateway, keinen weiteren Modbus-Kniff.

Wie es weitergeht

Drei Wege stehen offen, und sie schließen sich nicht aus. Der erste ist die Quelle selbst: Die beiden Spezifikationen beantworten jede Frage, die dieser Kurs offen lässt, und sie kosten nichts. Der zweite ist das Nachschlagen pro Marke. Wenn ein Wechselrichter, ein Zähler oder eine Wärmepumpe vor Ihnen steht, entscheidet deren Registertabelle, nicht das Protokoll.

Der dritte Weg ist die Frage, ob Sie das Auslesen selbst bauen oder ein fertiges Produkt einsetzen. Selbst bauen heißt: eigener Client, eigene Poll-Logik, eigene Alarme, eigene Verfügbarkeit. Fertige Wege gibt es ebenfalls: Home Assistant für die Gebäudetechnik im Kleinen, eine SPS oder ein SCADA-System im industriellen Umfeld, und Plattformen wie ModbusCloud, die Gateway-Hardware und Registerübersetzung mitbringen. Was ein vorkonfigurierter Ansatz konkret abnimmt, steht in der Übersicht zu Plug-and-play-Modbus-Monitoring, und wie Sie Schwellen und Empfänger festlegen, steht in der Anleitung zu automatischen Modbus-Benachrichtigungen. Vorbereitete Registertabellen für gängige Geräte liegen in der Vorlagenbibliothek, die passende Hardware finden Sie unter ModbusCloud Gateway.

Häufige Fehler

Ohne Dossier übergeben. Die Anlage läuft, also wirkt sie fertig. Ein halbes Jahr später weiß niemand mehr, warum ein Messwert durch zehn geteilt wird, und die nächste Erweiterung beginnt mit einer Woche Rückwärtsforschung. Schreiben Sie die Begründung neben jede Einstellung, nicht nur den Wert.

Keine Beschriftung an der Klemmenleiste. Baudrate, Parität und Serveradresse auf einem Etikett ersparen dem nächsten Monteur eine Stunde Durchprobieren. Ohne Etikett bleibt ihm nur, Kombinationen zu testen, und das an einer Anlage, die in Betrieb ist.

Alarmregeln ungetestet übergeben. Eine Regel, die nie ausgelöst hat, meldet sich im Ernstfall zu spät oder gar nicht. Provozieren Sie den Alarm einmal absichtlich und notieren Sie das Datum dazu.

Poll-Intervalle ohne Begründung. Steht nur alle 10 Sekunden im Dossier, weiß der Nächste nicht, ob das die Grenze war oder eine Vorsichtsmaßnahme. Notieren Sie die gemessene Zykluszeit daneben, dann sieht er sofort, wie viel Luft bleibt.

Selbst ausprobieren

Ziel: Sie übergeben eine echte oder eine gedachte Anlage nach Checkliste.

1. 1

   Anlage wählen

   Nehmen Sie eine Anlage, an der Sie gerade arbeiten, oder denken Sie sich eine mit drei Geräten aus: ein Zähler, ein Wechselrichter und eine Wärmepumpe.

2. 2

   Drei Checklisten abhaken

   Gehen Sie Physik, Protokoll und Netzwerk der Reihe nach durch. Abhaken dürfen Sie nur, was Sie gemessen oder ausgelesen haben, nicht was Sie annehmen.

3. 3

   Offene Punkte zuordnen

   Notieren Sie zu jedem offenen Punkt, welche Lektion Sie darauf zurückbringt. Ein offener Punkt ohne Zuordnung wird nie geschlossen.

4. 4

   Spickzettel drucken

   Drucken Sie die Karte aus dem Abschnitt oben aus und legen Sie sie in die Werkzeugkiste oder in die Tasche.

5. 5

   Dossier schreiben

   Adressplan, serielle Parameter, Registertabelle pro Gerät, Poll-Intervalle, Alarmregeln und die Begründung jeder Entscheidung. Eine Seite pro Gerät reicht.

6. 6

   Abschlusstest machen

   Machen Sie den Test unter dieser Lektion. Jede falsche Antwort zeigt auf eine bestimmte Lektion, nicht auf ein Gefühl.

Ohne Anlage. Bauen Sie zwei Geräte in dem Simulator nach, den Sie in der Lektion zum Üben mit dem Simulator eingerichtet haben, und übergeben Sie sie, als wäre es eine Kundenanlage. Das Dossier fällt kürzer aus, die Disziplin bleibt dieselbe.

Erwartetes Ergebnis: drei ausgefüllte Checklisten, ein gedruckter Spickzettel und ein Dossier, das jemand anders lesen kann.

Zusammenfassung

• Eine Anlage ist erst übergeben, wenn Adressplan, Registertabellen, Poll-Intervalle und Alarmregeln schriftlich vorliegen, nicht schon dann, wenn der Bus läuft.
• Die drei Checklisten trennen die drei Fehlerwelten: Physik, Protokoll und Netzwerk lassen sich unabhängig voneinander abhaken.
• Die Kernzahlen passen auf eine Karte: 1 bis 247 Serveradressen, 125 Register pro Leseanfrage, 123 pro Schreibanfrage, Port 502 und 260 Bytes maximale TCP-ADU.
• Symptom vor Werkzeug: Stille, Exception und falscher Wert zeigen jeweils in einen anderen Bereich und halbieren Ihr Suchgebiet, bevor Sie etwas anfassen.
• Wer weitergehen will, hat drei Quellen: die Spezifikationen, das Datenblatt der jeweiligen Marke, und die Entscheidung zwischen Eigenbau und fertigem Produkt.