Modbus TCP

Was ist das

Ein Modbus-Ziel ist ein benannter Datenpunkt an einer Maschinensteuerung über das Modbus-TCP-Protokoll, ein Coil oder ein Register mit fester Adresse. Einmal angelegt, brauchen Sie für den Zugriff darauf nur noch den Namen des Ziels.

Zwei Kommandos greifen darauf zu. modbus.read liest einen Wert ab, ohne die Steuerung zu verändern. modbus.write schreibt einen Wert; weil sich eine Steuerung softwareseitig nicht zurückdrehen lässt, gilt dieser Schritt als unumkehrbar. Daneben kann ein telemetry-Eintrag einer Ansicht denselben Datenpunkt laufend anzeigen, unabhängig von jeder Aktion.

Angelegt wird ein Modbus-Ziel in der Verwaltung unter „Modbus-Ziele", von Hand oder mit Unterstützung des Assistenten. Modbus TCP steht damit gleichrangig neben OPC UA; was zu einer bestimmten Maschine passt, richtet sich nach deren vorhandener Anbindung.

Wann einsetzen

Retrofit an älteren Steuerungen ohne OPC UA. Viele Bestandsmaschinen sprechen kein OPC UA. Ein aufgestecktes IO-Modul mit Modbus-TCP-Schnittstelle liefert trotzdem einzelne Werte, meist ohne Eingriff in die eigentliche Steuerung.
Impulszähler und IO-Module am Engpass. Ein Zählerbaustein an der Presse oder am Förderband liefert Stückzahlen als Modbus-Register, ohne dass die Steuerung selbst etwas davon mitbekommt.
Zählerabgleich im Cockpit. Wie bei OPC UA vergleicht der Zählerabgleich gebuchte Stückzahlen mit einem counter-Ziel, hier über Modbus statt über OPC UA. Das Kapitel Kennzahlen & Cockpit erklärt diesen Abgleich im Detail.

Wie weit eine Maschine angebunden ist, verbessert sich meist in Stufen: ohne Anbindung → Modbus-Retrofit → Gateway → natives OPC UA. Ohne Anbindung liefert eine Maschine nur Buchungen vom Terminal. Ein Modbus-Retrofit ergänzt einzelne Werte über ein nachgerüstetes IO-Modul, oft noch am selben Tag. Ein Gateway übersetzt diese Modbus-Werte anschließend in einen OPC-UA-Server, sobald mehrere Maschinen gebündelt an eine übergeordnete Leitebene sollen. Eine neue oder modernisierte Steuerung bringt einen eigenen OPC-UA-Server gleich mit und macht das Gateway überflüssig. Jede Stufe trägt für sich; WERKSPUR bindet Modbus-Ziele und OPC-UA-Ziele gleichberechtigt nebeneinander an, eine Maschine muss auf keine der folgenden Stufen warten.

Anatomie der Definition

Eine Modbus-Ziel-Definition ist ein flaches JSON-Objekt:

name: der Bezeichner des Ziels, ^[a-z][a-z0-9-]{0,63}$. Sowohl Kommando-Schritte als auch der telemetry-Eintrag einer Ansicht sprechen das Ziel nur über diesen Namen an.
endpoint: die Adresse der Steuerung oder des IO-Moduls, host oder host:port, ohne Schema. Fehlt der Port, ergänzt WERKSPUR beim Verbindungsaufbau automatisch den Modbus-Standardport 502.
unit_id: die Modbus-Unit-ID (Slave-Adresse) der Steuerung hinter dem Endpunkt, 1 bis 247. Ohne Angabe gilt 1.
register: der Datenpunkt selbst, mit type (coil, discrete, input oder holding) und address, der numerischen Registeradresse laut Steuerungsdokumentation.
data_type: der Datentyp des Werts. coil und discrete verlangen bool; input und holding verlangen einen numerischen Typ, int16, uint16, int32, uint32 oder float32.
word_order: nur bei den 32-Bit-Typen int32, uint32 und float32 Pflichtfeld, big oder little. Bei allen anderen Typen bleibt das Feld leer.
mode: legt die erlaubte Richtung fest, read, write oder read-write. modbus.read braucht read oder read-write, modbus.write braucht write oder read-write. Schreiben ist zusätzlich auf coil und holding beschränkt; discrete und input sind laut Modbus-Protokoll grundsätzlich nur lesbar.
poll_ms: das Abfrageintervall der Telemetrie in Millisekunden, 250 bis 60000. Ohne Angabe gilt 1000.

