Why a CPU 410-5H REDF Fault Blocks Further Configuration Changes in RUN
Do not ignore REDF to force another hardware change in RUN. Siemens' CPU 410-5H manual requires no redundancy error for system modification during redundant operation and identifies the diagnostic buffer as the place to establish its cause. Continued production does not prove that prerequisite is met. For the reported ET 200SP HA/MRP configuration, the exact firmware and supported recovery or staged-commissioning method remain unresolved.
Table of Contents
- The Documented Prerequisite for Runtime Modification
- Separate the Reported Network State from the Cause
- Inspect Before Attempting Another Download
- Why SFC 12 Is Not an Established Workaround
- Verification
- Limitations and Operational Precautions
- Engineer FAQ
- Technical References
- Related Articles
- Related Tags
The Documented Prerequisite for Runtime Modification
The CPU 410-5H manual explicitly requires no redundancy error for system changes during redundant operation: REDF must not be lit. It directs diagnosis to the diagnostic buffer and warns of automation-system failure if runtime-change rules are violated. CPU manual, section 10.1.
This is a concrete explanation for treating REDF as a modification prerequisite rather than a cosmetic warning. The opened edition is October 2013; the exact current project and firmware applicability still needs confirmation.
Separate the Reported Network State from the Cause
The reported system uses a redundant CPU 410-5H pair, ET 200SP HA and XF204-BA switches with cabinet MRP rings. A newly added but disconnected device, or a maintenance outage, is followed by REDF and blocked subsequent hardware changes.
Continued production in the remaining plant does not establish that every runtime-modification prerequisite is met. Identify which specific redundancy event the CPUs report; do not assume that every REDF condition is an identical missing-device problem.
Inspect Before Attempting Another Download
Use this evidence-first investigation:
- Record both CPU order numbers, actual/configured firmware and PCS 7 version.
- Save both CPUs' diagnostic-buffer entries covering the first REDF event and attempted change.
- Record CPU operating/redundancy states separately from PN-device reachability.
- Compare the configured topology with which ET 200SP HA stations and ring paths are actually available.
- Identify the event that must be restored or the supported staged-commissioning design required for intentionally absent stations.
- Reassess the runtime-change prerequisites using the manual applicable to that firmware before approving another hardware download.
This is a diagnosis and design-review approach. It does not prescribe bypassing the fault or downloading through it.
Why SFC 12 Is Not an Established Workaround
The proposed D_ACT_DP (SFC 12) approach was speculative. The quoted release statement itself restricted the mentioned activation/deactivation capability to stand-alone operation and excluded redundant configuration. That statement was not independently verified from the inaccessible firmware entry.
No supported method is established here for using SFC 12 to retain this redundant system's download capability with missing stations. Deliberately disabling half the H-system would change its availability; it is not an equivalent workaround and is not prescribed.
Verification
A useful recovery record must show the actual redundancy fault, the reviewed corrective action and the restored system state. Verify both CPU diagnostics and intended device/topology availability, not just continued process execution.
Only after the applicable prerequisites are established should an approved configuration-change test verify the intended change and retained redundancy. No hardware download, fault recovery or lab test was performed here.
Limitations and Operational Precautions
PCS 7 and CPU firmware versions are unspecified. The opened historical manual establishes the runtime-change rule, but does not verify this ET 200SP HA/MRP project's specific missing-device behavior or a supported ignore/deactivate procedure.
Keep a restorable hardware/project baseline and review staged commissioning and rollback. Do not suppress REDF, force an unsupported device state or remove CPU redundancy merely to make a download possible. The exact recovery and staged-design solution require technical review.
Engineer FAQ
Does a running process prove another hardware change is permitted? No; inspect the runtime-change prerequisites independently.
Can REDF simply be ignored? The opened manufacturer rule requires no redundancy error for the described operation.
Is SFC 12 verified for this redundant configuration? No; the suggested approach is not established.