Modbus/TCP-Treiber

Modbus/TCP basiert auf dem seriellen Modbus Protokoll, das für TCP/IP adaptiert wurde. Der Modbus/TCP Treiber kann gleichzeitig für Modbus/TCP oder UNICOS verwendet werden.

Modbus/TCP wird verwendet, um Datenblöcke auf SPSen zu lesen oder zu schreiben.

UNICOS ist eine von CERN definierte Erweiterung von Modbus/TCP. Eine Kommunikation mit UNICOS ist nur möglich, wenn auch in der SPS entsprechende Programmierungen vorgenommen werden (siehe Grundlagen UNICOS).

Der Informationsaustausch erfolgt über verschiedene Funktionscodes (function codes = FC, siehe Details zum Treiber Modbus/TCP). Diese Funktionscodes sind Teil der Peripherieadresse und müssen vom Benutzer angegeben werden.

Adressierung

Die Peripherieadresse setzt sich zusammen aus:

  • Typ - Modbus/UNICOS
  • Nummer der SPS (Speicherprogrammierbare Steuerung)
  • Funktionscode bzw. Subfunktionscode für UNICOS
  • Referenznummer
  • Subindex

Eine Unit-Adresse ist erforderlich, falls an einem LAN-Gateway mit einer IP-Adresse mehrere SPSen angebunden sind (z.B. für SPS 2 und SPS 3). Wenn eine SPS eine eigene IP-Adresse hat, soll die Unit-Adresse auf 1 gesetzt sein - z.B. für SPS 1 (siehe Parametrierpanel des Modbus/TCP Treibers).

Da eine SPS über verschiedene Verbindungen erreicht werden kann, gibt es auch mehrere TCP/IP Verbindungen für jede SPS. Unterstützt werden maximal zwei Verbindungen zur SPS, d.h. es sind zwei Netzwerkpfade möglich.

Master/Slave und Client/Server

Das Modbus Protokoll baut auf einer Master/Slave-Topologie auf. Ein Master in einer Kommunikation ist jene Einheit, die eine Aktion auslöst (Request). Der Master sendet Anfragen (Requests) und der Slave antwortet (Response) diesen Anfragen. Einem Slave ist es nicht erlaubt Anfragen (Requests) zu senden. Ein Slave kann von sich aus nie aktiv werden.

Bildet man das auf TCP/IP ab, so muss der Master der TCP Client sein, da vom Client die Verbindungsaufnahme ausgeht. Der Slave ist der TCP Server. Er macht einen "Listening Socket” und kann über diesen Socket Verbindungsanfragen und in der Folge Requests beantworten.

Der Treiber kann beide Modi (Master und Slave) gleichzeitig. Den Slave Modus braucht er um spontane Daten empfangen zu können, den Master Modus um Befehle und Abfragen zu schicken (d.h. wenn er Werte zur Peripherie schicken oder abfragen möchte, baut er eine Verbindung zur Peripherie auf). Gleichzeitig öffnet der Treiber auch einen TCP Server-Socket, der es erlaubt, dass sich Peripheriegeräte zum Treiber verbinden und spontan Daten schicken.

Folgende Abbildung zeigt den Datenfluss für einen Modbus/TCP Treiber:

Um Daten an die SPS zu senden, muss die Masterseite des Treibers einen Write Request senden. Die Antwort aus den Write Request ist nur für die Protokollschicht relevant und daher strichliert dargestellt.

Bei Eingangsdaten gibt es zwei Möglichkeiten: Entweder sendet der Master einen Read Request, um die Daten von der SPS abzufragen oder der Slave erhält einen Write Request von der SPS.

Der Slave antwortet auf Read Request mit Dummy-Daten für Simulationszwecke. Die Abfrage von Daten vom Treiber wird nicht unterstützt, da normalerweise keine SPS Daten von WinCC OA abgefragt werden.