PortDock

No reply from a Modbus device — a checklist for RTU and TCP

Every request times out? Narrow it down by what comes back, then check slave ID, baud, parity, wiring, IP, port, unit ID and the device's Modbus settings.

When a master sends a request and nothing comes back, all you see is «timeout». The cause can sit anywhere from the wiring to the device configuration, so the fastest route is to narrow it down from the traffic log first. This checklist combines the troubleshooting notes in the PortDock Modbus Master help with cases found in device manuals while building this site's register maps.

0. First: does anything come back?

Traffic logMeaningGo to
Only TX, no RX at allThe device did not understand the request or thinks it is not addressed to it1 – 5
RX arrives but fails the CRCBytes flow but get corrupted2 (baud, parity), RS-485 wiring
My own bytes come straight backEcho from a two-wire RS-485 adapterAdapter setting (PortDock Modbus Master skips the echo itself)
Exception reply (function + 0x80)Communication works; the request does not fit the device6
Occasional timeouts onlyTiming or noise7

1. Slave ID

If the first byte of the request does not match the device's slave ID, the device ignores it silently — no error comes back. Check the ID in the device menu; if you do not know it, ask each ID in turn (PortDock Modbus Master «Scan… → Slave ID scan», 200 ms wait per ID by default; an exception reply also counts as «device present»). ID 0 is broadcast: devices act on it but never reply.

2. Baud rate, data bits, parity, stop bits

If any of these differ, the device cannot read the bytes and stays silent, or its reply fails the CRC. Factory defaults vary: among the ten devices on this site most use 9600 bps, but the LS ELECTRIC GIMAC1000 ships at 38400 bps, the Rootech Accura 3300E and 2300 use even parity, and the Autonics TK, TX and MT4W use two stop bits.

The Modbus serial specification makes even parity the default and asks for two stop bits when no parity is used, yet many devices ship as 8N1. Follow the device manual, not the specification. Each device page lists its defaults at the top, with manual page numbers.

3. Wiring and adapter (RTU)

4. Modbus settings on the device

Some devices have a communication port that ships set to a protocol other than Modbus. The Hanyoung Nux VX, for example, defaults to PC Link; to use Modbus RTU set the protocol (PRS) to 3 (manual p.103–104). The LS ELECTRIC LSLV-S100 keeps slave ID, protocol, baud and data format in CM.01–CM.04, shipping as ID 1, Modbus-RTU, 9600 bps, 8N1 (manual p.281). Each device page notes where these settings live, with page numbers.

5. For Modbus TCP

6. If you get an exception

CodeMeaningCommon causes
01Illegal functionFunction code the device lacks, e.g. the Rootech Accura 3300E supports only 03, 06 and 16
02Illegal data address0-based vs 1-based vs 40001 confusion, quantity past the end, gaps in the map
03Illegal data valueQuantity over the limit (125 registers per read in the spec, some devices allow fewer), value out of range
04Slave device failureCheck the device status and the manual's error list
06Slave device busyIncrease the delay between requests

If reads work but writes fail with an exception, look for a write lock. The Hanyoung Nux LC ships with communication write protection (CWP) ON and answers write requests with an exception until it is switched OFF on the front panel (manual p.31, p.34). Per-request limits also differ: 124 registers on the LS ELECTRIC GIMAC1000, 31 with FC03 on the Hanyoung Nux VX.

7. If timeouts happen only now and then

Check the master without the device

If you suspect the master software, test it against PortDock Modbus Slave instead of the real device. On the same PC, start Slave as a Modbus TCP server (port 502 or 1502) and connect the master to 127.0.0.1. Slave's fault injection (delay, no reply, exception, bad CRC) shows how the master handles timeouts and retries before you go on site.

Published 2026-10-19