Wir setzen das Thema der Programmierung des Modbus TCP-Protokolls auf Simatic S7-1500-Controllern fort. Als wir das letzte Mal über die Serverseite gesprochen haben, werden wir heute die Clientseite beschreiben. Ein Modbus-TCP-Client ist ein Knoten, der Anforderungen an den Server generiert, d. H. fordert Daten an und überträgt Sollwerte / Befehle. In der Modbus RTU-Terminologie ist dies ein "Master", ein Master-Gerät. Im Gegensatz zu RTU kann TCP mehrere "Master" haben (richtig - Clients).
Die clientseitige Programmierung ist schwieriger. Während ein Funktionsblockaufruf und ein Datenblock für den Server ausreichen, sind die Dinge mit dem Client nicht so einfach. Erstens kann ein Client mit mehreren Servern kommunizieren, was in der Praxis tatsächlich der Fall ist. Zweitens kann (und tut) es mehr als eine Anforderung an einen Server - Eingangsregister lesen, Speicherregister lesen, Befehle zum Ausgeben von "Spulen" schreiben und all dies mit einem "Teilnehmergerät". Drittens sollten Sie die "spitze" und "stumpfe" Bytereihenfolge in Worten verschiedener Hardwareplattformen nicht vergessen. Wenn eine Nichtübereinstimmung vorliegt, müssen die Bytes unabhängig voneinander gespiegelt werden.
Aus diesem Grund ist es sinnvoll, den Client in SCL (ST in IEC 61131-3-Terminologie) zu programmieren und die gesamte Verarbeitung in einen Funktionsblock zu packen. Um realistischer zu sein, kommuniziert der Controller in diesem Beispiel mit zwei Modbus-TCP-Servern mit jeweils mehreren Anforderungen.
Lassen Sie uns zunächst einen ModbusClient-Funktionsblock in SCL-Sprache erstellen und seiner Instanz in OB1 einen Aufruf hinzufügen.
Ferner müssen im STAT-Bereich der Variablen des Funktionsblocks zwei Strukturen TCON_IP_v4 geschrieben werden. Warum zwei? Weil wir zwei Verbindungen zu zwei verschiedenen Servern haben. Tatsächlich haben wir zwei verschiedene Verbindungen und jede muss beschrieben werden. Wie bereits erwähnt, können konfigurierbare Verbindungen verwendet werden, die in diesem Beispiel jedoch nicht verwendet werden.
Zwei Strukturen sind für die Kommunikation mit zwei Servern deklariert
. , . .
, InterfaceId. ( « ») . Modbus №1 , ID .
ID 64. , , .
, ID. . . «» -. « » , 1 4096. «» . . ID = 1 .
, ConnectionType — TCP UDP. 0x0B hex 11 dec. , TCP.
ActiveEstablished. «». .
RemoteAddress. IP- . 192.168.43.100.
RemotePort. , Modbus TCP . «» 502.
LocalPort. .
, .
. , ID IP . .
. MB_CLIENT .
. - .
« »
. — 0 , , -, .
REQ . REQ = TRUE, .
DISCONNECT —
MB_MODE — «» . MB_DATA_ADDR Modbus TCP. . MODE 0.
MB_DATA_ADDR Modbus TCP. 40001 — « »
MB_DATA_LEN — . — . « 40001»
MB_DATA_PTR — , . , SingleHR INT, 2 Modbus. «» .
CONNECT — TCON_IP_V4
Modbus, , … . . . . . — , , … ( « » ). , , .
, (DONE) (ERROR) «» . , . . — .
, «» .
, . 80C6. MB_CLIENT , TCON ( TSEND, TRECEIVE ). : The connection partner cannot be reached (network error). . , - Modbus Windows Firewall. , , . , , . .
, . (REAL) — 4 . 2 . , 2, «» . — REAL ( ).
. , ModbusClient , Modbus, , 80A3. , , (- ). /. ( ), :
/ «» Srv1Req . «» ( , ) «» Srv1Disconnect, ( , .. , ), , . , REQ DISCONNECT , , , .
, «» (little-endian big-endian) . modbus 0.666. Modbus 1.663175E+38, (, , ). , , . . .
SWAP ( — ). , ( Data.Test) . , , «» , «», «». , 4 — .
, . 4 4 , .
Deserialize «» - , — . , Modbus.
, , , Modbus TCP, — () (). Modbus RTU «» . , , , . Unit ID, Device ID, — , , . Modbus TCP « » IP-. , Device ID . , . , «» Modbus TCP ID . Unit ID , Modbus RTU Modbus TCP (, , ). Modbus Unit ID. «» , , . , Modbus MB_Unit_ID. «» , .. Modbus. 0xFF 255. «» , TCP/IP. «», Unit ID . .
, , , , .. .
, . 3 (6 ), 40001, ( 40011). , «». ( «» ) . , , « » , ( Deserialize, ), . «» . Data , REAL.
, Data «» «», , — 818B.
, , «» .
, .
0.5, 0.7, 0.33 () « »
— ( ). , . , — . — , . « » ( « », ).
.
, , Server1Query ( Server2Query). CASE. « » .
, , . , , ( MODBUS_CLIENT) / .
Mit dem zweiten Server haben wir eine separate Verbindung konfiguriert, es gibt eine separate Instanz des Modbus-Funktionsblocks. Wir können es "gleichzeitig" mit der Kommunikation des ersten Servers nennen, daher gibt es im gemeinsamen Programm zwei CASE-Anweisungen, die unabhängig voneinander arbeiten.
Im Prinzip wäre es logisch, eine Analyse der Antwort auf eine bestimmte Anfrage und die Bildung eines Zeichens für Datenzuverlässigkeit hinzuzufügen und einige andere Verbesserungen vorzunehmen. Zum Beispiel ist das Senden von Befehlen und Einstellungen nicht obligatorisch, sondern nur durch Änderung.
Trotzdem beende ich hier die Beschreibung der Arbeit mit dem Modbus TCP-Protokoll. Schauen wir uns das nächste Mal die Programmierung des Modbus RTU-Protokolls an.