Why an HMI setpoint resets to zero after a power loss

Why does a temperature setpoint go back to zero after a power cut?

The entry is a window onto a controller register, and at reconnect the panel redraws whatever that register holds. After an outage you see the register's value, so the panel's retentive flag never gets a vote in what the number shows.

The write path explains the rest. An operator types 350, presses Enter, and the entry object writes that number into the register the tag points at. If your entry object already moves a numeric entry into PLC memory on Enter, its write side is healthy, and the zero you see at boot is memory telling the truth. When the panel boots it reverses the trip: it reads the register and draws what it finds there, so a register that came back as 0000 draws as 0000 on the screen. The panel is the last device to touch the value. Painting a remembered number onto the display would cover the controller's zero while the control loop keeps using it, which is why the repair belongs one device over.

Why is the retentive option grayed out on the tag?

Panel retention is defined for the panel's own internal bit and word tags. A tag pointed at a controller address is a live read of that address, so the panel gives it no retention of its own and locks the option.

The gray-out is the feature's documented scope, and it is not an edit lock, a missing license, or a corrupt project. Two documented behaviors make internal retention a poor foundation for a setpoint anyway. On at least one panel family, an internal tag with its retain switch set on comes back switched off after the panel loses power, so the flag itself fails across the exact event you are fighting. Building a separate internal tag to hold the setpoint creates two copies of one number that can disagree, while the panel still redraws from the register at startup. Keep the tag pointed at the register, and give the register the retention.

Is the value lost in the panel or in the controller?

Test the two power cycles apart, one device at a time. Cycle panel power alone first while the controller runs, then cycle controller power under a planned outage. Where the number disappears names the fault and the fix.

Before you cycle anything on a live cell, confirm the process tolerates the setpoint sitting at zero during the outage and the re-entry; where it does not, hold the cell in its safe state and run these tests at the next planned stop.

• Panel power cycle only: the entry reads 0000 and the register still holds the setpoint. The display path is the problem. Check the tag's address, its data format, and the panel's startup read, and compare the register's value with the displayed value right after the restart.
• Controller power cycle: the register reads 0000 after restart. Retention is missing in the controller, or startup logic cleared the register. This is the case behind most complaints of this kind, and the fix below is controller-side.
• The register survives the outage and goes to 0000 when the program starts. A startup move, a recipe load, or another assignment writes the address. Search the program for every write to that register and identify the one that runs at startup.

Two neighbors fail the same way and respond to the same tests. A timer preset that resets to zero in the PLC fails the same ownership test, and that fix walks the same two power cycles. A toggle switch that resets at controller power up usually has a startup write behind it, and that fix separates a startup overwrite from lost retention.

How do I make the setpoint register keep its value through a power cycle?

Configure retention where the register lives, inside the controller's programming package, and delete any startup logic that writes to the register. Controllers do it in three ways: a retentive address range, a per-block retain option, or a retentive area of a set width.

Retention in a controller is standard practice, and the IEC 61131-3 programming standard defines a retain qualifier for variables for exactly this job: values that survive a power cycle. Your programming package will match one of these three:

1. A retentive address range. The controller setup holds a list of address ranges that survive power loss. Type the setpoint register into that list and download the configuration.
2. A retain option on a data block. Where the controller stores data in named blocks, retention is a block attribute. If the retain option on the block is grayed out, optimized block access is on for that block; switch that off first, then set retention on the block.
3. A retentive area of a set width. One family opens a retain dialog from the programming package's toolbar, where you enter the width of the retentive memory area. Size the area to cover every register that must survive.

Then search the program for every write to the register. Remove or rework only the initialization that fights the approved setpoint, and leave every other startup assignment alone. Keep the register's data representation while you work: the setpoint stays a BCD 16 word, and changing a tag's format to chase retention is how a healthy register ends up showing nonsense numbers from a PLC BCD analog register. Save the project, download it through your site's change control, and confirm the running controller carries the new configuration before you test anything.

Recommendation: When a panel numeric entry zeroes after a power cut, make the register it writes to retentive in the controller's programming package and remove the startup write that clears it; leave the panel tag untouched. Keep panel-internal retention for values the panel alone owns, such as a local screen preference, and read the grayed-out retentive checkbox as confirmation of where the value actually lives.

Example: what happens to a 350 °F oven setpoint?

An oven cell keeps its temperature setpoint in one controller register as a BCD 16 word. The operator enters 350, the register holds 0350, and the two power-cycle cases end differently. Follow both to a decision.

A BCD 16 word is 16 bits arranged as four 4-bit binary-coded decimal digits, one decimal digit per group, so it carries whole numbers from 0000 to 9999, with no sign and no decimal point. The operator's entry of 350 °F stores digits 0, 3, 5 and 0, one per group, and the register reads 0350. A setpoint of 12345, or a negative one, has no representation in that word and needs a different data type in both devices.

In the working case, the retentive range covers the register. The outage passes, the controller restarts with 0350 intact, the panel reads 0350 at reconnect and draws 350 °F, and the loop resumes on the approved target. Decision: the repair is complete, and the record from the checks below closes it.

In the broken case, retention was never configured. The controller's startup clear writes 0000, the panel faithfully draws 0 °F, and the loop chases a target nobody approved. Decision: apply the retention setup above, re-enter 350 through the panel as a temporary restore, and prove both power cycles before the next shift relies on the number.

How do I prove the fix before the next shift?

Enter an approved test value and watch the controller register through both power cycles. The register must keep the value through a controller restart, the panel must redraw that same value at reconnect, and startup logic must leave it alone.

1. With both devices powered, enter the approved test value and confirm the register reads 0350 in the example's BCD 16 word.
2. Cycle panel power only and watch the reconnect. The entry must redraw the register's value. Where the register never receives the entry at all, the write path is the fault, and the fix for an imported tag that ignores PLC register writes traces it.
3. Under a planned outage, cycle controller power and read the register before shutdown and after restart: 0350 must survive. Let the program run its startup sequence and read it again: it must still read 0350.
4. Record which device lost power, the register address, the before and after values, and any startup logic you changed.

Close the case by its symptom. A register that survives both cycles with the display in agreement is done. A register that clears when the program starts still has a startup write; go back to the write search. A display that disagrees with a correct register points at the tag's address or format, and that check comes before any further retention work.

Questions