PLC Retentive Memory Explained: What Survives a Power Cycle and Why It Matters

The machine loses power halfway through a cycle.

Ten minutes later, power returns. The PLC starts, the HMI comes back to life, and one number on the screen still says Step 47.

That may be exactly what the programmer intended.

Or it may be the beginning of a very bad afternoon.

PLCs can preserve selected values even when power is removed, the processor stops or the program is restarted. This ability is known as retention, and it is useful for production totals, recipes, accumulated operating hours and other information that should not disappear every time somebody switches off the control panel.

The trouble begins when a retained value is mistaken for a safe, verified machine condition.

A cylinder position stored before shutdown does not prove that the cylinder is still there after power returns. A retained sequence step does not guarantee that every actuator remains in the correct position. A remembered “automatic mode” bit should not quietly restart a machine without fresh safety checks.

Retentive memory is not inherently dangerous. Unplanned retentive behaviour is.

What Is Retentive Memory in a PLC?

Retentive memory is PLC memory that preserves its value through an interruption that would otherwise reset normal working data.

Depending on the controller, retained data may survive:

• Loss of control power
• A transition from RUN to STOP
• A warm restart
• A program restart
• A CPU replacement using a memory card
• A download or project reload
• A battery change
• A firmware update

Do not assume that every PLC treats those events in the same way.

A tag that survives a short power interruption may still be cleared by a full memory reset. Another value may remain through a download but disappear during a cold restart. The exact behaviour depends on:

• PLC manufacturer
• CPU family
• Firmware
• Memory architecture
• Tag configuration
• Program structure
• Startup type
• Download procedure

The controller manual and project settings are the final authority.

Retentive and Non-Retentive Data

At a basic level, PLC data can be divided into two groups.

Non-Retentive Data

Non-retentive data returns to a defined initial value after the relevant restart event.

That initial value may be:

• Zero
• False
• A configured startup value
• A value loaded by initialization logic

Examples often include:

• Temporary calculations
• One-scan control flags
• Intermediate logic results
• Non-retentive timer accumulators
• Transient communication status
• Commands that should not survive a restart

A non-retentive motor command should normally return to OFF rather than remembering that it was ON before power failed.

Retentive Data

Retentive data preserves its previous value until the program deliberately changes or clears it.

Common examples include:

• Production totals
• Machine operating hours
• Batch totals
• Recipe selections
• Calibration constants
• Maintenance counters
• Historical alarm information
• Retentive timer accumulators
• Sequence information, when intentionally designed that way

Retention is especially useful when losing the value would create inconvenience, waste or inaccurate records.

It becomes risky when the value controls physical movement without being revalidated.

Retentive Memory Is Not the Same as a Retentive Instruction

These two concepts are related, but they are not identical.

Retentive Memory

Retentive memory refers to how a data location behaves during a restart or power loss.

A normal integer, Boolean or real-number tag may be configured as retentive.

Retentive Instruction

A retentive instruction preserves an accumulated or latched state when its rung condition becomes false during normal program execution.

For example, a retentive timer continues holding its accumulated time when the enabling rung goes false. It usually requires a separate reset instruction to clear the accumulation.

That does not automatically tell you what happens during every possible power-cycle or download event.

The PLC platform still determines how the instruction’s internal data is stored and initialized.

This distinction matters because a technician may say, “That timer is retentive,” while referring only to rung behaviour—not necessarily its behaviour through a complete CPU memory reset.

How PLCs Preserve Retentive Values

PLCs use several memory technologies to preserve data.

Older systems frequently relied on battery-backed RAM. A battery maintained memory while the main control power was removed.

Modern controllers may use:

• Nonvolatile flash memory
• Ferroelectric memory
• Battery-backed memory
• Supercapacitor-backed memory
• Removable memory cards
• A combination of volatile and nonvolatile storage

The mechanism changes from one controller family to another.

Some CPUs periodically copy selected values into nonvolatile storage. Others retain working memory directly. A controller may also store the complete application on a memory card and reload it during startup.

These differences affect:

• How quickly values are saved
• How many write cycles are permitted
• What happens during sudden power loss
• Whether a battery warning matters
• Whether retained values follow a replacement CPU
• Whether an old memory-card image overwrites newer data

Never remove a battery or memory card casually from a production controller.

First confirm:

• A current project backup exists
• Retained data has been recorded where necessary
• The CPU procedure is understood
• Replacement hardware is compatible
• The machine is in a safe state

