Modbus TCP sends the Modbus request (PDU) over TCP with a 7-byte MBAP header in front. There is no RTU CRC, and the MBAP unit ID takes the place of the slave ID. «It doesn't work» happens at one of the four layers below, so check them bottom-up. Specification details follow the Modbus Messaging on TCP/IP Implementation Guide V1.0b.
| Layer | Check | If it passes |
|---|---|---|
| 1. Network | Same subnet? Do ARP and ping reach it? | The device is on the network |
| 2. TCP connection | Does port 502 (or the configured port) accept? | A Modbus server is listening |
| 3. Modbus reply | Does a request get an MBAP reply? | Unit ID and function fit |
| 4. Values | Do the values make sense? | Address notation and word order fit |
1. Network: start with the subnet
Factory devices often ship with fixed IPs such as 192.168.1.x; if the PC is on another subnet, not even ping gets through. Adding a second IP on that subnet to the PC reaches the device without dropping your current network (e.g. device 192.168.1.10 → PC 192.168.1.200, mask 255.255.255.0). Some devices block ping, so «no ping» alone does not prove the device is absent — on the same subnet ARP still finds it.
2. Does port 502 accept a connection?
- The guide makes TCP 502 the default listening port and recommends that the port be configurable. Check whether the device's port was changed.
- An immediate refusal means nothing listens on that port; a long wait followed by failure usually means a firewall or router blocks it, or the address is wrong.
- The number of simultaneous TCP connections is left to the device's capacity, not fixed by the specification. If an HMI or SCADA already uses all of them, new connections are refused or the port looks closed. Disconnect other masters while testing, or look up the maximum in the manual.
- If the PC acts as the server (simulating a slave), Windows Firewall asks for permission the first time. Without it other devices cannot connect.
3. Connected but no reply: MBAP and unit ID
A request reading two holding registers from address 0, and its reply (values 100 and 200):
Request 00 01 00 00 00 06 01 03 00 00 00 02 Response 00 01 00 00 00 07 01 03 04 00 64 00 C8
| Bytes | Meaning |
|---|---|
| 00 01 | Transaction ID — copied into the reply by the server |
| 00 00 | Protocol ID — 0 for Modbus |
| 00 06 | Length — bytes that follow (unit ID + PDU) |
| 01 | Unit ID |
| 03 00 00 00 02 | PDU — function 03, start address 0, quantity 2 |
- A device that speaks Modbus TCP natively is already identified by its IP address, so the guide recommends the non-significant unit ID 0xFF (255) and also accepts 0. Which values a device actually accepts varies, so check the manual; if unsure, try 1, 255 and 0.
- Behind a gateway (TCP ↔ RTU), the unit ID is the serial device's slave ID (1–247). If the gateway returns exception 0A (path unavailable) or 0B (target failed to respond), the TCP side works and the problem is on the serial side.
- If the length field does not match the actual byte count, the device may discard the request. This happens often with hand-built bytes.
- TCP does not keep message boundaries, so replies can arrive split or two at once. Split replies by the MBAP length field and pair them with requests by transaction ID.
4. Connections drop or will not come back
- The guide recommends keeping the connection open rather than opening and closing it for every request. A master that reconnects for each request can use up the device's connection slots quickly.
- The server may close a connection too; the client must accept that and reopen when needed.
- If a cable is pulled or the peer powers off while connected, the device may keep holding that slot. The guide recommends enabling TCP keep-alive on both ends to detect broken connections. If the device only accepts a connection again after a power cycle, suspect this.
Replies arrive but values look wrong
That is interpretation, not communication. Values shifted by one point to address notation (0-based, 40001); wrong 32-bit values only point to word order. For exception replies, see the exception table in the no-response checklist.
In PortDock
- Net Scan sweeps a subnet with ARP and ping, shows devices with port 502 open and copies «IP:502». Its device ID read (FC 2B/0E) tries unit ID 1 first, then 255.
- Modbus Master matches Modbus TCP replies by transaction ID and discards late replies to earlier requests.
- TCP: connect to port 502 as a client, send requests with an MBAP header and decode the reply's transaction ID, length field and unit ID. Relay mode shows requests passing between an HMI and a PLC.
- «Modbus Frame Decoder» web tool: paste hex with an MBAP header to decode the header and PDU.
Published 2026-10-22