Downloading S7 Hardware Configuration in RUN Mode Methods

Downloading S7 Hardware Configuration in RUN Mode: Methods & Limits

The question of whether a Siemens S7-300 or S7-400 CPU can accept a hardware configuration (HW Config) download while the process remains in RUN is one of the most common engineering misconceptions in brownfield modernization. The short, unambiguous answer for a single, non-redundant CPU is no: any change to the central or distributed hardware configuration forces a STOP→STARTUP→RUN transition. The only true path to zero-process-impact hardware configuration changes is a redundant topology — either an S7-400H high-availability system or a Software Redundancy (SWR) pair of S7-300/S7-400 CPUs. This reference covers the underlying reasons, the exact exceptions, the TIA Portal and STEP 7 V5.x procedures that work, and the safety gates that must be implemented when you apply them.

1. Why Hardware Configuration Normally Forces a STOP Transition

When you change the hardware configuration of an S7-300 or S7-400 station, the engineering tool regenerates the system data blocks (SDBs). The CPU's startup routine re-reads the SDBs, rebuilds the hardware object list (HwIo) in work memory, reinitializes the process image partition (PIP) table, and re-runs the module parameter assignment handshake on the backplane bus or on PROFIBUS / PROFINET. None of those steps can occur on a live execution level of OB 1 without breaking the consistency guarantees that OB 35 (cyclic interrupt), OB 40–OB 47 (hardware interrupts), OB 55–OB 57 (DP/PROFINET interrupts), OB 70 (I/O redundancy error), OB 82 (diagnostic interrupt), OB 83 (insert/remove interrupt), OB 85 (program execution error), OB 86 (rack failure), OB 100 (warm restart), OB 101 (hot restart), and OB 102 (cold restart) rely on. Siemens therefore locks the operation: a hardware configuration download is only accepted when the target CPU is in STOP.