Retentive Timers

A retentive timer accumulates elapsed time while its enabling condition is true.

When the condition becomes false, the accumulated value remains instead of returning immediately to zero.

The timer resumes from the stored value the next time it is enabled.

In Rockwell terminology, a common example is the:

RTO — Retentive Timer On

An RTO generally requires a separate:

RES — Reset instruction

to clear its accumulated value and done status.

Suppose an RTO has a preset of 60 seconds.

The timer runs for 25 seconds, then the rung becomes false.

The accumulator remains at approximately 25 seconds.

When the rung becomes true again, timing continues from 25 seconds rather than restarting from zero.

This makes retentive timers useful for measuring cumulative activity.

Practical Uses for Retentive Timers

Retentive timers may be used to track:

• Pump running time
• Motor operating hours
• Conveyor movement time
• Time spent in production
• Accumulated alarm duration
• Maintenance intervals
• Heater operating time
• Filter usage
• Lubrication-system runtime

For long-term operating-hour totals, the program may periodically convert accumulated time into hours and store the total in a retentive register.

A normal millisecond timer is not always the best choice for tracking several years of machine operation. Data range, timer resolution and overflow must be considered.

Retentive Timer Example

Imagine a pump maintenance warning that should activate after 500 operating hours.

The program tracks only the time while the pump feedback confirms that the motor is actually running.

The accumulated time should survive:

• Normal pump stops
• Shift shutdowns
• Weekend power removal
• Brief control-power interruptions

When the total reaches 500 hours, the PLC activates a maintenance reminder.

After the pump is serviced, an authorized maintenance command resets the accumulated value.

That is a sensible use of retention.

Resetting the timer every time the pump stops would defeat the purpose.

Non-Retentive Timers

A non-retentive on-delay timer typically accumulates time while its rung is true and clears when the rung becomes false.

A common example is a standard TON instruction.

Suppose the timer delays a conveyor start by five seconds.

If the start condition remains true for three seconds and then disappears, the timer normally returns to zero. The next start request must complete the full five-second delay.

This is usually the desired behaviour for:

• Startup delays
• Debounce timing
• Sequence delays
• Alarm delays
• Off-condition verification
• Temporary process timing

However, timer behaviour during CPU restart still depends on the controller platform.

Do not assume every timer named TON behaves identically in every PLC family.

Retentive Counters

Counters commonly retain their accumulated value when the count rung becomes false.

Examples include:

• CTU — Count Up
• CTD — Count Down

A count-up instruction may increment each time a product sensor changes from false to true. When the sensor turns off, the accumulated count remains.

The value is usually cleared by a reset instruction rather than by the count rung becoming false.

This makes counters useful for:

• Product totals
• Reject totals
• Machine cycles
• Tool usage
• Pallet counts
• Maintenance events
• Batch quantities

Again, there is a difference between retaining the count during normal scan execution and retaining it through every possible power-cycle event.

Check how the controller stores the counter’s backing data.

Tags and Data Registers

Ordinary data tags may also be retentive.

Depending on the PLC platform, retention may be configured:

• Tag by tag
• Memory area by memory area
• Data block by data block
• Automatically for certain data types
• Through startup logic
• Through nonvolatile storage functions

Potentially retained values include:

• Integers
• Real numbers
• Boolean states
• Strings
• Structures
• Arrays
• User-defined data types
• Function-block instance data

Some PLC families make most normal controller tags persistent unless initialization logic changes them. Others require selected tags or memory ranges to be marked as retained.

The dangerous assumption is thinking that all PLCs work like the one you used last week.

They do not.

Warm Restart, Cold Restart and Memory Reset

Restart terminology varies, but many PLCs distinguish between different startup conditions.

Warm Restart

A warm restart usually preserves more working data.

The CPU stops and restarts without completely reinitializing every memory area.

Cold Restart

A cold restart commonly reinitializes a larger portion of program data.

Some retained variables may remain, while temporary and non-retained values return to startup values.

Memory Reset or Factory Reset

A full memory reset may clear:

• User program
• Hardware configuration
• Retained values
• Diagnostics
• Communication settings

The exact effect depends on the CPU.

Do not use restart terms casually. “Reboot the PLC” is not a precise instruction when several restart types are available.

Before choosing one, understand what data will be preserved and what will be erased.

First-Scan and Startup Logic

