Seite 2: Adressierungsschemata

Es ist der Natur ihres Einsatzgebiets geschuldet, dass eine SPS in der Regel nur einfache, das heißt systemnahe Datentypen unterstützt, etwa Bit beziehungsweise Bool (X), Byte (B) oder ein {einfaches, doppeltes, langes} Word (W = Word = 16 Bit, D = Double = 32 Bit, L = Long = 64 Bit). Bisweilen sind beispielsweise auch Felder und andere einfach strukturierte Datentypen anzutreffen.

Um Eingaben (I), Ausgaben (Q) und Speicherzugriffe (M) zu adressieren, gibt es eine eigene Notation aus dem IEC-Standard.

Drei Beispiele zur Veranschaulichung:

• %IX1.7 : vom Eingangsport 2 (Zählungen fangen informatikgerecht bei 0 an, I steht für Input, X für Bit!), das achte (least-significant bzw. am weitesten rechtsstehende) Bit.
• %QX2.3 : vom Ausgangsport 3 (Q steht für Output) das vierte Bit von rechts.
• %MW0 : Das Speicherwort an Adresse 0

Was mit dem ersten und zweiten Beispiel auf der echten Hardware tatsächlich gemeint ist, hängt vom Mapping dieser Adressen auf die physikalische Hardware ab.

Wer sich im Übrigen über das Q für Ausgabeports wundert: Vermutlich hat man im Standard deshalb Q statt O für Ausgabe genutzt, weil sich Q leichter von der Zahl 0 unterscheiden lässt, aber das ist reine Spekulation des Autors.

Auf einem Arduino Mega oder Due beispielsweise würde die Abbildung auf die reale Physik wie folgt aussehen (links die physikalischen Pin-Nummern, rechts die in der PLC genutzten Adressen):

Digital In ​

62, 63, 64, 65, 66, 67, 68, 69 => %IX0.0 bis %IX0.7​

22 , 24, 26, 28, 30, 32, 34, 36 => %IX1.0 bis %IX1.7​

38, 40, 42, 44, 46, 48, 50, 52 => %IX2.0 bis %IX2.7​

Digital Out​

14, 15, 16, 17, 18, 19, 20, 21 => %QX0.0 bis %QX0.7​

23, 25, 27, 29, 31, 33, 35, 37 => %QX1.0 bis %QX1.7​

39, 41, 43, 45, 49, 49, 51, 53 => %QX2.0 bis %QX2.7​

Analog In​

A0, A1, A2, A3, A4, A5, A6, A7 => %IW0 bis %IW7​

Analog Out​

2, 3, 4, 5, 6, 7, 8, 9 => %QW0 bis %QW7​

10, 11, 12, 13 => %QW8 bis %QW11​

Für andere Zielsysteme gibt es eigene Adressabbildungen, die Anwender der OpenPLC-Dokumentation entnehmen können.

Das Modbus-Kommunikationsprotokoll

In Automatisierungslösungen kommunizieren alle möglichen Geräte miteinander, etwa die SPS mit einer anderen SPS oder die SPS mit einem Motor, einer Pumpe, einem Ventil oder einem Sensor, oder aber ein SCADA-Server (siehe weiter unten) mit einer SPS. Hierfür existieren eine ganze Reihe von Kommunikationsprotokollen wie Profibus, BacNet, Modbus und Profinet. OpenPLC integriert das einfache und offene Modbus-Protokoll, das es seit den Siebzigerjahren in verschiedenen Geschmacksrichtungen gibt: über serielle Ports mit Binärdaten (RTU) oder ASCII-Daten (ASCII), und als Protokoll oberhalb TCP/IP. Letzteres ist heutzutage in Mode, weil dadurch parallel auch andere Protokolle wie HTTP koexistieren können. OpenPLC unterstützt übrigens Modbus RTU sowie Modbus TCP.

