Nous poursuivons le sujet de la programmation du protocole Modbus TCP sur les automates Simatic S7-1500. La dernière fois que nous avons parlé du côté serveur, nous décrirons aujourd'hui le côté client. Un client Modbus TCP est un nœud qui génère des requêtes vers le serveur, c'est-à-dire demande des données et transmet les consignes / commandes. Dans la terminologie Modbus RTU, il s'agit d'un "maître", un appareil maître. Contrairement à RTU, TCP peut avoir plusieurs "maîtres" (correctement - clients).
La programmation côté client est plus difficile. Alors qu'un appel de bloc fonction et un bloc de données suffisent pour le serveur, les choses ne sont pas si simples avec le client. Premièrement, un client peut communiquer avec plusieurs serveurs, ce qui se passe réellement dans la pratique. Deuxièmement, il peut (et fait) plus d'une requête à un serveur - lire des registres d'entrée, lire des registres de stockage, écrire des commandes pour sortir des "bobines", et tout cela avec un "dispositif d'abonné". Troisièmement, n'oubliez pas l'ordre des octets "pointu" et "émoussé" dans les mots des différentes plates-formes matérielles, s'il y a une discordance, les octets doivent être retournés indépendamment.
Pour cette raison, il est judicieux de programmer le client en SCL (ST dans la terminologie CEI 61131-3) et d'envelopper tous les traitements dans un bloc fonctionnel. Pour être plus réaliste, dans cet exemple, le contrôleur communiquera avec deux serveurs Modbus TCP avec plusieurs requêtes à chacun.
Tout d'abord, créons un bloc fonction ModbusClient en langage SCL et ajoutons un appel à son instance dans l'OB1.
De plus, dans la zone STAT des variables du bloc fonction, il est nécessaire d'enregistrer deux structures TCON_IP_v4. Pourquoi deux? Parce que nous avons deux connexions à deux serveurs différents. En fait, nous avons deux connexions différentes et chacune doit être décrite. Comme je l'ai dit précédemment, il est possible d'utiliser des connexions configurables, mais elles ne sont pas utilisées dans cet exemple.
Deux structures sont déclarées pour communiquer avec deux serveurs
. , . .
, 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) / .
Avec le deuxième serveur, nous avons une connexion séparée configurée, il y a une instance distincte du bloc fonctionnel Modbus. Nous pouvons l'appeler "simultanément" avec les communications du premier serveur, de sorte que le programme général a deux instructions CASE qui fonctionnent indépendamment l'une de l'autre.
En principe, il serait logique d'ajouter une analyse de la réponse à une demande spécifique et la formation d'un signe de fiabilité des données, et d'apporter d'autres améliorations. Par exemple - l'envoi de commandes et de paramètres n'est pas obligatoire, mais uniquement par modification.
Néanmoins, c'est là que je termine la description du travail avec le protocole Modbus TCP. La prochaine fois, examinons la programmation du protocole Modbus RTU.