Many PLCs provide a system flag or startup routine that executes during the first program scan after entering RUN mode.

This is often used to initialize the machine.

Typical startup actions include:

• Clearing temporary commands
• Resetting sequence requests
• Setting known default modes
• Initializing communication states
• Checking retained-data validity
• Resetting nonessential latches
• Generating a power-restored alarm
• Preventing automatic restart
• Requiring operator acknowledgement

The first-scan logic should be designed deliberately.

A blanket reset of every tag may destroy useful production and calibration data.

Doing nothing may allow stale commands to survive.

Good startup logic separates data into categories rather than treating all memory the same way.

What Should Usually Be Retained?

Values commonly worth retaining include:

• Total production count
• Lifetime machine cycles
• Operating hours
• Maintenance counters
• Recipe parameters
• Calibrated offsets
• Equipment identification
• Last completed batch number
• Historical totals
• User-configured setpoints, when appropriate

Even these values should be checked for validity after startup.

For example, a temperature setpoint retained as 9,999°C because of corrupted memory should not be accepted merely because it survived the power cycle.

What Usually Should Not Be Retained?

Values commonly returned to a safe default include:

• Motor start commands
• Solenoid commands
• Automatic cycle requests
• Jog commands
• Manual push-button states
• Temporary permissives
• Communication-health bits
• Sensor simulation bits
• Maintenance bypasses
• Motion requests
• One-shot memory
• Active pulse commands

The program should generally reconstruct these conditions from real inputs and current operating logic.

A command that existed before power failure may no longer be appropriate after power returns.

Retaining a Sequence Step

Whether a machine sequence should retain its current step is a design decision.

There is no universal answer.

Reasons to Retain the Step

Retention may reduce:

• Lost product
• Interrupted batches
• Restart time
• Manual recovery work
• Process waste

This may be useful for long batch processes where the real process state can be verified reliably.

Reasons Not to Retain the Step

A retained step may no longer match:

• Cylinder positions
• Product position
• Valve states
• Drive conditions
• Pressure
• Material state
• Safety status

A power failure may cause pneumatic cylinders to drift, contactors to drop out or material to move.

Resuming blindly from the old step can create:

• Mechanical collision
• Duplicate operation
• Product damage
• Incorrect dosing
• Unsafe movement
• Lost sequence synchronization

If sequence retention is used, startup logic must verify that the physical process still matches the retained state.

Example: Conveyor Sequence After Power Loss

Suppose a conveyor stops while transporting a carton between two sensors.

Before power loss, the PLC stores:

• Sequence step: 40
• Conveyor command: ON
• Entry sensor: OFF
• Exit sensor: OFF

After power returns, the carton may still be between the sensors.

If the PLC clears the sequence step and assumes the conveyor is empty, it may accept another carton and create a collision.

If it retains step 40 and immediately restarts the conveyor, someone may be working on the machine.

A better restart strategy could be:

1. Keep the conveyor output OFF.
2. Restore the sequence information.
3. Read actual sensors.
4. Require safety circuits to be healthy.
5. Display “Cycle interrupted—recovery required.”
6. Allow an operator-controlled recovery movement.
7. Resume automatic operation only after the machine state is verified.

Retention provides information.

It should not provide automatic permission to move.

Retained State Versus Real State

A retained Boolean tells you what the PLC remembered.

It does not necessarily tell you what exists physically.

For example, the controller may retain:

Cylinder_Extended = TRUE

After power loss:

• Air pressure may bleed away.
• The cylinder may retract under gravity.
• Someone may move the mechanism manually.
• A valve may return to its spring position.
• The sensor may no longer be active.

The program should use the real position sensor after startup, not trust the remembered status bit indefinitely.

A good rule is:

Retain history and configuration. Revalidate physical state.

Unexpected Automatic Restarts

One of the greatest risks of poorly designed retentive memory is unexpected machine restart.

Imagine that these values remain true:

• Automatic mode
• Cycle start latch
• Motor run request
• No-fault latch

Power returns, inputs update and the program immediately resumes the output command.

Whether the motor actually starts depends on the full safety and electrical design, but software should not rely on uncertainty.

Restart prevention may include:

• Clearing run requests on startup
• Requiring a new start-button edge
• Requiring operator acknowledgement
• Verifying all interlocks
• Confirming drive-ready status
• Resetting sequence commands
• Using hardwired anti-restart circuits where required

