Power returns, the CPU restarts — and the machine either resumes sanely or does something expensive. The difference is which data you chose to retain.
The mechanics
S7-1200/1500 retain marked data across power cycles (retentive memory areas, with size limits per CPU — check yours before designing). In optimized DBs, retentivity is set per element or struct: exactly the granularity good design wants. The memory card holds the program; retentive memory holds the state.
What belongs in each bucket
Retain: totalizers and production counters, recipe selections and setpoints entered by operators, calibration results, maintenance counters, the machine’s notion of “which product is loaded”. Never retain: sequence step states that assume physics froze with the power (the cylinder will have drifted), command bits, anything whose stale value can move iron on restart. The restart OB (OB100) is where retained state gets validated: plausibility-check the retained step against actual sensor reality before trusting it — resume when they agree, force a defined home sequence when they do not.
Recipes deserve their own tier: retained DB for the working set, plus export (CSV via the web server, or SCADA) for the library — retentive memory is not a backup strategy, and CPU swaps prove it monthly somewhere.
FAQ
Do S7-1500 counters and timers retain? IEC counters/timers are DB data — retain them per element like anything else. Classic S5-style memory habits do not apply.
What survives a memory reset (MRES)? Deliberately: not the retentive data. MRES is the factory-fresh act; document that fact next to the procedure so nobody discovers it operationally.
Zone Otomasyon designs restart behavior explicitly — the power-cut test is part of our commissioning. Machines that wake up polite.