The controller is not losing the data. The HMI writes its startup tag values over the retained registers when its link comes up. Prove it with a cable-unplugged power-cycle test, then give every retained setting one owner and verify with six power-cycle runs.
Your retained settings are not being lost. The controller keeps them through the power cycle, and the panel writes over them a few seconds later, when its communication link comes up and it pushes its own startup tag values into the registers. The fault looks like a retention failure because the write has already landed by the time you read the values. One test splits it in about two minutes: unplug the link between panel and controller, power-cycle the controller alone, and read the variables back. If the values survive, retention works and the panel is the writer. The fix is ownership. The controller keeps each setting and the panel writes a register only when the operator edits it, or the panel keeps its own retentive copy of every setting and restores it before the link writes anything.
Symptoms and what each one points to
- Values read back correctly with the panel disconnected, wrong once it reconnects. The panel writes its startup values when the link comes up. This is the case this article fixes.
- Values wrong even with the panel disconnected. The fault is in the controller: the variable sits outside the remanent list that is actually stored, or the reset you ran is one of the types that clears RETAIN. Fix that first; nothing at the panel will help.
- The panel shows a value first, then the controller value changes underneath it. The panel displayed its own tag value and wrote it back at link-up.
- Only some settings revert. Only those tags carry an initial value or receive a startup action, screen object or script write. The tags with no writer keep their values.
A value the panel shows without reading it from the controller is a candidate writer. What the screen displays should follow the controller, which is the whole point of PLC-driven HMI graphics.
The cable-unplugged test
- At the panel, set every retained setting to a value you can recognise, different from the defaults and from each other.
- Unplug the Ethernet cable at the panel or at the controller port.
- Power-cycle the controller with the machine in a safe state; a retained temperature or speed setting drives real equipment.
- Go online with the programming tool and read the variables.
- Reconnect the cable, power-cycle both devices together, and read again.
| Readback after step 4 | Readback after step 5 | What it means |
|---|---|---|
| All operator values | All operator values | Nobody writes the registers; retention is sound |
| All operator values | Startup defaults | The panel writes at link-up; apply the fix below |
| Wrong values | Wrong values | The controller loses the values on its own; fix retention there |
Steps 1 to 4 take about two minutes and they split the fault with no configuration change.
Example: four retained settings on a packaging line
One packaging line keeps four settings as retained variables in a controller that a panel reaches over ModbusTCP. The four settings and their values are illustrative inputs for this walkthrough; the fault pattern is the one above. Batch target is 500 pieces with a panel initial value of 0 pieces, seal temperature is 165 °C with an initial value of 150 °C, conveyor speed is 32 m/min with an initial value of 20 m/min, and label offset is 3 mm with an initial value of 0 mm. Both devices lose power over the weekend.
The rule in words: retention decides what the controller keeps in its own memory between power-off and power-on. A tag write that arrives after the link comes up is new data, so the device that writes last after startup owns the value. To find the writer, take the panel out of the circuit.
Test A, panel disconnected: set the four tags to 500 pieces, 165 °C, 32 m/min and 3 mm, cycle the controller, and read back 500, 165, 32 and 3. Four values written, four values read back, 0 lost.
Test B, both devices cycled together: read back 0 pieces, 150 °C, 20 m/min and 0 mm, and compare each value against its two candidates:
| Tag | Operator value | Panel initial value | Test B readback | Match |
|---|---|---|---|---|
| Batch target | 500 pieces | 0 pieces | 0 pieces | Initial value |
| Seal temperature | 165 °C | 150 °C | 150 °C | Initial value |
| Conveyor speed | 32 m/min | 20 m/min | 20 m/min | Initial value |
| Label offset | 3 mm | 0 mm | 0 mm | Initial value |
Four matches to the initial-value column, zero to the operator column. The timing fits the same story: the panel finishes loading after the controller is already running, and an online watch shows the four registers flip at that moment.
Decision: every value survived Test A and reverted in Test B to the panel's configured initial values, so the panel is the writer and the fix below applies. The threshold is one lost value in Test A. If even one value disappears while the panel is unplugged, the fault is in the controller's retention, and the panel fix does not apply.
What the retain flag governs, and what it does not
RETAIN is the IEC 61131-3 attribute for variables that keep their value across a power loss. PERSISTENT is the wider remanent list controller vendors add on top. The reset lists are documented in each controller vendor's remanent-variable documentation: RETAIN variables are reinitialised after a reset cold, a reset origin and an application download, and kept otherwise; PERSISTENT variables survive an uncontrolled termination, a reset cold and a new download of the PLC project on controllers that support them. Every one of those rules governs what the controller does with its own memory between power-off and power-on. None of them governs a write that arrives from the panel after the link is up. Your retention held the value for the few seconds between controller boot and panel boot, and then the panel replaced it.
The write is documented behavior too. HMI vendors document an On Startup action for setting PLC tag values from the panel, and a panel tag that carries an initial value comes back after a power loss at that value or at zero, then pushes it to the controller the moment communication starts.
The tempting fixes fail for specific reasons:
- Adding RETAIN or PERSISTENT flags again. Test A already proved the retention works.
- Changing Modbus register addresses. A wrong map returns no data or garbage; it never returns a clean set of exact startup defaults.
- Re-downloading the controller project. An application download is on the documented list of resets that clear RETAIN, so the download itself clears the values.
- Power-cycling in a lucky order. Whichever device writes last after the link comes up still owns the value.
The fix: one owner per setting
Pick one owner per retained variable and remove every other writer.
Controller as owner is the choice when the controller runs the process:
- Delete the initial value from every panel tag mapped to a retained register.
- Delete any On Startup action, screen-open action or script that writes those tags.
- Let the panel read the registers, and write one only when the operator edits that field.
Showing controller values at the panel without writing them is a technique of its own; displaying PLC configuration values in a visualization walks through it.
Panel as owner is the choice when the panel must carry the value through a controller power-down:
- Create one copy variable per setting in the panel, in the memory type your HMI software documents as retentive.
- Copy the setting into its copy on data change. A periodic copy can snapshot a default and make the fault permanent.
- Add an On Startup action that loads each setting from its copy, so the first value the panel writes to the controller is the last operator value. Vendors document the On Startup action as the place panel-side values are set; the same place restores from copies.
- Delete the initial values from the setting tags anyway, so no default can reach the controller before the restore runs.
When the panel on the machine only ever shows values and nobody edits settings there, treat it as a status screen instead; factory status display or operator HMI covers choosing between the two.
Recommendation: make the controller the owner of every retained setting that drives the process, and strip initial values and startup writes from the panel tags so the panel writes a register only when the operator edits that field. Use the retentive-copy scheme only for settings the panel must carry through a controller power-down, with one copy per setting, saved on data change and loaded by the On Startup action.
Verify with six power-cycle runs
Three cases times two boot orders gives six runs: both devices together, panel alone and controller alone, each run once with the controller powered first and once with the panel powered first. Set every retained setting to a unique test value, run all six, and read the controller online values after each. The pass condition is identical in all six: the readback equals the test values. Watch the online values while the panel boots; a flicker to a default means a startup write is still armed somewhere.
Rerun the six runs after any project change on either device, and expect to re-enter retained values after a controller application download. Confirm every setting against the recipe sheet before running product; a default that slips through can drive a heater 15 °C low or run a conveyor at the wrong speed.
What brings the problem back
- A second writer. Another panel, a SCADA node or controller logic that writes the same register at startup reintroduces the fault. Search the controller program for writes to those registers and the panel project for other tags on the same addresses.
- The restore runs after the copy trigger is armed. If a change event fires while a default still sits in the setting tag, the copy takes the default. Sequence the On Startup action so the restore completes first, and keep the initial values deleted so there is no default to copy.
- Copies in volatile panel memory. A copy that clears at power-up restores nothing. Place each copy in the panel memory type documented as retentive and prove it with a panel-only power cycle.
Questions
Which reset types clear RETAIN variables?
The documented lists: a reset cold, a reset origin and an application download reinitialise RETAIN variables, while a plain power loss keeps them. The wider PERSISTENT list also survives an uncontrolled termination, a reset cold and a new download of the PLC project. To see which list your settings need, write four recognisable values and run each reset type in turn, reading the values back after each.
Why did the fault start after months of correct values?
The write lands only where a panel tag carries an initial value or a startup action, screen-open object or script puts the register. If the fault appeared after a panel project change, compare each reverted value against the new project's initial values. A match identifies the tag that puts the value; delete that initial value or write and the fault goes with it.
When is the fault on the controller side?
When values are lost while the panel is unplugged. The variable may sit outside the remanent list that is actually stored, or the reset in use is one of the documented types that clears the attribute. Bring the readback results from the unplugged cycle to the controller vendor, because no panel-side change fixes that case.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.