Modbus obliegt einer Master-Slave-Architektur – was inzwischen freilich kein politisch korrekter Begriff mehr sein dürfte. Trotzdem übernimmt der Autor die bestehende Nomenklatur. Jedenfalls initiiert der Master eine Kommunikation mit einem einzelnen Slave oder per Broadcast mit mehreren Slaves – bis zu 247 Slaves lassen sich anschließen – und bittet um Ausführung einer Funktion. Ein angesprochener Slave empfängt die Nachricht (den Request), führt die angeforderte Funktion aus oder meldet im Fehlerfall eine Exception beziehungsweise versendet im Normalfall eventuelle Rückgaben (die Response) an den Master.

Die nutzbaren Nachrichtentypen und ihr genauer Aufbau sind bei Modbus fest vorgegeben: etwa "Lesen des analogen Inputs von Port %IW0". Alle verwendeten Adressierungsschemata entsprechen dabei den weiter oben erläuterten.

Während die OpenPLC-Laufzeitumgebungen auf Desktop-Betriebssystemen auch als Modbus-Master fungieren können, arbeiten Mikrocontroller-basierte Systeme in OpenPLC ausschließlich als Slaves. Auf den von OpenPLC unterstützten Embedded-Boards lassen sich Modbus-Nachrichten auch über USB oder serielle Eingänge empfangen und versenden. Demzufolge kommt hier Modbus RTU zum Einsatz.

Der voreingestelle Standard-Port für Modbus TCP lautet 502, was sich aber in den Einstellungen ändern lässt, sollten Konflikte auftreten.

Adressierungsschemata für angeschlossene PLCs innerhalb OpenPLC sind auf der Projekt-Website verfügbar.

Zu beachten ist dabei, dass Modbus zwar dasselbe Adressierungsschema benutzt, sich aber in der Terminologie für Datentypen unterscheidet. So gelten folgende Zuordnungen:

PLC Datentyp................Modbus Datentyp​

Digital Input...............InputStatus​

Digital Output..............Coil​

Analog Input................Input Register​

Analog Output...............Holding Register​

Speicher....................Holding Register​

Jede über Modbus übertragene Nachricht besteht aus vier hintereinander folgenden Bestandteilen:

| MBAP Header | Slave ID | Function Code | Data |​

• Der optionale MBAP-Header enthält für das Transportprotokoll (TCP) bestimmte Information. Bei RTU/ASCII fehlt er indes.
• Die Slave ID besteht aus einem Byte, das eindeutig den gewünschten Modbus-Slave spezifiziert. Modbus TCP ignoriert manchmal diese ID, wenn das Endgerät sich eindeutig über dessen IP-Adresse identifizieren lässt.
• Function Code definiert, welche Aktion die Modbus-Instanz ausführen soll, also meistens Lesen oder Schreiben. Beispiele sind FC 01 (Read Coils), FC 16 (Read Multiple Registers) oder FC 05 (Force Coil).
• Data dient, wenig überraschend, zur Spezifikation der Daten für die aufzurufende Funktion. Bei Antworten des Geräts stehen dort die Daten, die das Gerät gelesen oder geschrieben hat.

Kleine Tipps am Rande:

• Ein eigenes Testwerkzeug, um einen Modbus-Master zu simulieren, ist der kostenlose Radzio! Modbus Master Simulator (RMMS) für Windows (Download hier). Der Simulator unterstützt wie OpenPLC auch Modbus TCP und Modbus RTU. Mithilfe von RMMS können Anwender den Status der Ports eines angeschlossenen Mikrocontrollerboards abfragen. Dadurch behält er den Überblick über die aktuellen Zustände angeschlossener Modbus-Slaves wie etwa eines Arduino mit aktiver OpenPLC-Runtime.
• Es gibt darüber hinaus Open-Source-Software, um auf Basis oder anstelle von Modbus MQTT-Messaging zu implementieren (siehe GitHub).
• Wer will, kann auch Python zusammen mit dem PyModbus-Paket nutzen, um von einer beliebigen Plattform aus mit OpenPLC-Instanzen zu kommunizieren. Nähere Information dazu gibt es in der PyModbus Dokumentation.