HMI text lost after a power cycle: find who clears it

Why did the text disappear after the power came back?

Because one of the two devices restarted and wrote its own startup value over the entry, and in most cases that device is the PLC: the panel saved the text, the controller restarted, and its startup logic assigned a default before the panel reconnected.

The acronym you will see in controller documentation, POR, means power-on reset: the restart that follows a complete loss of supply power. A sag that never reaches zero can instead trip a brown-out reset in one device and leave the other running, and power-on reset versus brown-out reset behavior shows how a controller tells the two apart. That asymmetry matters here. The panel and the controller restart at different moments during the same event, so one device's startup code always gets the last word.

Retention has one job: it holds a value across a restart. It gives no protection from a write. When your text comes back as a default, some code assigned that default after the power returned, and on a PLC-backed field that code usually lives in the controller's initialization. Panel runtimes differ, from internal tags kept in RAM that clears at power down to a memory class documented to hold through a shutdown. You can settle which one you have with one test, and the next two sections run it.

Is the panel dropping the value or is the PLC overwriting it?

Read the tag on both sides after the reset: if the PLC tag holds a default or an old value while your entry is gone, the PLC overwrote it; if the PLC still holds your entry and only the display is wrong, the panel storage cleared.

Open the text-entry object in the panel project and read its tag assignment before you change anything. The look of the field tells you nothing about where the value is stored; the assigned address does. Then match your symptom:

• The field shows a default or an old value, and the PLC tag holds that same string. The controller's startup logic wrote it. This is the common case.
• The PLC tag still holds your entry while the field is blank or stale. The panel is not reading the tag. Check the address, the data type and the link.
• The field is blank, no PLC tag is behind it, and a power cycle did it. The value lived in panel-internal storage that clears at power down.
• The text survives power cycles and disappears after a project download. Panel-internal storage again; the download rewrites it, and the fix is the PLC-backed field described below.
• The entry flips back minutes or hours later with no power event at all. Something else owns the tag, and finding what owns a tag that changes back after an HMI write walks that hunt.
• The whole project is missing after the cycle, not one field. That is a panel fault of another kind: see an HMI panel that loses its project after a power cycle.

How do I catch the moment the value changes?

Poll the PLC tag once per second from the programming software across the restart and log the panel's reconnect time; the poll that first shows the default tells you which device was running when the change landed.

Power cycling restarts everything downstream, pumps, heaters and conveyors included, so run this test between cycles with nothing mid-batch.

1. Type a short, unmistakable test value, 7 characters such as WO-4471, and confirm it in the PLC tag.
2. Start a one-poll-per-second watch on the tag and note two times: when the controller enters RUN, and when the panel finishes booting and reconnects.
3. Drop power to both devices, fully, then restore it.
4. Read the tag on the first poll after RUN and keep logging for 60 s.
5. Compare three timestamps: entry, first poll after RUN, panel reconnect.

If the tag already holds the default on that first poll after RUN, the write happened inside the controller before the panel existed again. If the tag still holds your entry at reconnect and changes in the following seconds, the write crossed the link, from a transfer-on-start in the panel project or an entry screen that writes its default when it opens. Run the whole test through three consecutive power cycles: one clean pass can be coincidence, three in a row is a result.

What does an example power-cycle trace look like?

Here is one carried through with numbers: a work-order label, the 7-character string WO-4471, typed at 06:05, wiped out by an outage at 06:12, and traced through the restart with one poll per second.

A label field on a filler line, mapped to a PLC string tag in retained memory:

The arithmetic that convicts the controller: the tag already read DEFAULT-01 at 06:13:06, and the panel reconnected at 06:13:40, so the value changed at least 34 s before the panel could have written anything, 40 minus 6. Retention did its job, the tag held WO-4471 through the outage, and the controller's startup logic replaced it between 06:13:05 and 06:13:06. The panel then displayed the tag faithfully.

A search of the controller program for writes to that tag finds one rung: a move of the constant DEFAULT-01, conditioned on the first-scan trigger, the one-shot that fires at initial startup to initialize program elements. Used this way, that rung also erases every operator entry on every power-up.

Flip the timestamps and the verdict flips. If the tag polled WO-4471 at 06:13:40 and read DEFAULT-01 at 06:13:42, two seconds after reconnect, the write came through the link. Hunt a transfer-on-start in the panel project or an entry screen that loads a default when it opens.

Where should the text live: in the panel or in the PLC?

In the PLC, in a memory area documented to hold values through power loss, whenever the text is machine data; keep panel-internal storage only for entries an operator can retype without loss when a reset or download clears them.

Controller memory set up for retention holds values between power cycles; that is what it is for, and PLC retentive memory for restart-after-outage logic shows the same choice made for pump states. On the panel side, where HMI internal tag retention survives power-off and download lists which events each storage class survives. No panel-internal class survives a download, so a field that must live through a panel replacement or an update belongs in the controller. And when the same label needs to reach the whole floor, a separate shop-floor signage screen can show it as a slide from a memory card, outside the HMI project entirely.

What do I change so the text survives the next reset?

Move the field onto a retained PLC tag, then remove the startup write that loads a default on every power-up; the default load belongs on a genuine memory-loss condition, and anything else leaves the entry intact.

1. Back up both projects before you edit either.
2. Pick a controller memory area documented to retain values through power loss, and confirm in the controller's retention setup that the area is inside it.
3. Confirm the string tag is long enough: at least one character more than the longest real entry, since many string types spend one on the terminator.
4. Point the panel's text-entry object at that tag, with matching data type and length.
5. Find every write to the tag in the controller program and re-gate the default load. Run it only on a true memory-loss condition; if the software offers no such condition, delete the startup write and load defaults from an operator command.
6. Check the panel project for writes on connect or on screen open, and remove any that reload a default.
7. Download both projects in a maintenance window, then run the verification below.

How do I know the fix worked?

Type the test value, power the pair down and up three times in a row, and confirm the tag and the display both still read it after every cycle; then run one project download and confirm that event also leaves it alone.

• Before: the tag reads the test value, the field shows it, and the one-poll-per-second watch is running.
• Cycles 1, 2 and 3: after each, the tag and the field both read the test value, and the 60 s log after RUN shows no late write.
• Download test: one project download to the panel, then read the tag; PLC-held storage does not move.
• Record the four results with their times. That record is your evidence the next time an entry goes missing.

Why does the text survive power cycles but not a project download?

Because a download rewrites the panel's storage, and panel-internal values are cleared with it, while a PLC-held tag sits in the controller and a download to the panel never touches it; the two events need two different storage choices.

A download rebuilds the panel's runtime storage, and panel-internal values go with it, retentive classes included. The controller is a different box on a different supply, and a download aimed at the panel has no path into it. That is the whole argument for PLC-backed storage, and it is why the two symptoms, lost after a power cycle and lost after a download, point at different fixes. If you see both, the field is panel-internal, and the power-cycle case needs the storage move described above.

Recommendation: put any text the machine must keep into controller memory with retention configured, and gate its default load so it runs only after a true memory loss; keep panel-internal storage only for values an operator retypes anyway, and accept that a download clears those.

Questions