Continuamos com o tópico de programação do protocolo Modbus TCP nos controladores Simatic S7-1500. Da última vez que falamos sobre o lado do servidor, hoje iremos descrever o lado do cliente. Um cliente Modbus TCP é um nó que gera solicitações para o servidor, ou seja, solicita dados e transmite pontos de ajuste / comandos. Na terminologia do Modbus RTU, este é um "mestre", um dispositivo mestre. Ao contrário da RTU, o TCP pode ter vários "mestres" (corretamente - clientes).
A programação do lado do cliente é mais difícil. Embora uma chamada de bloco de função e um bloco de dados sejam suficientes para o servidor, as coisas não são tão simples com o cliente. Primeiro, um cliente pode se comunicar com vários servidores, que é o que acontece na prática. Em segundo lugar, pode haver (e acontece) mais de uma solicitação para um servidor - para ler registros de entrada, ler registros de armazenamento, escrever comandos para "bobinas" de saída e tudo isso com um "dispositivo de assinante". Em terceiro lugar, não se esqueça da ordem de bytes "apontados" e "contundentes" em palavras de diferentes plataformas de hardware; se houver uma incompatibilidade, os bytes devem ser invertidos independentemente.
Por este motivo, faz sentido programar o cliente em SCL (ST na terminologia IEC 61131-3) e agrupar todo o processamento em um bloco de função. Para ser mais realista, neste exemplo, o controlador se comunicará com dois servidores Modbus TCP com várias solicitações para cada um.
Em primeiro lugar, vamos criar um bloco de funções ModbusClient em linguagem SCL e adicionar uma chamada à sua instância em OB1.
Além disso, na área STAT das variáveis do bloco funcional, é necessário registrar duas estruturas TCON_IP_v4. Por que dois? Porque temos duas conexões para dois servidores diferentes. Na verdade, temos duas conexões diferentes e cada uma precisa ser descrita. Como eu disse antes, é possível usar conexões configuráveis, mas elas não são usadas neste exemplo.
Duas estruturas são declaradas para se comunicar com dois 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) / .
Com o segundo servidor, temos uma conexão separada configurada, há uma instância separada do bloco funcional modbus. Podemos chamá-lo de "simultaneamente" com as comunicações do primeiro servidor, portanto, há duas instruções CASE no programa comum que funcionam independentemente uma da outra.
Em princípio, seria lógico adicionar uma análise da resposta a uma solicitação específica e a formação de um sinal de confiabilidade de dados e fazer algumas outras melhorias. Por exemplo, não é obrigatório enviar comandos e configurações, mas apenas por alteração.
No entanto, termino aqui a descrição de como trabalhar com o protocolo Modbus TCP. Da próxima vez, vamos dar uma olhada na programação do protocolo Modbus RTU.