Safety requirements must be addressed by the complete machine design, not only ordinary PLC logic.

Retentive Latches

Set/reset or latch/unlatch instructions may preserve a Boolean state until an opposite instruction clears it.

Examples include:

• OTL and OTU
• SET and RESET
• SR and RS function blocks

A latched bit can remain true after its original condition disappears.

That is useful for:

• Alarm memory
• Start requests
• State machines
• Event capture
• Maintenance warnings

It can also create confusing faults.

A bit may remain true because:

• The unlatch condition never occurred
• The reset routine did not execute
• A program branch was bypassed
• The PLC restarted before cleanup logic ran
• Another routine set it again
• The programmer forgot that it was retentive

Whenever a latched condition behaves strangely, cross-reference both the set and reset instructions.

Look for every place that writes to the tag.

Alarm Retention

Many alarms are intentionally retained until acknowledged.

This allows the operator to see that an event occurred even if the original fault condition has already disappeared.

A retained alarm system may store:

• Active alarm
• Unacknowledged state
• First-occurrence time
• Number of occurrences
• Historical event data

A good alarm design distinguishes between:

• Fault condition currently active
• Fault condition no longer active
• Alarm still awaiting acknowledgement

Clearing the physical fault should not necessarily erase the event history.

However, old alarms should not permanently block machine operation unless that is intentionally required.

Recipe and Setpoint Retention

Recipes and setpoints are obvious candidates for retentive memory.

Operators do not want every temperature, speed and timing value returning to zero after each shutdown.

Still, retained configuration needs protection.

Useful safeguards include:

• Minimum and maximum limits
• Data-type checking
• Recipe version number
• Checksum or validity code
• Default fallback values
• Controlled write permissions
• Change history
• Confirmation before loading

A corrupted retained value can be more dangerous than a cleared value because it may look legitimate.

For example, a retained speed reference of 65,530 may be interpreted as a valid integer even though it exceeds the machine’s safe range.

Always validate important retained values at startup.

Retained Data and Program Downloads

Downloads can affect stored data differently depending on the PLC platform and project settings.

Possible outcomes include:

• Current values are preserved.
• Initial values overwrite current values.
• Only modified blocks are reinitialized.
• All retained data is cleared.
• Data is restored from the offline project.
• Online values can be uploaded and preserved before download.

Before downloading to a production controller, identify important retained values.

Consider recording:

• Calibration constants
• Recipe data
• Production totals
• Maintenance hours
• Drive parameters
• Counters
• Communication settings

A successful program download is not particularly helpful if every calibrated offset has quietly returned to factory default.

Retained Data and CPU Replacement

When replacing a CPU, determine where the retained values actually live.

They may be stored in:

• The old CPU
• A removable memory card
• A battery-backed memory area
• An HMI
• A SCADA database
• A recipe file
• Another controller

Installing the project in a new processor may restore the logic but not the current production data.

In other cases, inserting an old memory card may restore an outdated program and stale retained values.

Before replacement:

1. Upload the current project.
2. Record critical retained data.
3. Save recipes and calibration settings.
4. Confirm firmware compatibility.
5. Check memory-card contents.
6. Follow the manufacturer’s replacement procedure.
7. Validate values after startup.

Do not assume that “same PLC model” means “everything will come back exactly as before.”

Battery and Retention Problems

Older PLCs may depend on a battery to preserve memory.

Signs of a weak or failed battery can include:

• Battery warning LED
• Diagnostic alarm
• Loss of program after power removal
• Retained values returning to default
• Real-time clock resetting
• Inconsistent startup behaviour

Replace batteries according to the manufacturer’s instructions.

Some controllers must remain powered during battery replacement. Others use capacitors that provide a limited replacement window.

Installing a battery backward, leaving it disconnected too long or replacing it with the wrong type can lead to data loss.

Check the manual before pulling it out.

Troubleshooting Retentive Memory Problems

Retentive-memory faults usually appear as unexpected behaviour after:

• Power loss
• Program download
• CPU restart
• Maintenance work
• Battery replacement
• Memory-card change
• Mode transition

The following process helps narrow the cause.

Step 1: Identify What Should Have Happened

Determine whether the value was intended to:

• Stay unchanged
• Return to zero
• Return to a default value
• Be reconstructed from field inputs
• Be loaded from a recipe
• Be reset by startup logic

Do not begin by assuming the current behaviour is wrong.

