Initialize PLC bits to a safe state after a long power outage

5 min read · Published November 11, 2026

After a long power outage, treat every PLC bit and register as undefined. Write the reviewed safe values once at startup with the CLICK first-scan system bit, keep panel-local numbers on a separate restart list, and finish with a controlled power-cycle test.

After a long power outage, every bit and register in a battery-less CLICK PLC is undefined. Undefined covers two endings: an address can come back cleared, and it can come back holding whatever it held when power disappeared. A start command that survived as a 1 is a live request to run the machine, and the machine obeys it at power-up. So the startup state gets written on purpose: the reviewed values, once, on the controller's documented first-scan bit, then a controlled power-cycle test to check the rung against the table. This article uses a CLICK PLC and a graphical operator panel that writes to PLC addresses; any controller with a documented first-scan system bit takes the same pattern.

What a long outage leaves in memory

The CLICK documentation lists three years of data retention in the battery-backed SRAM, with a good battery installed. The battery is what backs that figure, and the machine in this situation runs with no battery, so the figure never enters the decision. What you find at power-up is unknown state: zero on some addresses, the last value on others, and nothing in the project that tells them apart.

That is why the startup state gets decided in logic. A start bit that reads ON after restart is a command, and retained ON is the state that starts equipment nobody asked to start.

Two kinds of value need two lists:

  • PLC addresses. Bits, counters and registers the panel writes to or the logic reads. You initialize these in the PLC program.
  • Panel-local values. A numeric input stored on the operator panel lives in the panel and follows the panel's own startup behavior. The PLC program has no path to it, so it goes on a restart list to check and re-enter by hand.

Where a CLICK setpoint comes back and why some values return at zero is covered in Why an HMI setpoint resets to zero after a power loss. The GX and GY bit addresses have their own write-up: Why GX and GY bits do not stay retentive after power loss. A value that should accumulate across restarts, such as run hours, wants a different home: PLC run hours reset at power loss: keep them in a counter.

What you need

  • The PLC project and the panel project files.
  • The CLICK documentation for your CPU: the memory map and the system control relays.
  • A table of every address that can energize equipment or mislead an operator, with the startup value each one gets.
  • A programming laptop with an address watch open on those addresses.
  • A way to remove and restore power under control, with the output circuit isolated under your site's lockout procedure.

Build the first-scan network

  1. List the addresses. Walk the project and write down every output, command bit, counter and setpoint that can energize equipment or mislead an operator. Include the bits the panel buttons write.
  2. Assign each address a startup value. Command bits that can move the machine get OFF. Counters the operator resets each batch get 0. Setpoints get the reviewed default. Leave every other address alone; a blanket reset of the whole memory erases valid data along with the stale data.
  3. Condition one network on SC2 _1st_SCAN. The CLICK documentation describes this system control relay as ON for the first scan only, so the network runs once each time the CPU enters RUN.
  4. Write the presets inside that network, one instruction per address from the table. Put the command-bit OFF presets in the first rungs, then the counters and setpoints.
  5. Put panel-local values on a restart card, one line each: what it should read and who re-enters it.
  6. Save the table with the project, so the next engineer knows which addresses initialize and which are left untouched.

Test it with a real power cycle

  1. Isolate the output circuit under your site's lockout procedure, so an unexpected output cannot cause motion or process upset.
  2. Open an address watch on the table addresses in the programming software.
  3. Remove power from the PLC and the panel together and leave them off for a few minutes. The initialization runs on the first scan whatever the outage lasted, so a short test exercises the same logic a weekend outage will.
  4. Restore power, let the CPU enter RUN and read the watch: every address in the table at its safe value.
  5. Switch the CPU from RUN to STOP and back to RUN. The presets apply again on the new first scan; confirm the second pass changes the table addresses and nothing outside the table.
  6. Re-enter the panel-local values from the restart card, then press each panel button once and confirm it writes its mapped PLC bit and nothing else.
  7. Repeat the whole test after any logic change that touches the table.

A panel that comes back blank or without its project is a separate failure; see HMI panel loses its project after a power cycle.

Example: a filler line restarts after a weekend outage

A filling station runs a CLICK PLC with a graphical operator panel and no battery. Power fails Friday at 18:00 and returns Monday at 06:00, 60 hours later. The reviewed table holds 6 command bits (start, jog, dosing pump, purge valve, heater, conveyor), 1 batch counter, and 2 PLC setpoints: fill weight 250.0 g and purge time 4.0 s. That is 6 + 1 + 2 = 9 addresses written once on SC2 _1st_SCAN. A fourth value, the product temperature setpoint of 8.0 °C, is stored on the panel, so it goes on the restart card.

Without the network, the Friday state comes back as it was: the batch counter holds 41, so the operator's next piece lands on 42, and the start bit holds whatever Friday left it. With the network, the first scan after RUN writes all 9 addresses: commands OFF, counter 0, setpoints 250.0 g and 4.0 s. The operator checks the panel-local setpoint, re-enters 8.0 °C, and presses start. One scan touched 9 addresses and the machine waited for a fresh command.

How to know the test passed

  • Every address in the table reads its safe value on the first scan after RUN.
  • No output energized at power-up, and the machine starts only on a fresh operator command.
  • Both RUN entries applied the presets, and nothing outside the table changed.
  • Panel-local values were re-entered, and each panel button writes only its mapped bit.
  • The result repeats after a logic change, on the same test.

Recommendation

Recommendation: put a first-scan initialization network in every CLICK program that drives outputs, and power-cycle test it before the machine ships. Preset the reviewed command bits OFF, reset counters to 0 and setpoints to their defaults on SC2 _1st_SCAN, keep a restart card for panel-local values, and leave every other address alone. Where a machine must resume a batch across short outages, move those values into documented battery-backed retentive memory with a good battery and verify them with the same timed power-cycle test.

Questions

Will the PLC bits revert to zero if the outage lasts long enough?

The CLICK documentation publishes a retention time for the battery-backed memory, three years with a good battery, and publishes no time at which battery-less memory decays to zero. An address can come back in any state, including a command bit that stayed ON. Write the startup state in logic on SC2 _1st_SCAN and treat whatever the hardware happens to hold as an input you override.

Does the first-scan preset run again after a STOP to RUN switch?

Yes. SC2 _1st_SCAN is ON for the first scan after each entry into RUN, so the presets also run after a project download or a STOP to RUN switch. That is usually what you want for command bits. Check any setpoint preset that would overwrite a value an operator entered mid-shift, and confirm the re-run during the test by switching the CPU from RUN to STOP and back while watching the addresses.

Can the machine resume exactly where it stopped after an outage?

Only with documented battery-backed retentive memory, a good battery, and a power-cycle test that covers the outage lengths the site actually sees. Verify each retained address by name, and keep the first-scan presets for every command bit that can energize equipment: the process value resumes, the commands wait for a fresh operator start.

Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.

Keep reading

Build your signAsk for a quote