Alle Lektionen anzeigen
Teil 1
Grundlagen
Teil 2
Modbus RTU
- Lektion 5RS485 erklärt: A, B, Common und Terminierung20 Min.
- Lektion 6Baudrate und Parität: warum 8E1 Standard ist16 Min.
- Lektion 7Das Modbus RTU Frame Byte für Byte, plus CRC18 Min.
- Lektion 8Mehrere Modbus Geräte an einem RS485-Bus16 Min.
- Lektion 9Ihr erstes Modbus Gerät mit mbpoll auslesen22 Min.
- Lektion 10Modbus RTU Fehlersuche: vom Symptom zur Ursache20 Min.
Teil 3
Modbus TCP
Teil 4
Fortgeschritten
- Lektion 16Sicher auf ein Modbus Gerät schreiben18 Min.
- Lektion 17Word Order und Float: gleiche Bytes, anderer Wert22 Min.
- Lektion 18Poll-Intervall und Buslast selbst berechnen18 Min.
- Lektion 19Modbus Sicherheit: das Protokoll hilft nicht16 Min.
- Lektion 20Modbus integrieren: SPS, Home Assistant, Cloud20 Min.
- Lektion 21Modbus Inbetriebnahme: Checkliste und Spickzettel18 Min.
Poll-Intervall und Buslast selbst berechnen
Ihr Modbus Polling Intervall folgt aus einer Rechnung, nicht aus dem Gefühl. Berechnen Sie die Zykluszeit, nutzen Sie Blocklesen, halbieren Sie die Last.
Was diese Lektion behandelt
- Wie lange eine einzelne Transaktion bei Ihrer Baudrate dauert
- Die Zykluszeit des ganzen Busses, und die Faustregel von 50 Prozent
- Blocklesen, fast sechsmal schneller, und was ein totes Gerät kostet
Vorher lesen: Baudrate und Parität: warum 8E1 Standard ist, Mehrere Modbus Geräte an einem RS485-Bus
Ihr Poll-Intervall ergibt sich aus einer Rechnung, die Sie in fünf Minuten machen: Zykluszeit ausrechnen, verdoppeln, fertig. Dafür brauchen Sie nur die Baudrate, die Rahmenlänge und die Anzahl der Geräte am Bus. Nach dieser Lektion berechnen Sie die Zykluszeit Ihrer eigenen Anlage, leiten daraus ein Intervall ab und wissen, warum ein einziges ausgefallenes Gerät die ganze Runde ausbremst.
Wie lange dauert ein einzelner Lesevorgang?
Länger, als die Nutzdaten vermuten lassen. Bei 9600 Baud kostet das Auslesen von zehn Registern rund 46 ms reine Buszeit, obwohl davon nur 20 Byte tatsächlich Messwerte sind. Sehen wir uns eine echte Transaktion an. Die Anfrage 01 03 00 00 00 0A C5 CD bedeutet: lies zehn Holding-Register ab PDU-Adresse 0 beim Server mit der Serveradresse 1.
| Feld | Bytes | Anzahl |
|---|---|---|
| Serveradresse | 01 | 1 |
| Funktionscode FC03 | 03 | 1 |
| Startadresse (PDU-Adresse 0) | 00 00 | 2 |
| Anzahl Register (10) | 00 0A | 2 |
| CRC-16 | C5 CD | 2 |
| Anfrage gesamt | 8 |
Die Antwort auf genau diese Anfrage lautet 01 03 14 00 0A 00 0B 00 0C 00 0D 00 0E 00 0F 00 10 00 11 00 12 00 13 29 D6:
| Feld | Bytes | Anzahl |
|---|---|---|
| Serveradresse | 01 | 1 |
| Funktionscode FC03 | 03 | 1 |
Byte count (0x14 = 20) | 14 | 1 |
| Daten, 10 Register zu je 2 Byte | 00 0A bis 00 13 | 20 |
| CRC-16 | 29 D6 | 2 |
| Antwort gesamt | 25 |
Erst jetzt die Regel. Ein RTU-Zeichen ist immer 11 Bit lang, auch ohne Parität. Zwischen zwei Rahmen liegt die Pause t3,5, also 3,5 Zeichenzeiten, und die brauchen Sie zweimal.
Zeichenzeit = 11 / Baudrate
Transaktion = (Bytes Anfrage + Bytes Antwort + 7) x Zeichenzeit + Verarbeitungszeit
Bei 9600 Baud ist eine Zeichenzeit 1,1458 ms. Für unser Beispiel: 8 + 25 + 7 = 40 Zeichenzeiten oder 45,83 ms reine Buszeit, plus angenommene 20 ms Verarbeitungszeit im Gerät, macht 65,83 ms. Woher die 11 Bit und die Pausen kommen, steht in der Lektion zu Baudrate, Parität und Timing.
Warum Blocklesen so viel bringt
Weil der Aufwand pro Transaktion fest ist und die Nutzdaten nicht. Ändern Sie am Beispiel oben genau eine Größe, nämlich die Anzahl der Register, und lesen Sie statt zehn nur zwei: die Antwort schrumpft von 25 auf 9 Byte, die Transaktion von 40 auf 24 Zeichenzeiten, also von 45,83 ms auf 27,5 ms. Ein Fünftel der Daten kostet immer noch 60 Prozent der Zeit.
Der feste Anteil ist immer derselbe: 8 Byte Anfrage, 5 Byte Antwortgerüst und 7 Zeichenzeiten Pause, zusammen 20 Zeichenzeiten. Jedes zusätzliche Register kostet danach nur noch 2 Byte.
| Lesevorgang | Zeichenzeiten | Davon Aufwand |
|---|---|---|
| Ein Lesevorgang über 2 Register | 20 fest + 4 Daten = 24 | 83 Prozent |
| Ein Lesevorgang über 10 Register | 20 fest + 20 Daten = 40 | 50 Prozent |
| Ein Blocklesen über 24 Register | 20 fest + 48 Daten = 68 | 29 Prozent |
Der Aufwand je Messwert sinkt damit um fast eine Größenordnung. Welche Zähler wie viele Werte in einem Block liefern, steht im Vergleich von Modbus-Energiezählern für Installateure.
Die Zykluszeit Ihrer gesamten Anlage
Die Zykluszeit ist die Summe aller Transaktionen einer Pollrunde, und sie fällt je nach Zuschnitt der Blöcke völlig unterschiedlich aus. Nehmen Sie zehn Energiezähler an einem RS485-Bus mit 9600 Baud, pro Zähler zwölf Messwerte als float32, also 24 Register.
| Szenario | Pro Zähler | Zehn Zähler |
|---|---|---|
| Ein Blocklesen über 24 Register, 9600 Baud | 97,92 ms | 979,2 ms |
| Zwölf Lesevorgänge über je 2 Register, 9600 Baud | 570 ms | 5.700 ms |
| Ein Blocklesen über 24 Register, 19200 Baud | 58,96 ms | 589,6 ms |
Dieselben Daten, derselbe Bus, nur anders gefragt: Faktor 5,8. Die doppelte Baudrate halbiert die Zeit übrigens nicht ganz, weil die Verarbeitungszeit im Gerät nicht mitskaliert. Bei langen Blöcken hilft mehr Tempo also viel, bei vielen kurzen Lesevorgängen ist das Gerät der Engpass. Wie viele Geräte überhaupt an ein Segment gehören, behandelt die Lektion zu mehreren Geräten an einem Bus.
Von der Zykluszeit zum Poll-Intervall
Buslast ist Zykluszeit geteilt durch Poll-Intervall, mehr steckt nicht dahinter.
Buslast = Zykluszeit / Poll-Intervall
Mit den 0,98 s aus dem Szenario oben sieht das so aus:
| Poll-Intervall | Buslast | Urteil |
|---|---|---|
| 1 Sekunde | 97,9 Prozent | unbrauchbar, jede Störung reißt eine Lücke |
| 2 Sekunden | 49,0 Prozent | knapp, aber machbar |
| 5 Sekunden | 19,6 Prozent | komfortabel |
| 10 Sekunden | 9,8 Prozent | reichlich, für Energiemonitoring mehr als genug |
| 60 Sekunden | 1,6 Prozent | üblich für Wärmepumpen und Gebäudeleittechnik |
Die Faustregel dieses Kurses lautet: bleiben Sie unter 50 Prozent, wählen Sie das Intervall also mindestens doppelt so lang wie die gemessene Zykluszeit. Das ist eine Empfehlung dieses Kurses und keine Vorgabe der Spezifikation. Sie schafft Platz für einen Wiederholungsversuch, für ein Gerät, das einmal langsam antwortet, und für eine zweite Funktion auf demselben Bus.
Ob Sie dieses Intervall frei wählen können, hängt vom Client ab. In ModbusCloud Diagnostics stellen Sie es zwischen 500 ms und 10 s ein und sehen, was ein kürzeres Intervall mit der Buslast macht, bevor Sie es in Ihrem eigenen Client festlegen.
Was der Hersteller zulässt
Meistens weniger als die Spezifikation. FC03 und FC04 erlauben 125 Register pro Anfrage, aber kaum ein Gerät geht so weit.
| Grenze | Wert |
|---|---|
| Modbus-Spezifikation, FC03 und FC04 | 125 Register pro Anfrage |
| Eastron SDM630 | 80 Register (40 Werte), immer eine gerade Anzahl |
| Daikin DCOM-LT/MB | 64 Register für FC03, FC04 und FC16 |
| NIBE S-Serie | 20 Register pro Abfrage, insgesamt 100 Register pro Sekunde |
| SMA | 5 Werte gleichzeitig, mindestens 10 Sekunden zwischen Transfers |
Nehmen Sie pro Gerät die kleinste dieser Grenzen und schneiden Sie Ihre Blöcke darauf zu. Übertreiben Sie es dabei nicht nach oben: ein maximales Blocklesen über 80 Register beim SDM630 dauert bei 9600 Baud allein 206,25 ms, bei zehn Zählern also über zwei Sekunden je Runde. Und die Grenze, die Sie lesen dürfen, ist nicht dasselbe wie die Anzahl der Register, die es gibt. Ein Block über eine Lücke in der Registertabelle kann Exception 02 liefern.
Was ein totes Gerät mit Ihrem Zyklus macht
Es kostet Sie pro Runde den vollen Timeout, oft mehr Zeit als alle funktionierenden Geräte zusammen. Fällt in unserem Szenario Zähler 7 aus, dann rechnet die Runde so: neun arbeitende Zähler zu je 97,92 ms sind 881,25 ms, dazu ein Timeout von 1000 ms, macht 1.881 ms. Aus 0,98 s wird 1,88 s durch ein einziges Gerät. Wiederholt Ihr Client die Anfrage dreimal, bevor er aufgibt, sind es 881 + 3000 = 3.881 ms, also fast das Vierfache. Das ist die übliche Erklärung für die Klage, seit letzter Woche sei alles langsam.
Die Spezifikation nennt für 9600 bps einen typischen Response-Timeout von 1 s bis zu einigen Sekunden. Setzen Sie ihn nicht höher als nötig: messen Sie die Antwortzeit Ihres langsamsten Geräts und rechnen Sie das Dreifache als Marge. Lassen Sie den Client ein stummes Gerät zeitweise überspringen und alarmieren Sie getrennt auf Gerät antwortet nicht und Wert außerhalb der Grenzen. Wie sich das dauerhaft überwachen lässt, zeigt der Überblick zum Modbus-Monitoring über die Cloud.
Bei TCP rechnet man anders
Auf Modbus TCP gibt es keine Buslast im seriellen Sinn. Der MBAP-Header kostet 7 Byte statt 1 Byte Adresse plus 2 Byte CRC, die maximale ADU wächst von 256 auf 260 Byte, und die vorgeschriebene Pause zwischen zwei Rahmen entfällt vollständig. Die Spezifikation erlaubt sogar, mehrere Anfragen an denselben Server zu senden, ohne auf die Bestätigung zu warten, in der Größenordnung von 1 bis 16 gleichzeitig.
Die Bremse sitzt damit nicht mehr in der Leitung, sondern im Gerät. SolarEdge nimmt genau eine gleichzeitige Modbus-TCP-Verbindung an und schließt sie nach 2 Minuten ohne Verkehr, die NIBE S-Serie bleibt bei 100 Registern pro Sekunde, und SMA will weiterhin 10 Sekunden zwischen zwei Datentransfers. Sitzt zwischen Client und Anlage eine Mobilfunkstrecke, lohnt vorher ein Blick in den Überblick zu 4G-Modbus-Gateways.
Eine Ausnahme, die viele übersehen: hinter einem RTU-over-TCP-Gateway gilt die serielle Rechnung unverändert weiter, denn dahinter hängt immer noch ein Bus mit 9600 Baud. Das Netzwerk trägt Ihre Anfrage in Millisekunden bis zum Gateway, danach warten Sie genauso lange wie vorher. Rechnen Sie also mit der Zykluszeit des seriellen Segments, nicht mit der Latenz Ihres Netzwerks. Das gilt auch dann, wenn die Strecke zum Gateway über Mobilfunk läuft.
Häufige Fehler
Jedes Register einzeln auslesen. Der Aufwand pro Transaktion ist fest und groß. Bei zwei Registern sind 83 Prozent Ihrer Buszeit Aufwand, bei 24 Registern nur noch 29 Prozent. Fassen Sie zusammen, was in der Registertabelle ohnehin nebeneinander liegt.
So schnell wie möglich abfragen, sicherheitshalber. Bei 97,9 Prozent Buslast erzeugt jede kleine Störung eine Lücke in Ihren Daten, und für einen Wiederholungsversuch bleibt kein Platz. Ein Intervall von 5 Sekunden bringt dieselbe Anlage auf 19,6 Prozent, ohne dass Sie eine Messung verlieren.
Die Grenze des Herstellers ignorieren. SMA verlangt mindestens 10 Sekunden zwischen zwei Datentransfers. Schneller abzufragen liefert keine besseren Werte, sondern nur unbeständige.
Ein ausgefallenes Gerät im Zyklus stehen lassen. Mit drei Wiederholungen und einem Timeout von einer Sekunde frisst ein totes Gerät mehr Zeit als der ganze Rest der Anlage zusammen.
Selbst ausprobieren
Ziel: Sie rechnen Ihre eigene Anlage durch und passen das Poll-Intervall an das Ergebnis an. Für den letzten Schritt brauchen Sie mbpoll, das unter der GPLv3 steht und frei nutzbar ist, auch geschäftlich.
- 1
Register und Lesevorgänge zählen
Notieren Sie pro Gerät, wie viele Register Sie wirklich brauchen und wie viele einzelne Leseaufträge Ihr Client heute dafür absetzt.
- 2
Transaktionszeit ausrechnen
20 Zeichenzeiten fester Aufwand plus 2 Zeichenzeiten je Register, das Ganze mal die Zeichenzeit Ihrer Baudrate. Bei 9600 Baud sind das 1,1458 ms.
- 3
Zur Zykluszeit aufsummieren
Addieren Sie die Transaktionen aller Geräte und rechnen Sie eine Verarbeitungszeit je Gerät dazu. Schreiben Sie in Ihre Notiz, dass dieser Wert eine Annahme ist.
- 4
Buslast bestimmen
Zykluszeit geteilt durch Ihr aktuelles Poll-Intervall. Liegen Sie über 50 Prozent, gibt es etwas zu tun.
- 5
Blöcke zusammenlegen und neu rechnen
Fassen Sie einzelne Lesevorgänge zu Blöcken zusammen, soweit die Grenze des Herstellers das zulässt, und rechnen Sie noch einmal. Notieren Sie den Gewinn.
- 6
In der Praxis nachmessen
Lassen Sie mbpoll ohne
-1eine Minute lang weiter abfragen und teilen Sie diese Minute durch die Anzahl der Pollzyklen.
mbpoll -m rtu -a 1 -b 9600 -P none -t 4 -r 1 -c 24 /dev/ttyUSB0
Ohne Hardware. Rechnen Sie das Szenario mit den zehn Zählern nach: 24 Register je Zähler, 9600 Baud. Sie müssen auf etwa 0,98 s kommen und bei 19200 Baud auf etwa 0,59 s. Weicht Ihr Ergebnis ab, prüfen Sie zuerst, ob Sie die 7 Zeichenzeiten für die beiden Pausen mitgerechnet haben.
Erwartetes Ergebnis: eine ausgerechnete Zykluszeit, ein begründetes Poll-Intervall und mindestens eine Stelle, an der aus einzelnen Lesevorgängen ein Blocklesen geworden ist.
Zusammenfassung
- Eine Transaktion mit FC03 kostet 20 Zeichenzeiten festen Aufwand plus 2 Zeichenzeiten je Register, und eine Zeichenzeit ist 11 geteilt durch die Baudrate.
- Zehn Zähler mit je einem Blocklesen über 24 Register brauchen bei 9600 Baud etwa 0,98 s pro Runde, dieselben Daten in zwölf Einzelvorgängen etwa 5,7 s.
- Buslast ist Zykluszeit geteilt durch Poll-Intervall, und als Faustregel dieses Kurses bleiben Sie unter 50 Prozent, damit Wiederholungen noch hineinpassen.
- Herstellergrenzen liegen unter der Spezifikation: 80 Register beim SDM630, 64 beim Daikin DCOM-LT/MB und 20 pro Abfrage bei der NIBE S-Serie.
- Ein ausgefallenes Gerät verlängert eine Runde von 0,98 s auf 1,88 s, mit drei Wiederholungen auf 3,88 s.
Überprüfen Sie sich selbst
Vier Fragen zu dieser Lektion. Zu jeder Antwort gibt es eine Erläuterung.
Frage 1 von 4
Selbst sehen, wie es funktioniert?
Das ModbusCloud Gateway liest die Geräte aus diesem Kurs aus, ohne dass Sie ein einziges Register programmieren.