PLC Memory Types Explained
A PLC is built around a small set of memory areas, each with a specific purpose. Understanding the difference between input image, output image, retentive and non-retentive memory is the key to predictable PLC behaviour — and the cause of many beginner bugs when it's misunderstood.
The five memory areas every PLC has
| Area | Updated when | Survives power cycle | Purpose |
|---|---|---|---|
| Input image table | Phase 1 of scan | No | Snapshot of every physical input at scan start |
| Output image table | Phase 3 of scan | No | Buffer of output bits; copied to output cards at scan end |
| Retentive memory | Whenever code writes | Yes | Battery-backed RAM or flash. Preserves values across power cycles, faults and reprogramming |
| Non-retentive memory | Whenever code writes | No (cleared on power-up) | Internal flags, scratch values, working variables |
| System memory | By firmware | Yes (firmware-managed) | Diagnostics, fault codes, scan-cycle stats, force tables |
Retentive memory — the critical concept
Retentive memory means PLC data memory that preserves its value across power cycles, processor restarts, and program transitions to STOP mode. Battery-backed RAM, non-volatile flash, or supercapacitor-backed cache holds the data; non-retentive memory is cleared to zero on power-up.
Why this matters in practice:
- Counter values for production totals must be retentive. Losing yesterday's output count after a power blip is unacceptable.
- Run-time totalisers for maintenance intervals must be retentive. The motor's "hours since last service" can't reset to zero on every brownout.
- Recipe and setpoint values entered by operators must be retentive. Operators don't want to re-enter the batch recipe after every controller reboot.
- Latched alarm states are typically retentive. An alarm that triggered during a power outage should still require operator acknowledgement after restoration.
- Internal scratch flags should be non-retentive. "Was the start button pressed?" should be FALSE after power-up regardless of state at shutdown.
Vendor-specific memory areas
Allen-Bradley ControlLogix / CompactLogix
- Tag-based memory — no fixed addresses. Tags are named (
Conv1_Run,Tank1_Level) and the compiler allocates memory. - Each tag has a Retain checkbox in Studio 5000. Default is non-retentive; enable Retain for values that must survive power cycles.
- Controller scope vs Program scope — controller-scope tags are visible plant-wide; program-scope tags are private to one program.
Siemens S7-1500 / TIA Portal
- Inputs (I) — input image table
- Outputs (Q) — output image table
- Memory bits (M) — non-retentive flag area by default; retain settings configurable
- Data Blocks (DB) — structured persistent data; can be retentive or non-retentive per DB
- Timers (T) and Counters (C) — separate areas with their own retain settings
- Local data (L) — temporary stack memory inside FBs/FCs; non-retentive
Mitsubishi MELSEC iQ-R / GX Works3
- X / Y — physical inputs and outputs
- M — internal relays (some retentive, some not — configured per range)
- D — data registers (most are non-retentive; D-Latch ranges are retentive)
- L — Latch relays (always retentive)
- R / ZR — file registers (retentive, large memory areas)
Common memory bugs
- Reading the output image inside the same scan it was set. The output bit reflects the previous scan's value until phase 3. Use input states or internal flags that update synchronously.
- Forgetting to mark counters retentive. Production count goes to zero on every reboot. Symptom: missing 8-hour shifts of data.
- Marking everything retentive. Internal scratch flags retain stale values from before the power-up, causing weird startup behaviour.
- Battery dead. On older PLCs (Siemens S7-300, AB SLC-500, AB PLC-5) battery-backed retentive memory loses data when the battery dies. Check battery status routinely; modern PLCs use supercaps or flash and don't have this issue.
- Mixing scopes — Allen-Bradley program-scope tag with the same name as a controller-scope tag is a bug magnet.
Frequently asked questions
What is retentive memory in a PLC?
Retentive memory means PLC data memory that preserves its value across power cycles, processor restarts, and transitions to STOP mode. Battery-backed RAM, non-volatile flash, or supercapacitor-backed cache holds the data. Non-retentive memory is cleared to zero on power-up. Counter totals, run-time totalisers, recipe values and setpoints are typically retentive; internal scratch flags are not.
What is the difference between retentive and non-retentive memory?
Retentive memory survives power cycles, faults and program transitions to STOP — its values persist. Non-retentive memory is cleared to zero or its initial value on power-up. Use retentive for production totals, run-time counters, operator setpoints, and latched alarms; use non-retentive for internal flags and scratch variables that should reset on every cold start.
What is an input image table?
The input image table is a memory area in the PLC that holds a snapshot of every physical input at the start of each scan cycle (phase 1 of the scan). The user program reads from the input image table, not directly from the input cards. This means physical input changes during the scan are not visible until the next scan starts.
What is the difference between input image and output image?
The input image table is updated at the start of each scan (phase 1) by reading every physical input card. The output image table is updated by the user program throughout phase 2 and copied to output cards at phase 3 (end of scan). Both are non-retentive — they exist only for the duration of one scan.
How do I make a counter retentive in Allen-Bradley Studio 5000?
In Studio 5000, every tag has a Retain checkbox in the tag properties dialog. Check it for tags whose values must survive power cycles. Note that Allen-Bradley uses tag-based memory (not numbered addresses), so retention is configured per-tag rather than per-memory-area as in Siemens or Mitsubishi.