Fix a Modbus TCP slave register that resets after a write

Why does a written register revert about one second later?

The slave device's own timeout did it. The ModbusTCP_Slave_Device in CODESYS carries a timeout checkbox with a time value. When that interval lapses, the slave returns its registers to their defaults. A good write reverting about 1 second later is what that reads as.

The write arrived. Your readback shows the new value for that second, so the network, the IP plan, TCP port 502 and the master driver all work; a broken path fails the write outright. What fails is retention.

The timeout setting supervises the master. With the checkbox enabled, the slave watches for master activity, and when the interval expires it returns its register image to its default values. An operator-driven OPC write is one transaction; the timer then runs out with nothing behind it, and the register goes back. In the confirmed case the master kept polling reads the whole time and the written value still reverted. The ongoing reads kept the slave reachable but kept nothing in the register.

Two ways out. Clear the checkbox and the value holds until the master or your application changes it. Leave it enabled and set the interval past the longest gap between writes; the next two sections show where and how far.

Which symptom points to which fault?

A write that lands and then snaps back points inside the slave configuration. Failing reads, a Modbus exception, and a value that changes with the program each point somewhere else. The list below names the fault and the check for each.

• The readback shows the new value for about 1 s, then the old value returns. The device timeout. Work the next two sections.
• The write returns a Modbus exception. Wrong register type, or an address outside every configured channel. See the register-type section.
• Reads time out or return nothing. Link, IP addressing, TCP port 502, or a runtime that stopped. See the bus section.
• The value holds with a blank program and reverts with the real one. Your code assigns the mapped variable. See the overwrite section.
• The same master writes correctly to a simulator and to another vendor's controller running CODESYS 2.3. The fault sits in this slave's configuration, so work the timeout and the channels on this device.

Where is the timeout setting on the ModbusTCP_Slave_Device?

In the device tree of your CODESYS project: double-click the ModbusTCP_Slave_Device. The timeout appears as a checkbox with a time value in its configuration dialog. This is the setting that produced the revert in the case confirmed on CODESYS 3.5 SP6.

Three states cover every installation:

• Checkbox cleared. The written value holds until the master or the application writes something else.
• Checkbox set, interval shorter than the gap between writes. The value reverts about one interval after each write.
• Checkbox set, interval longer than the gap. The value holds while the master keeps its schedule.

After changing it, log in, download the application, and put the runtime in RUN. A dialog change reaches the controller only with the download.

What interval keeps the register alive if the timeout stays enabled?

Twice the longest gap between writes from that master. The interval has to sit above the gap for the value to hold. The factor of two leaves room for one delayed or missed write before the register drops back to its default.

Keep the timeout when the default values are the state you want after a silent master; a line whose safe speed is a known number is a good case. Drop it when writes are operator-driven and the gaps have no ceiling.

To size it, measure the longest gap between writes from that master, including quiet shifts where nobody edits a tag, then double the figure.

The master carries its own communication settings, among them a response timeout. That value sets how long the master waits for an answer before it faults the request; the vendor's Modbus TCP master documentation describes it. It sets the master's patience and never the slave's register contents. When the fault runs the other way, a slave that drops out and returns, read make a Modbus master reconnect after a slave outage.

Example: how long a timeout does a setpoint written every five minutes need?

Clear the checkbox: with an operator-driven write the quiet gap has no limit, so no interval works. On a master that also writes a cyclic tag every 5 minutes, the gap tops out at 300 s and the interval wants 2 x 300 s = 600 s.

Walk the faulty state first. The revert came about 1 s after each write, which pins the old interval near 1 s. The quiet gap on the cyclic tag is 300 s. 300 / 1 = 300: the timer expires three hundred times across one quiet gap, and the register reverts about 1 s after every write. That is exactly the reported symptom.

Now the fix on the cyclic master: 2 x 300 s = 600 s. One missed 300 s write still leaves 300 s of cover, so the register holds through a hiccup. On the operator-driven tag with no heartbeat, clear the checkbox and let the cyclic tag carry the supervision.

When the register is a speed or position setpoint on a running machine, treat the revert as a real command to the default value. Fix the timeout before commissioning, and pick a default the machine can receive safely.

Could the application be overwriting the variable?

Yes, and the blank-program test settles it in about ten minutes. Download an empty application, repeat the write, and a value that now holds means your own code assigns the mapped variable every cycle, with the last writer in the scan winning the register.

A register the master writes has one mapped variable. When a POU assigns that variable every scan, the register shows your code's value, which is often the initialized value and reads as a revert. Search the project for assignments to the variable name, including writes inside libraries you call. Two clean fixes: give the master sole ownership and copy the value into an internal variable for the logic, or gate your assignment so it runs only on a local command.

Is the master writing to a register type that holds writes?

Holding registers and coils take writes; input registers and discrete inputs are read-only by function-code definition. A write there comes back as an exception or leaves the value untouched, a different signature from the 1 s revert.

In the slave device, every channel lists an access type, an offset and a length; the address the master writes has to land inside one writable channel. An off-by-one offset lands the write in the next variable while a read of the intended address keeps showing the old value, which looks like a revert that never took. A PC Modbus test client can run the same writes to coils and registers, which is useful as a second master when you want to isolate the SCADA driver. Values that arrive as 0 instead of reverting are a data-format question, covered in fixing CODESYS showing 0 for Modbus TCP analog values. The same two faults, no reply and a wrong address, behave alike on serial links; see Modbus RTU master no reply and address errors.

What does it mean when the slave says the bus is not running?

The fieldbus stack never started, so the slave is absent from TCP port 502 and both reads and writes fail, unlike the timeout fault where reads keep answering. One site saw this on runtime 3.5.10 with the Ethernet adapter and the ModbusTCP_Slave_Device both at 3.5.10.0.

When the IDE reports "The bus is not running" on the slave device, work in this order:

1. Confirm the application is downloaded and the runtime is in RUN, in the IDE's online state, in STOP nothing serves the bus.
2. Open the Ethernet adapter object in the device tree and confirm it is bound to the interface the controller actually uses, with the slave device as its active child.
3. Confirm a task is assigned as the bus cycle task on the slave device; a missing or unscheduled task leaves the bus idle.
4. From the master side, confirm TCP port 502 on the controller accepts a connection.
5. Match the versions of the runtime, the Ethernet device and the slave device description in the device repository; a mismatch can stop the stack from starting.

Read the slave's device state online after each change. It has to leave the not-running state before any register test tells you anything.

How do you confirm the write now holds?

Put the mapped variable in a watch list, write one nonzero value from the master, and check it is still there after 60 s with no further writes. Sixty seconds sits far past the old 1 s revert, so a value that survives it has held.

1. Go online in the IDE and add the mapped variable to a watch list.
2. Write one nonzero value from the master, once.
3. Confirm the watched variable shows the value and still shows it after 60 s, with no further write.
4. Read the address back through the master driver and confirm it matches.
5. Write a second, different value and confirm that one holds too, while the master keeps polling reads.

Recommendation: Clear the timeout checkbox on the ModbusTCP_Slave_Device whenever the master writes on operator action; that alone ends the 1 s revert. Keep the timeout enabled only when the register defaults are the state you want after a silent master, and then set the interval to at least twice the longest gap between writes, 600 s for a 300 s gap.

Questions