TABLE OF CONTENTS
TCP/IP based
MQTT
Modbus TCP
The biggest pitfall that we currently encounter is the incorrect implementation of the Modbus protocol by some manufacturers.
Modbus TCP describes the following model:
This means ibaPDA sends a request for data to the Modbus server, and the Modbus server answers with the data.
Wireshark example: Request packet from ibaPDA to the server:
Wireshark example: Server response with the data sent back to ibaPDA system.
From the upper part of the Wireshark tool, you can see that only those packets are being transferred back-n-forward.
This is following the design/implementation guidelines of Modbus Organisation. (see attachment, chapter 4.3 USE of TCP/IP STACK, page 14 and following)
However, some companies/integrators would expect an 'ACK' back from ibaPDA to the Modbus Server to confirm the good reception of the data (ACK on the Response packet)
If the Modbus Server does not receive the 'ACK' on the Response this may cause:
To be clear, ibaPDA does not send an 'ACK' back to the Modbus Server.
If the Modbus Server does not receive the 'ACK' on the Response this may cause:- normal operation
- re-transmissions
- timeouts
- communication errors
- ...
This depends on the implementation of the creator.
When the 'ACK' is needed on the Modbus Server side, you can enable the following option in ibaPDA (This requires ibaPDA v6.39.0 or later):
Checking data comm. port
When a customer can ping the PLC but cannot make a connection, e.g. received error 0xFFF5004 S7-XPlorer, it's possible there is a network connection but the required port is not open.
To test if TCP port 9170 (PDA client) is open for IP-address 192.168.140.163 (example):
- Open Microsoft Powershell (preferably admin rights)
- Type in "Test-NetConnection 192.168.140.163 -Port 9170
- Hit Enter
- The testing might take +- 20 seconds, it is slower than a default ping.
Example test succeeded:
Example test failed:
TABLE OF CONTENTS
Si el Servidor Modbus no recibe el 'ACK' en la Respuesta esto puede causar:
