S7-400 Cold Restart: Online Parameter Loss in PCS7 V7 SP3

Problem Overview

When engineers modify parameters online in a PCS 7 V7.0 SP3 multi-project - for example toggling the B_EN input on an instance of an MB (Motor Block, the standard PCS 7 APL driver for motor starters) - and then trigger a cold restart on the S7-400 CPU, those online changes are not preserved. The block reappears with the values last downloaded from the project, even though the operator changed them from the ES (Engineering Station) or from an OS (Operator Station) faceplate while the AS (Automation Station) was in RUN.

This behavior surprises many maintenance engineers because online parameter changes look as if they should be persistent. They survive a warm restart in some cases, but they never survive a cold restart. The root cause is documented in the Siemens reference manual SIMATIC - Automation System S7-400 CPU Specifications, chapter 4.2 "Overview of the Startup Scenarios for S7-400 CPUs" (Siemens support entry ID 14016796).

Cold Restart Behavior per Siemens S7-400 Specifications

Chapter 4.2 of the S7-400 CPU Specifications manual describes the cold restart semantics in detail. The relevant statements, paraphrased into a single operational rule set, are:

• At the cold restart, all data - process input image (PII), process output image (PIQ), memory markers (M), timers (T), counters (C) and data blocks (DB) - are reset to the start values stored in the load memory, irrespective of whether the affected areas were configured as retentive or non-retentive.
• Retentive flags, timers and counters would retain their last valid value across a warm restart, but a cold restart overrides this and forces the load-memory image on every memory area.
• All DBs assigned the Non Retain attribute are reset to their load values.
• DBs assigned the Retain attribute would normally keep their last valid value across a warm restart, but at a cold restart the load-memory values win for those DBs as well.
• Program processing starts from the beginning again. The CPU runs the configured startup OB first (typically OB 100 for warm restart, OB 101 for hot restart, OB 102 for cold restart) and then enters the cyclic OB 1.

For projects running on a PCS 7 V7.0 SP3 AS with the standard CFC/SFC chart generation, the B_EN input of an MB is held in the MB instance DB and follows the same memory rules. Because the PCS 7 APL block type for the MB declares the instance DB as non-retentive by default, the bit returns to its compiled value after every cold restart.

Where Online Parameter Changes Are Stored

Online changes made from the ES (Monitor/Modify, or via CFC test mode) are written into the working memory of the S7-400 CPU - the same data area (RAM) that holds the process image, M/T/C, and DB instance values. The download from the engineering project, by contrast, is loaded into the load memory first (typically a RAM card or the integrated flash) and then mirrored into the working memory during the startup sequence.

Because online changes never write back to the load memory, a cold restart - which restores working memory from load memory - silently overwrites them. The distinction is summarized in the table below.

Recipe values are the only common exception. The PCS 7 recipe system stores recipes on the OS server, not in the CPU, and re-loads them on operator request. A cold restart does not touch the OS server, so recipes survive.

Memory Architecture: Load, Work, and Retentive Memory

The S7-400 distinguishes three physical memory regions, each with a different persistence guarantee:

1. Load memory - non-volatile storage for the user program, hardware configuration, and the initial values of all data blocks. On S7-400 CPUs this is the RAM card, the integrated flash, or, on newer revisions, the internal flash area. Contents survive power loss indefinitely and are not affected by the CPU backup battery.
2. Work memory - volatile RAM that holds the currently executing code and the current values of all data blocks. Online modifications only touch this region. Contents are lost on power loss unless backed by the CPU backup battery.
3. Retentive memory - a battery-backed portion of work memory reserved for M, T, C, and DB bits explicitly marked as retentive. The backup lasts only as long as the backup battery in the CPU is healthy and the configured backup time window (typically a few hours to several days) is not exceeded.

The cold-restart process performs an explicit memory reset: the CPU clears the work-memory area and rebuilds it from load memory. The retentive backup is intentionally overwritten with load-memory data because the cold restart is defined as "start from a known clean state". Any online modification that exists only in work memory - which is the case for every Monitor/Modify action - is therefore guaranteed to be lost.

DB Retain Attribute and Startup Behavior

The Retain attribute on a DB is the only mechanism by which a data block can keep its runtime values across a CPU restart. The attribute is set per-DB in the DB properties dialog (or in the block-type definition for FB instance DBs). Its effect depends on the restart type as shown below.

Even with the Retain attribute set, a cold restart clears the runtime values and reinitializes from load memory. The Retain flag only helps across a warm restart or a brief power cycle while the CPU backup battery is intact.

Startup Types Compared on S7-400

The cold restart is the most aggressive of the three. The S7-400 CPU clears the entire work memory and rebuilds it from load memory. In PCS 7 V7.0 SP3, a cold restart is generally triggered from the SIMATIC Manager via PLC > Operating Mode > Cold Restart, or by the ES function "Complete Restart", or automatically by the CPU after certain fatal errors detected in OB 121 / OB 122 (programming errors / I/O access errors).

Startup Organization Blocks (OBs)

The S7-400 calls a specific startup OB once after the restart and before OB 1 begins cycling. The mapping is fixed:

• OB 100 - "Complete restart / Warm restart". Called once when the CPU performs a warm restart. The user typically re-initializes non-retentive process data here, restores operator commands, or triggers a one-shot pre-conditioning sequence.
• OB 101 - "Hot restart". Called once on a hot restart, if the CPU is configured to support hot restart. PCS 7 process cells generally do not use hot restart because the controlled process cannot tolerate the brief freeze of outputs during the restart.
• OB 102 - "Cold restart". Called once on a cold restart. Use this OB to detect the cold restart in your application and - if necessary - re-issue operator commands that the previous cycle had executed.

When the CPU enters OB 102, the work memory already reflects the load-memory values. Any online-modified B_EN, operator commands, or setpoints are gone at this point, and OB 102 cannot recover them. This is exactly the symptom observed after a cold restart: the chart runs, but state that the operator had set online is missing.

Why the B_EN Input on an MB Disappears

The Motor Block (MB) is one of the standard PCS 7 driver blocks from the APL (Advanced Process Library). Its instance DB is generated by CFC and inherits the default Retain attribute from the block type definition. For PCS 7 V7.0 SP3 the relevant facts are:

• APL blocks in PCS 7 V7.0 SP3 ship with Retain = false on their instance DBs unless the developer manually changes the block type and recompiles.
• The B_EN input is a Boolean inside the MB instance DB. After a cold restart the entire DB is reinitialized from the load memory values, so the Boolean returns to whatever value was compiled into the chart.
• PCS 7 operator faceplates write operator commands into the same DB instance (typical fields: OP_EN for enable, MOD_LOC for local/remote, AUT_ON for automatic mode). The same loss applies to any operator command, not only engineering-set inputs.
• If the chart was compiled with B_EN = 1 (block enabled), the cold restart will simply re-enable the motor block - which may look correct but still constitutes a state loss from the operator's perspective. If B_EN was online-disabled for maintenance and then the cold restart re-enables it, that becomes a real safety issue for the affected equipment.

The same rule applies to every other APL block that stores operator-controllable state in its instance DB - VALVE (VL), MOTOR_SPEED (MVS), PID (CTRL_PID), and so on. All of them share the Retain = false default.

Triggering a Cold Restart from the ES or TIA Portal

The remote cold-restart sequence described in the TIA Portal S7 communication manual (S7 communication S7-300/S7-400 - cold restart) is:

1. The ES sends the START function with the restart type COLD_RESTART using S7 communication to the remote S7-400.
2. The target CPU acknowledges the request, performs a complete memory reset, and reinitializes from load memory.
3. When the restart finishes, the CPU changes to RUN and sets the DONE status parameter of the function to 1.
4. A positive execution acknowledgement is returned to the calling ES block.

Once DONE = 1 is observed, all online-modified values from before the restart are guaranteed to be gone. This is the moment at which operators typically notice that B_EN, command bits, setpoints, and tuning parameters have reverted to their last compiled state.

The same operation can be issued locally on the CPU front panel: turn the mode selector to STOP, then back to RUN-P and pull the selector to MRES within three seconds - this issues a memory reset followed by a cold restart.

Practical Effects in a PCS 7 Multi-Project

PCS 7 V7.0 SP3 distributes the project across multiple AS stations, each with its own S7-400 CPU. Online modifications done on one AS do not propagate to the other AS stations. After a cold restart on AS 1, only AS 1 loses its online changes; AS 2 keeps whatever values it had if it was not restarted.

Typical PCS 7 scenarios that trip this issue:

• A commissioning engineer disables a motor block online via the ES to keep it from starting during a test. A cold restart is performed for an unrelated reason. The motor block re-enables and may start unexpectedly.
• An operator changes a setpoint or a tuning parameter from the OS faceplate. A cold restart wipes the change back to the loaded default.
• A recipe setpoint is loaded via the PCS 7 recipe function. Recipes write to a separate data area on the OS server, but if the application then propagates the recipe value into the block instance DB at runtime, the cold restart still wipes the propagated value.
• An interlock is temporarily bypassed by online-forcing a Boolean inside a CFC chart. The cold restart clears the force because the force lives in work memory only.

In all cases the underlying cause is the same: the value lived only in the work-memory copy of the instance DB and was never downloaded back to the load memory.

Backup Battery, Retentive Memory, and Cold Restart Interaction

The retentive memory region on an S7-400 is only useful if the CPU backup battery is healthy. The battery:

• Powers the retentive RAM while the CPU is off so that M, T, C, and retentive DBs survive a power loss.
• Is monitored by the CPU and reports a diagnostic buffer entry ("Backup battery fault") when its voltage drops below threshold.
• Does not protect against a cold restart. A cold restart is an intentional memory wipe; the CPU ignores the retentive image and reloads from load memory.
• Does not protect against an MRES. MRES wipes both work memory and the retentive backup in the same operation.

If the battery has failed and a cold restart is issued, the retentive DBs would have lost their values during the power-down anyway, so the cold restart outcome is no worse. But operators should not interpret a cold restart as a way to "test the retentive DBs". It is the wrong tool for that purpose.

Workarounds to Preserve Parameter Changes Across a Cold Restart

For values that must survive a cold restart, online modify is the wrong tool. The engineering workflow must be one of the following:

1. Recompile and download the chart before issuing the cold restart. In SIMATIC Manager this is CFC > Chart > Compile and Download Objects. After a successful download the new value is in the load memory and the cold restart will load it back into work memory.
2. Mark the DB as Retain on the block type, recompile, and download. This preserves the value across a warm restart and across a brief power cycle, but not across a cold restart - so it is only a partial fix and does not satisfy the requirement that motivated this article.
3. Persist critical parameters in a separate non-volatile store. PCS 7 does not provide this directly, but a custom block can write critical tuning values to the CPU system data area or to a non-volatile memory card slot. Common targets are the recipe / parameter set areas of the PCS 7 OS server.
4. Avoid cold restarts for parameter changes. Use online modify for the parameter, then document the change, and trigger only a warm restart (or a STOP/RUN transition) when the CPU must be restarted. A warm restart does not wipe the load-memory image of the program and preserves retentive data.
5. Use the PCS 7 "Operator-Enabled Parameter Set" feature for setpoint ranges that operators must change. These parameters are saved as part of the OS project and reloaded automatically when the OS reconnects after a CPU restart.
6. Document all online modifications. Before any planned cold restart, capture the current online values from PLC > Monitor/Modify and apply them as new initial values in the CFC chart. After the cold restart, download the updated chart so the values are again in the load memory.
7. Use a custom persistent store block. A simple SCL function block can copy critical parameters from the instance DB into a non-volatile area (a second DB placed in load memory via download, or the system data area) at every value change, and restore them in OB 102. This pattern is commonly used for tuning parameters of PID controllers that operators adjust over weeks.

Verification Procedure After a Cold Restart

1. Open the CFC chart for the affected block in SIMATIC Manager and compare the value against the value you last set online. It should match the compiled value. If it does not, the chart was not recompiled before the cold restart.
2. Open PLC > Monitor/Modify on the instance DB and read the actual runtime value. Compare it against the chart compiled value. Any divergence indicates a chart that was modified online but not re-downloaded.
3. Verify the DONE status of the cold-restart function is 1, confirming the CPU completed the restart per the TIA Portal S7 communication manual referenced above.
4. Check the diagnostic buffer (PLC > Diagnostic Buffer) for entries "Cold restart completed" and "Restart executed by ...". The "Restart executed by" line identifies the source (front-panel selector, ES user, or S7 communication) so you can correlate the event with the maintenance ticket.
5. Confirm that operator-initiated commands on the OS faceplate still respond. If faceplate commands appear "stuck" or in an unexpected state, the instance DB was overwritten by the cold restart and the operator must reissue them.
6. For multi-project PCS 7 cells, repeat the verification on every AS that was restarted. A cold restart is per-AS; one AS losing state does not affect the others.
7. Verify the CPU backup battery diagnostic bit. After a cold restart the diagnostic buffer often includes the battery status; a "Backup battery fault" indicates the retentive image is no longer trustworthy for any future restart.

Troubleshooting Matrix for Parameter Loss After Restart

Frequently Asked Questions