Diagnostic buffer entries for a forced STOP caused by a config download are typically in the operating-mode change class (event ID 16#43xx). Reading the buffer via Online > Diagnostics > Diagnostic Buffer in TIA Portal is the first verification step after any such event.

1.1 SDB Container Structure

The SDBs are stored in the load memory of the CPU (MMC for S7-300, integrated or MMC for S7-400). SDB 0 contains the central rack configuration; SDB 1 contains the distributed I/O configuration. Additional SDBs (SDB 2 through SDB 4xxx) hold per-module parameter records. A delta in any of these triggers the rebuild. TIA Portal's "Compile" step regenerates all SDBs; an incremental "Download to device" only transfers the changed SDBs but the CPU still restarts to apply them. The SZL (System State List) partial list 0x0111 (module identification) and 0x0A91 (module status) can be read back online to verify that the new SDB container is in effect after the restart.

2. Standard S7-300: Hardware Configuration Download Restrictions

All S7-300 CPUs — from the entry-level CPU 312 to the flagship CPU 319-3 PN/DP — share the same restriction: a hardware configuration download is rejected if the CPU is in RUN, STARTUP, or HOLD. This applies regardless of whether the change is a new module, a different slot, a re-parameterized analog input range, or a renamed PROFIBUS DP slave.

Workarounds occasionally proposed in field discussions — toggling the mode selector, removing the MMC, or "tricking" the online interface — do not change the result. The CPU performs the SDD (System Data Download) check, sees the configuration delta, and requests STOP. Attempting to download during RUN with the "Download to device" command in TIA Portal results in a dialog stating "The module does not support download in RUN". In legacy STEP 7 V5.x, the equivalent error is logged to the diagnostic buffer with a configuration-error event (16#45xx or 16#49xx range) and the CPU remains in STOP after the failed attempt.

If you need to add a signal module to a running S7-300 station, the supported pattern is: bring the CPU to STOP, perform the download, and execute a warm restart (OB 100) or cold restart (OB 102) — the choice of which OB runs is set in the CPU properties under Startup. Configure Startup when expected/actual configuration differ carefully: Startup only when compatible is the conservative setting for process-critical systems; Startup also when not compatible will accept a new module the CPU has not seen before but can mask genuine configuration errors.

3. Standard S7-400: Hardware Configuration Download Restrictions

S7-400 single CPUs (e.g., CPU 412-2 PN, CPU 414-3 PN/DP, CPU 416-3 PN/DP) are also locked to STOP for any hardware configuration change. S7-400 is faster at the SDD check than S7-300 because of the larger work memory and dedicated firmware path, but the rule is the same: a delta in HW Config means a restart. The diagnostic buffer entry for the STOP is in the operating-mode change class with event ID 16#4300.

The exception begins with the S7-400H family.

4. S7-400H: The Only True Online Hardware Configuration Path on a Siemens PLC

The S7-400H high-availability system uses two redundant CPUs (rack 0 and rack 1) connected by fiber-optic sync modules. One CPU holds the role of master; the other runs in hot-standby with synchronized program execution, memory image, and I/O. The system tolerates the loss of either CPU without interrupting the process — and it is precisely this tolerance that allows one CPU to be put in STOP, reconfigured, and restarted while the other carries the process.

Sync modules are mandatory. The standard 10 m fiber pair is 6ES7 960-1AA04-0XA0; the long-distance variant 6ES7 960-1AB04-0XA0 supports up to 10 km over multi-mode fiber. Both CPUs must be loaded with the same project, same firmware, and the same SDB container version — a mismatch is caught at the first link-up and logged in OB 70 (I/O redundancy error) or OB 72 (CPU redundancy error).

4.1 Procedure to Update Hardware Configuration on a Live S7-400H

1. Verify redundancy health. Open the H-system diagnostic screens and confirm RACK 0 and RACK 1 both show RUN-Redundant. The H-status LED on each CPU must be green. Any of the following states must be resolved first: Solo, Link down, Standby (not synchronized), Update in progress.
2. Open the project in TIA Portal (V16 or later recommended for V8 firmware H-CPUs) and load the modified H-station project. Use Online > Download to device with the Consistent download option enabled. The tool detects the redundancy and offers to download to the standby CPU first.
3. Force a role switch. Click Online > Operating Mode > Switch Master/Standby (or call the SFC 90 "H_CTRL" instruction with CTRL = "MASTER-STANDBY"). The current standby becomes master, the current master becomes standby. The H-system handles the role swap within a single cycle; outputs are unaffected.
4. Download the new HW Config to the now-standby CPU. The download places that CPU in STOP, applies the new SDBs, and the CPU restarts in RUN-Redundant. The active master continues executing without process interruption.
5. Repeat the role switch and download to the new standby (the original master). Confirm both CPUs return to RUN-Redundant and the link-up event is logged with the same firmware version on both.
6. Verify with Online > Diagnostics > Diagnostic Buffer on both CPUs. The expected sequence is: standby download → startup → link-up → redundant sync established. The H-system's redundancy error OBs (OB 70, OB 72) should not have triggered during the procedure; if they did, investigate the sync link and the firmware compatibility matrix.

4.2 Module Replacement Under Power (Hot Swap) on S7-400H Racks

The S7-400H central rack supports module replacement under power via the redundant PS 405 / PS 407 power supplies and the active backplane bus. Both the master and standby racks can be serviced one at a time, and a single H-CPU can be replaced with the system running as long as the other CPU is healthy. Signal modules in the central rack use the S7-400 hot-swap mechanism: pull the failed module, insert the replacement, the surviving CPU detects the module change via OB 83 (insert/remove), and the new module is parameterized from the existing SDB without a CPU restart.

This is module-level hot swap, not a configuration change — the SDB is unchanged; the CPU is re-using the existing configuration against a freshly inserted module of the same type. Adding a module that is not in the SDB is a different operation and is still blocked without a STOP.

5. Software Redundancy (SWR) for S7-300 and S7-400

The Software Redundancy package (order number 6ES7 862-0AC01-0YA0 for SWR V2.0; SWR V3.x is delivered with STEP 7 V5.6+ and is integrated in TIA Portal V16+ for the S7-300/400 target) implements redundancy in software on top of two standard S7-300/S7-400 CPUs that are not necessarily identical to each other but must each be supported. The package adds four libraries: SWRS_CTRL (master/standby handshake), SWRS_SND and SWRS_RCV (DP slave data synchronization), and SWRS_DIAG (diagnostics). The two CPUs exchange their data images and the non-redundant DP slave image over PROFIBUS DP using a dedicated DP connection, so a slave failure on one side does not stop the other.

Unlike S7-400H, SWR does not provide hot-standby execution; the backup CPU is in RUN but only sends a heartbeat, it does not execute the process. When the master fails, the backup takes over within the configured monitoring time (typical: 100–500 ms, set in the SWR configuration). This makes the failover slower than S7-400H (which is in the millisecond range) but is acceptable for non-safety, non-motion processes.

5.1 Updating HW Config on an SWR Pair

1. Confirm the master CPU is the one you want to update first, or force a master/standby role swap through the SWRS_CTRL block. The two CPUs exchange their roles at the next SWR cycle.
2. Download the new HW Config to the standby CPU. As in any single CPU, the download forces a STOP. The running master CPU continues the process.
3. When the standby CPU completes its startup and is again in RUN, verify the SWR link status — the STATUS output of the SWRS_CTRL block must show SYNC_OK or the equivalent per SWR version. The two CPUs re-synchronize their data images.
4. Download the same HW Config to the master CPU. A forced master/standby swap will then take place at the next SWR cycle, and the process sees a brief master transition (sub-millisecond to a few hundred ms depending on monitoring time).
5. Validate in the diagnostic buffer of both CPUs: the SWR OBs (OB 86, OB 87, OB 88) should remain quiet, and the role swap events should be visible in the buffer with the standard "Standby → Master" / "Master → Standby" diagnostic events.

6. TIA Portal: The Download Mechanics

The TIA Portal menu path Online > Download to device is the single entry point for both the initial configuration download and incremental updates. Per the TIA Portal online help (Downloading a configuration to a device), the first download to a target device always transfers the complete hardware configuration. Subsequent downloads can be partial — only the changed objects are transferred — but the CPU still restarts to apply them.

Important operator action: uncheck All in the "Download to device" dialog and check only the items you intend to transfer. Selecting "Hardware configuration" by itself when the user program is unchanged is the correct pattern, and it is the configuration download that the CPU will reject in RUN.

For an S7-400H, the TIA Portal download dialog adds a "Download to both CPUs" option that performs the staggered download described in §4.1. For an SWR pair, the download is performed twice (once to each CPU), with the operator choosing the order to align with the planned role swap.

6.1 STEP 7 V5.x Equivalence

In STEP 7 V5.5 / V5.6, the equivalent menu path is PLC > Download to Target System (German: Zielsystem > Laden). The dialog shows the same delta detection. For S7-400H, the "Download to Target System — H Station" dialog adds the role-swap prompt. The HW Config tool (§3 of SIMATIC Manager) is the offline editor; the online consistency check is invoked before the download proceeds.

7. Hot-Swap Module Replacement vs. Configuration Download

A common confusion in the field is the difference between physically replacing a module that is already in the configuration versus adding a new module to the configuration. The first is supported on several S7-300 and S7-400 modules through the OB 83 mechanism; the second is not.

OB 83 ("Insert/remove module interrupt") must be programmed in the user program. The default response in an S7-300/400 if OB 83 is not present is a CPU STOP — this is the most common reason that "hot swap" attempts fail in the field. Insert the OB 83 (empty or with a diagnostic logging statement), recompile, download to RUN (a software-only change), then attempt the physical replacement.

8. Comparison Matrix: Single CPU vs. S7-400H vs. SWR

The Schneider M580 Hot-Standby (M580HSBY) is referenced here as a cross-vendor comparison only; the engineering procedure is documented in the EcoStruxure Control Expert (Unity Pro) help and the Modicon M580 Hot Standby System Planning Guide, available from the Schneider Electric product documentation portal. The principle is the same: two CPUs, one runs the process, the other is on hot-standby, and the running CPU carries the load while the standby is brought down for a configuration update.

9. Commissioning and Verification Procedure

1. Pre-flight check: confirm the redundant link (fiber for S7-400H, DP/PN cable for SWR) is healthy and the standby CPU is in sync. For S7-400H, the diagnostic buffer on both CPUs must show no pending errors; the redundancy status OBs (OB 70, OB 72) must be empty.
2. Offline simulation: compile the project. TIA Portal's Compile reports SDB errors that would otherwise only surface at the target CPU. STEP 7 V5.x's Station > Check Consistency and PLC > Check Module Identification perform the same function.
3. Download to standby: select the standby CPU, perform the download, verify it restarts to RUN-Redundant (H) or RUN with SWR sync (SWR).
4. Role swap: trigger the master/standby swap, observe the diagnostic buffer event, confirm the process continues without I/O glitches.
5. Download to new standby: repeat the download for the new standby CPU.
6. Final check: confirm both CPUs report identical firmware version, identical SDB container version, and identical project checksum. Use the SZL partial list 0x0019 (H-system identification) and 0x0111 (module identification) to read back the live state.
7. Operator acceptance: have the control room operator sign off on the role swap log and the diagnostic buffer excerpts; archive these in the project change log.

10. Safety and Process Protection Considerations

Even when the topology allows a zero-process-impact HW config update, treat every such change as a "near-live" maintenance window. Specific points:

• Make sure the process area is informed and operators are aware that outputs may briefly transition during the role swap, even though the process should continue.
• Disable any forced outputs or override conditions in the active CPU before the role swap. The S7-400H role swap does not preserve "force" states — a forced output on the master that is not forced on the standby will revert to the program value on swap.
• For SWR pairs, the monitoring time setting is the worst-case process latency on a master failure. A value of 100 ms is typical; below 50 ms risks spurious swaps from network jitter, above 500 ms risks unacceptable process lag on a real failure.
• Document the new SDB version (read it via the CPU's online diagnostics, "System data" tab). This is the audit trail for the change.
• For functional safety systems (F-CPU in S7-300F / S7-400F / S7-1500F), no online HW config change is permitted in RUN even on a redundant F-system. Bring the F-CPU to STOP and follow the safety acceptance test procedure for the change.
• For PROFIsafe slaves (F-modules in ET 200M / ET 200SP / ET 200pro), parameter changes require a re-acceptance test; staggered HW config updates on an H-system still trigger PROFIsafe re-parameterization, which forces a re-integration of the F-slave with the F-host's CRC checks.

11. Troubleshooting Matrix

12. Common Project Engineering Mistakes

1. Assuming a CPU "supports" online HW config downloads — the S7-300/400 firmware has no such option; the only way to change configuration in RUN is through the redundant topology mechanisms above.
2. Mismatched module order numbers in HW Config vs. installed module — a typo in the catalog number (e.g., 6ES7 331-7KF02 vs. 6ES7 331-1KF02) triggers a download-time configuration error even on a single CPU in STOP.
3. OB 83 forgotten after the first hot-swap module was added — the OB exists in the offline project but is not in the CPU's load memory because it was never downloaded; or it was downloaded once and a later program change removed it.
4. Substitute value strategy not defined — an S7-300/400 in STOP defaults to output = 0, which can drive actuators to unsafe positions. For a hydraulic valve, "0" might mean "open"; for an ESD solenoid, "0" might mean "trip".
5. S7-400H firmware mismatch across the pair — after a TIA Portal upgrade, one CPU may receive a firmware update via the download while the other is still on the old version. The link-up will fail. Resolve by performing the firmware update on the standby first, then the master, and only then loading the new HW Config.
6. SWR monitoring time set below 50 ms — network jitter from a busy PROFIBUS segment causes spurious role swaps, which can be worse than a process stop.
7. Ignoring PROFIsafe re-parameterization — a staggered HW Config update on an H-system that includes F-slaves will force the F-host to re-integrate each F-slave. This re-integration is logged in the F-host's diagnostic buffer; operators may misinterpret the F-host's standard "F-integration in progress" event as a fault.

13. Cycle Time and Memory Implications

An S7-400H dual-CPU setup doubles the user program execution path in terms of compile-time validation, even though the redundant CPU does not actively execute OB 1 in parallel — it executes a cyclic "shadow" image used for the link-up comparison. This adds 10–20% to the OB 1 scan time in well-engineered systems. S7-300 SWR pairs add a smaller overhead (1–5%) because the standby CPU only runs the SWR synchronization OBs and a heartbeat.

Memory budget: an S7-400H station with the redundant configuration requires two SDB containers, two of every user block loaded, and the H-system library (H-system firmware blocks). Plan a 30–40% increase in load memory compared to a single S7-400 station. For SWR, the SWR library blocks add about 200 KB to the load memory of each CPU.