The program may be doing exactly what it was designed to do—just not what anyone expected.

Step 2: Check the Actual Tag Value

Go online and inspect:

• Current value
• Initial value
• Retentive attribute
• Data-block settings
• Timer accumulator
• Counter accumulator
• Latch state
• First-scan status

Compare the online value with the offline project.

Step 3: Cross-Reference the Tag

Find every instruction that writes to the value.

Look for:

• MOV instructions
• Reset instructions
• Set/reset coils
• Startup routines
• HMI writes
• Recipe loading
• Communication data
• Array copying
• Fault-recovery routines

The tag may be correctly retained and then immediately overwritten during startup.

Or the opposite: the expected reset instruction may never execute.

Step 4: Review Startup Logic

Inspect first-scan or startup routines.

Check whether they:

• Reset the correct tag
• Execute in the correct program
• Depend on another condition
• Run only after a cold restart
• Are skipped after a warm restart
• Use the correct controller system bit

A reset rung that looks correct but never runs is not much use.

Step 5: Determine the Restart Type

Find out what actually happened:

• Brief voltage dip
• Full power removal
• CPU mode change
• Warm restart
• Cold restart
• Memory reset
• Download
• Firmware update

Different events may produce different memory behaviour.

Step 6: Check Controller Documentation

Verify the platform-specific rules for:

• Retained tags
• Timer behaviour
• Counter behaviour
• Data-block retention
• Battery backup
• Download effects
• Startup organization blocks
• Memory-card loading

This is not the place to rely on vague recollection from another PLC brand.

Step 7: Reproduce the Test Safely

Where appropriate, create a controlled test.

For example:

1. Record selected values.
2. Stop the machine safely.
3. Remove control power using the approved procedure.
4. Restore power.
5. Record the values again.
6. Compare expected and actual behaviour.

Do not perform an uncontrolled power-cycle test on a production process that can be damaged by interruption.

Common Retentive-Memory Symptoms

Missing Reset Instructions

A retentive instruction needs a deliberate clearing method.

For a retentive timer or counter, check:

• Is a reset instruction present?
• Does the reset rung ever become true?
• Is the reset tag controlled by the HMI?
• Is the correct timer or counter referenced?
• Is the reset active for enough scans?
• Does another routine immediately restore the old value?

Copied program sections sometimes contain reset instructions pointing to the wrong tag.

The code looks tidy. The machine does not agree.

Retained Values That Keep Coming Back

A value may be manually changed to zero and then return to its old value.

Possible causes include:

• Another routine writes it
• HMI recipe reload
• SCADA command
• Produced/consumed data
• Memory-card restoration
• Redundant controller synchronization
• Startup initialization
• Data copied from a backup structure

Cross-reference the tag and inspect external data sources.

Not every mysterious returning value comes from retentive memory itself.

Safe Programming Practices

Decide Retention Intentionally

Every important tag should fall into a defined category:

• Temporary
• Command
• Physical status
• Configuration
• Historical total
• Sequence state
• Alarm memory

Retention should follow that purpose.

Do not mark an entire data block as retentive merely because three values inside it need to survive.

That may preserve dozens of temporary bits nobody intended to keep.

Separate Commands From Status

Use separate tags for:

• Requested state
• Actual state
• Retained historical state

For example:

• Conveyor_Run_Request
• Conveyor_Running_Feedback
• Conveyor_Run_Hours

Only the operating-hours total clearly needs long-term retention.

This separation makes startup behaviour easier to understand.

Use Safe Startup Defaults

Commands should normally start in a safe condition.

Examples:

• Outputs OFF
• Automatic cycle not requested
• Motion commands cleared
• Manual jog commands cleared
• Simulation disabled
• Maintenance bypasses disabled
• Alarm reset request false

The physical safety system must still provide appropriate protection independently of ordinary program memory.

Require a New Start Action

After a power interruption, consider requiring:

• New start-button press
• Operator acknowledgement
• Mode reselection
• Fault reset
• Machine-state verification

A retained start command should not be enough on its own to restart hazardous movement.

Validate Retained Data

At startup, check important values for:

• Valid range
• Correct version
• Plausible value
• Checksum
• Required initialization marker

If the value fails validation:

• Load a safe default
• Generate an alarm
• Prevent automatic operation
• Require maintenance confirmation

Document Reset Behaviour

Program comments should explain:

