Make a Modbus master reconnect after a slave outage

Why does my Modbus master never reconnect after the slave comes back?

The master latched the communication error and is waiting for an acknowledgment. With auto-restart disabled, one failed command halts the channel. A restored cable or a finished firmware download brings the slave back and leaves the master silent.

Two outages look the same to the master and differ at the slave. Pull the Ethernet cable and the physical path is gone; the master's connect attempts time out. Start a firmware download on the slave and the Ethernet link can stay up while the slave code stops. The port stops accepting connections, and the master's commands time out against a device that still shows a link light. Both end the same way: the master records a communication error and, by default, stops executing the Modbus command until the error is confirmed.

The recovery you want is master-side. The slave has no part in it; a slave that is back online answers the first request it receives. The question is whether your master ever sends one.

Where do I enable auto-restart communication on the master?

Open the master's settings screen in the engineering project, tick the checkbox named Auto-restart communication, redeploy, and confirm the running master reports it enabled. With it on, the master confirms each communication error itself and re-issues the command on the next cycle.

1. Open the Modbus master device in the project tree and go to its settings screen.
2. Tick Auto-restart communication. Tools that use different words call this automatic retry or reconnect on error.
3. Download the project to the controller or runtime host so the setting reaches the running system.
4. Verify with the slave healthy: exchanges run, and the error counter stays at zero.
5. Pull the link for 10 s and restore it: exchanges resume with no operator action.

That last step is the acceptance test. If the setting will not stay enabled after a download, read why a control application config setting is ignored before you blame the channel.

Auto-restart makes the master keep trying. It repairs nothing else: a wrong address, a closed port and a slave that never restarts its Modbus service stay broken no matter how often the master retries.

What do I check first, cable, slave, or master?

Check in this order: link indications at both ends and at any switch, then that the slave application runs and listens on the configured address, then the master's endpoint settings. Physical faults are the most common and the cheapest to rule out.

A link light confirms the cable path. A successful ping confirms the IP stack. Neither tells you the Modbus service is listening, so finish with a capture on the host interface and watch the connection attempt reach the slave and the port answer. On the serial side the equivalent faults are addressing and framing, covered in Modbus RTU no reply and address errors.

What does each symptom after the outage point to?

Match what you observe to where execution stops. No link points at cable and interfaces. Requests that leave with no answer point at the path or the slave service. Exception responses point at the request itself, and good responses with unchanged data point at your mapping.

• No link light at either end: physical. Swap the cable, check the switch port, check the host interface is up.
• Link up, no connection attempts leave the host: the master stopped. Check the auto-restart setting, the channel's error state and the command scheduler.
• Attempts leave, no answer returns: path or slave service. Check the destination address, the port, and whether the slave application started after the download.
• Answers return with a Modbus exception code: application level. Check the function code, register address and quantity against the slave's map.
• Good answers return, your values never change: mapping or freshness. Check scaling, byte order, and where the logic consumes the value.

A packet capture settles the first three in one pass. Pairing it with the master's status words shows whether a reconnect delay belongs to the network stack or to the master; Modbus TCP packet decoding and reconnect timing works through that pairing.

How do I read the Modbus status inside my program?

Read the channel's error flag, the error identifier and the command-done edge from the master function block's status interface, sampled every cycle. The error bit gives the master's opinion, and the done edge tells you a fresh answer arrived in that cycle.

Three signals are enough for logic:

• Error: true while the channel is faulted. Log the error identifier beside it; the identifier separates a timeout from a refused connection from an exception code.
• Done edge: one scan where a command completed. Use it to timestamp the last good read.
• Busy count: how many commands are queued. A stuck busy with no done edge points at the scheduler, and where the scheduler runs depends on task order, so trace it with PLC execution order across task layers.

Treat a single connected flag with care. It summarizes the library's belief, and that belief drifts in known ways: at least one Modbus library release corrected a fault that logged slaves as connected even with no connection present. Build validity from the done edge and the error bit, and use the connected flag on the operator screen only.

Record the error state during the outage and its transition after recovery, then match that transition to a captured response. One correlation run makes the status words dependable inputs to your logic.

What timeout and retry values should I set?

Set the response timeout to 1000 ms, retries to 3, the TCP connect timeout to 5 s, and the poll cycle to 500 ms. One unanswered command then fails the channel in a known 4 s, and recovery starts on the next 500 ms cycle after the slave answers.

• Response timeout 1000 ms: the common library default. Keep it above your slowest legitimate answer; a loaded slave that answers in 600 ms needs 1000 ms or more.
• Retries 3: enough to ride through a busy cycle, few enough that a dead slave is declared in 4 s (first attempt plus 3 retries at 1000 ms each) instead of locking the poll task.
• Connect timeout 5 s: set this yourself. An unanswered TCP connect stalls for tens of seconds at operating-system defaults while the stack retries; a 5 s cap puts that wait under your control.
• Poll cycle 500 ms: two reads per second per register group. A faster poll shortens recovery by at most one cycle and loads the slave for nothing.

Change one number at a time and retest with the 10 s link pull. The channel's fail time becomes your stale-data window, so keep it short on channels that feed control logic.

How does recovery play out in one worked example?

A soft master on a plant PC polls a controller-board slave every 500 ms with a 1000 ms timeout, 3 retries, a 5 s connect timeout and auto-restart on. A 30 s firmware download ends with fresh data back 2.5 s later.

• During the download, the slave's port refuses connections in milliseconds, so failed attempts run at the poll pace: 30 s ÷ 0.5 s = 60 error cycles, each acknowledged automatically. The error counter rises by about 60.
• The download ends. The slave reboots and opens its listener in 2 s, and the next poll lands within one cycle: 2 s + 0.5 s = 2.5 s from end of download to fresh data.
• Pull the cable instead and the arithmetic changes: each connect burns the full 5 s, so 30 s ÷ 5 s = 6 failed attempts. The worst case after the cable returns is one more 5 s attempt before the next one connects. Recovery still lands inside 6 s.

Now the same outage with auto-restart off: the master records one error, stops, and the register on your screen holds its last value until somebody acknowledges the fault. The slave was gone 30 s; the data was frozen for the rest of the shift. That difference is the whole fix.

How should my logic treat data while the link is down?

Mark a polled value invalid after 3 missed cycles, which at a 500 ms poll is 1.5 s. Auto-restart brings the requests back, and only your logic stops a frozen register being used as live data.

Build it from the status words you already read:

• Timestamp the last done edge. A value older than 3 cycles is stale, whatever the register says.
• Inhibit what depends on it: hold outputs, suppress alarms derived from it, and flag the value on every screen that shows it.
• Restore use on a fresh done edge, never on the connected flag.
• Check freshness on demand with a test register the slave increments every second. A register that never changes looks identical frozen and live.

If a polled value feeds an interlock, drive the dependent output to its safe state on invalid and let a human return it to service. Recovery should be automatic; restarting a guarded motion is a decision.

Recommendation: Enable auto-restart communication on every channel that must recover unattended, with a 1000 ms response timeout, 3 retries, a 5 s connect timeout and a 500 ms poll, and gate every polled value on a 3-cycle freshness window. Leave auto-restart off only where a person must review each communication fault before the channel resumes. When the same values also feed a shop-floor status display, give that board its own data path so a master outage never blanks it.

Questions