Modbus TCP timeout: a 7-step checklist
Your Modbus TCP client times out, you restart it, it works for a minute and then times out again. Most timeouts come from the network path or the client's settings, not from the device firmware. Work through these checks in order; each one rules out a whole group of causes.
Check the basics. Confirm the device's IP address, that your PC is on the same subnet (or has a route to it), and that the device answers a ping. Some devices block ping, so a failed ping is a hint, not proof.
Check the port. Modbus TCP uses port 502 by default. Some devices use another port, and Modbus/TCP Security (TLS) normally uses port 802. Check the device manual and your firewall.
Check for another client. Many devices accept only one or a few simultaneous TCP connections. If a SCADA system, HMI or PLC already holds the connection, your new client may be refused or time out.
Check the unit ID. Direct Ethernet devices often accept any unit ID, but gateways that forward requests to serial slaves need the correct one. A wrong unit ID usually shows up as a timeout, not as an error.
Check the address range. Start with a small read: one register at address 0 with function 03. If that works but your real range times out, the device may not implement part of the range. A register scan shows which address ranges respond and which return an exception.
Check the response timeout and the polling rate. A slow device or a gateway may need 1 to 3 seconds. Raise the response timeout before concluding the device is not answering, and lower the polling rate if requests pile up.
Capture and compare. If a known good client works and yours does not, compare the exact requests: function code, address, quantity and unit ID. A list of requests that you can replay and compare against expected responses makes this much faster.
Doing this in Busscope
Open a Modbus TCP connection and add one small poll window: function 03, address 0, quantity 1. If it answers, widen the window step by step until it fails. Set Response timeout in the connection settings if slow answers are the problem, and Delay between polls to space requests out.
For steps 5 and 7, use the two tools built for them. The Register Probe scans address ranges and marks which ones answer, which return an exception and which time out. The Request Runner replays a saved list of requests and checks each response against an expected result: OK, EX n, TIMEOUT or a full response frame.
Exception codes are explained on the Modbus exception codes page. If the device answers with an exception, the timeout is not the problem and the request needs fixing.
Try Busscope
Install Busscope and run it without a license key to see whether it fits your work. Evaluation mode is for trying the tool, not for production or commercial use.