• Why the value is retained
• What clears it
• What happens after power loss
• Which startup routine validates it
• Whether an HMI command can reset it
• Whether it survives a download

A comment such as “retentive” is not enough.

A better comment would be:

Retains cumulative pump runtime through power loss. Reset only after documented pump service using maintenance HMI command. Do not clear during normal machine startup.

That gives the next technician useful context.

Protect Maintenance Totals

Maintenance counters should not be easy to reset accidentally.

Possible protections include:

• Password-controlled HMI screen
• Confirmation prompt
• Separate maintenance mode
• Reset-event logging
• Date and user record
• Minimum authorization level

A maintenance timer that anyone can reset from the main operator screen is not a reliable maintenance record.

Back Up Critical Retained Values

Important values may be stored outside the CPU as well.

Possible backup locations include:

• HMI recipe files
• SCADA historian
• Database
• Memory card
• Maintenance report
• Controller backup file

This is useful for:

• CPU replacement
• Memory corruption
• Accidental reset
• Program migration
• Disaster recovery

Do not create multiple uncontrolled copies without defining which one is authoritative.

Otherwise, an old backup can overwrite the correct current value.

Retention and Safety Systems

Safety-related restart behaviour must be designed and validated according to the applicable machine-safety requirements.

Ordinary retentive PLC memory should not be used as proof that a safety condition is valid.

After restart, safety systems may need to verify:

• Emergency-stop circuit
• Guard status
• Safety contactor feedback
• Safe-speed status
• Reset conditions
• Manual restart requirement

A remembered “safety healthy” bit is not a substitute for reading the actual safety system.

Practical Example: Retentive Batch Total

A filling machine produces batches of 500 containers.

The machine retains:

• Current batch count
• Total production count
• Selected recipe
• Last completed batch number

It does not retain:

• Conveyor run command
• Filler valve command
• Start-button request
• Temporary timing bits

After power returns:

1. Outputs remain off.
2. The operator sees that the interrupted batch had reached 327 containers.
3. The PLC checks sensor and actuator states.
4. The HMI asks whether to recover or discard the interrupted batch.
5. A new start command is required.
6. The batch count continues only after controlled recovery.

This preserves useful production data without allowing an automatic restart.

Practical Example: Retentive Motor Hours

A motor feedback input activates a runtime accumulator.

Every completed time interval is added to a retained operating-hours tag.

When the total reaches the maintenance threshold:

• A service-due alarm appears.
• Production may continue.
• Maintenance performs the required work.
• An authorized reset clears the service interval.
• The lifetime operating-hours value remains.

This uses two different retained values:

• Service interval hours
• Lifetime hours

Resetting the service interval should not erase the lifetime total.

Practical Example: A Bad Retentive Design

A pneumatic press retains:

• Automatic mode
• Cycle active
• Step number
• Press-down output request

Power fails while the press is moving downward.

When power returns, the retained output request becomes active before the program verifies the press position or operator area.

Even if the safety system prevents immediate motion, the control logic is now out of synchronization and difficult to recover.

A safer design would:

• Clear motion requests
• Preserve only necessary sequence history
• Re-read position sensors
• Require safety reset
• Enter a controlled recovery state
• Require a deliberate operator command

Retention should help recovery, not attempt to pretend the interruption never happened.

Retentive Memory Checklist

Before commissioning or modifying a PLC program, review:

• Which tags survive power loss?
• Which tags reset?
• Which timers are retentive?
• Which counters require reset instructions?
• Can a retained value command motion?
• Can the machine restart automatically?
• Is sequence state verified after startup?
• Are recipe values range-checked?
• Are maintenance counters protected?
• What happens during download?
• What happens during CPU replacement?
• Is battery or memory-card health monitored?
• Are first-scan actions documented?
• Can important retained values be restored from backup?

If those questions do not have clear answers, the restart behaviour is not fully understood.

Final Thoughts

Retentive memory allows a PLC to remember what matters after power disappears.

Used properly, it protects production totals, recipes, calibration values, maintenance records and interrupted-process information.

Used carelessly, it preserves stale commands, incorrect sequence states and assumptions that no longer match the physical machine.

The key is not to make everything retentive or everything non-retentive.

It is to classify the data deliberately.

Retain information that should survive. Clear commands that should require a fresh decision. Revalidate every physical condition after startup, and never treat remembered software state as proof that a machine is safe to move.

A PLC remembering the past can be extremely useful.

It still needs to check the present.