Ein Modbus-Ziel kennt, anders als ein OPC-UA-Ziel, keinen security-Block. Modbus TCP bringt selbst keine Verschlüsselung und keine Anmeldung mit; jedes Ziel läuft im Klartext gegen den offenen Port der Steuerung. Das eignet sich, genau wie ein OPC-UA-Ziel ohne security-Block, ausschließlich für abgeschottete Maschinennetze ohne Zugriff von außen.

Das Demoprofil bindet ein Ziel per Modbus an die Presse: presse-1-temperatur-mb, ein input-Register vom Typ float32 im Modus read. Die Zuordnung Maschine→Ziel, mit kind und protocol, stammt heute aus dem Seed-Profil des Systems; das telemetry-Widget der Ansicht bindet nur die Maschine. Für diesen Wert trägt die Zuordnung protocol: modbus und macht damit sichtbar, dass er über Modbus statt über OPC UA kommt; alle übrigen Werte derselben Maschine laufen weiter über ihre bestehenden OPC-UA-Ziele.

Beispiele

{
  "name": "presse-2-stueckzaehler-mb",
  "endpoint": "192.168.10.40:502",
  "unit_id": 1,
  "register": {
    "type": "input",
    "address": 100
  },
  "data_type": "uint32",
  "word_order": "big",
  "mode": "read",
  "poll_ms": 1000
}

Mit dem Assistenten

Lese-Ziel für einen Modbus-Stückzähler anlegen, 32 Bit, große Byte-Reihenfolge.

Ein input-Register vom Typ uint32 braucht zwingend eine word_order, hier big. Der Endpunkt nennt den Port ausdrücklich; ohne diese Angabe würde WERKSPUR ohnehin den Standardport 502 verwenden. mode: read erlaubt modbus.read und das telemetry-Widget, modbus.write dagegen nicht.

{
  "name": "presse-2-freigabe-mb",
  "endpoint": "io-modul.werk.local",
  "unit_id": 1,
  "register": {
    "type": "coil",
    "address": 8
  },
  "data_type": "bool",
  "mode": "read-write",
  "poll_ms": 1000
}

Mit dem Assistenten

Schreibbares Coil-Ziel für eine Freigabe an einem IO-Modul anlegen.

Ein coil trägt immer data_type: bool und braucht keine word_order. mode: read-write erlaubt sowohl modbus.read als auch modbus.write auf dasselbe Ziel, hier ohne Port im Endpunkt, WERKSPUR ergänzt beim Verbindungsaufbau also den Standardport 502.

Fallstricke

Schreiben geht nur auf coil oder holding. mode: write oder read-write scheitert an der Validierung, sobald register.type auf discrete oder input steht. Diese beiden Register-Arten sind laut Modbus-Protokoll grundsätzlich nur lesbar; WERKSPUR erzwingt das schon bei der Definition, nicht erst beim Schreibversuch.
Eine vertauschte word_order liefert eine plausible, aber falsche Zahl. Bei einem 32-Bit-Wert ergibt big statt little meist keinen offensichtlichen Ausreißer, sondern eine Zahl in einer ähnlichen Größenordnung wie der echte Wert. Prüfen Sie einen neu angelegten 32-Bit-Zähler deshalb einmal gegen einen bekannten Referenzwert an der Steuerung selbst, bevor Sie sich auf ihn verlassen.
Höchstens ein counter-Binding je Maschine, über alle Protokolle hinweg. Der Zählerabgleich zählt pro Maschine genau einen Stückzähler. Binden Sie sowohl ein OPC-UA-Ziel als auch ein Modbus-Ziel mit kind: counter an dieselbe Maschine, zählt der Abgleich doppelt und die Abweichung wird unbrauchbar.
Modbus TCP läuft unverschlüsselt und ohne Anmeldung. Jeder mit Netzzugriff auf den Endpunkt liest dieselben Coils und Register und schreibt sie, wo mode es erlaubt. Das gehört ausschließlich in ein abgeschottetes Maschinennetz, nie in ein Netz mit Zugriff von außen.
Eine Änderung an einem Ziel braucht für die Live-Anzeige einen Neustart. Änderungen an Zielen wirken für Aktionen sofort, die laufende Telemetrie liest ihre Zuordnung beim Start; nach dem Ändern eines Ziels braucht die Live-Anzeige einen Neustart des Servers.

Wie ein telemetry-Eintrag einen Datenpunkt in eine Ansicht einbindet, beschreibt das Kapitel Ansichten. Den Zählerabgleich selbst, der ein counter-Ziel gegen gebuchte Stückzahlen hält, erklärt das Kapitel Kennzahlen & Cockpit. Für Maschinen mit eigenem OPC-UA-Server gilt weiterhin das Kapitel OPC UA.