Continuamos con el tema de la programación del protocolo Modbus TCP en controladores Simatic S7-1500. La última vez que hablamos del lado del servidor, hoy describiremos el lado del cliente. Un cliente Modbus TCP es un nodo que genera solicitudes al servidor, es decir solicita datos y transmite consignas / comandos. En la terminología de Modbus RTU, este es un "maestro", un dispositivo maestro. A diferencia de RTU, TCP puede tener varios "maestros" (correctamente, clientes).
La programación del lado del cliente es más difícil. Si bien una llamada a un bloque de funciones y un bloque de datos son suficientes para el servidor, las cosas no son tan simples con el cliente. Primero, un cliente puede comunicarse con varios servidores, que es lo que realmente sucede en la práctica. En segundo lugar, puede (y lo hace) más de una solicitud a un servidor: leer registros de entrada, leer registros de almacenamiento, escribir comandos en "bobinas" de salida, y todo esto con un "dispositivo de abonado". En tercer lugar, no se olvide del orden de bytes "puntiagudos" y "contundentes" en palabras de diferentes plataformas de hardware; si hay una discrepancia, los bytes deben invertirse de forma independiente.
Por esta razón, tiene sentido programar el cliente en SCL (ST en terminología IEC 61131-3) y envolver todo el procesamiento en un bloque de funciones. Para ser más realista, en este ejemplo, el controlador se comunicará con dos servidores Modbus TCP con múltiples solicitudes a cada uno.
En primer lugar, creemos un bloque de funciones ModbusClient en lenguaje SCL y agreguemos una llamada a su instancia en OB1.
Además, en el área STAT de las variables del bloque de funciones, es necesario registrar dos estructuras TCON_IP_v4. ¿Por qué dos? Porque tenemos dos conexiones a dos servidores diferentes. De hecho, tenemos dos conexiones diferentes y cada una debe describirse. Como dije anteriormente, es posible usar conexiones configurables, pero no se usan en este ejemplo.
Se declaran dos estructuras para comunicarse con dos servidores
. , . .
, 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) / .
Con el segundo servidor tenemos configurada una conexión separada, hay una instancia separada del bloque funcional modbus. Podemos llamarlo "simultáneamente" con las comunicaciones del primer servidor, por lo que hay dos declaraciones CASE en el programa común que funcionan de forma independiente entre sí.
En principio, sería lógico agregar un análisis de la respuesta a una solicitud específica y la formación de un signo de confiabilidad de los datos, y realizar algunas otras mejoras. Por ejemplo, enviar comandos y configuraciones no es obligatorio, solo por cambio.
Sin embargo, aquí es donde termino la descripción del trabajo con el protocolo Modbus TCP. La próxima vez, veamos la programación del protocolo Modbus RTU.