Modifying S7-FH Standard User Program Without CFC Source Charts

Problem Definition: Editing an S7-FH Standard User Program Without CFC Source Charts

• Will a download of a modified standard block force the CPU into STOP?
• Does the change require the (unavailable) charts to be downloaded as well?
• Is the safety program affected, and will a re-certification be necessary?
• What is the right order of operations on a redundant H-system, and what happens if the H-link is marginal?

This article works through the engineering decisions and the concrete download behavior, drawing on the S7-FH / SIMATIC Safety documentation and the specific Siemens Support record that addresses STOP-mode download on F-CPUs.

S7-FH System Architecture and the Standard/Safety Program Split

The S7-FH designation covers the fail-safe high-availability SIMATIC S7-400 family — typically a CPU 414FH or CPU 417FH in H-mode with two synchronized rack pairs. The F-functionality is built on top of the standard CPU by an additional F-runtime group executed in fixed time slices, with a separate F-shared DB, F-instances, and a fail-safe signature. The same architectural split exists on the newer F-CPUs of the S7-1200F and S7-1500F families (CPU 1212FC, 1214FC, 1215FC, 1217FC, 1510F through 1519F), where the standard user program and the safety program share the same CPU but live in different runtime contexts with strictly controlled data exchange.

Two address spaces matter for every download decision:

• Standard user program — OBs (OB1, OB32–OB38, OB82, OB100, OB121), standard FBs/FCs/DBs, SFBs/SFCs, instance DBs, and any imported type-FBs used in the standard chart context. These are compiled by STEP 7 / TIA Portal from FBD/LAD/STL/SCL or imported into CFC charts. There is no signature and no safety implication; the runtime behavior of a single-block download is governed purely by STEP 7's standard download rules.
• Safety program — F-OB, F-runtime group, F-shared DB, F-FB, F-FC, F-I/O DBs, F-block container, and the F-signature. Changes here always go through the F-system compile-and-download path and require the F-CPU password plus a fresh collective F-signature before the safety program is accepted.

Editing the standard user program is the lower-risk case because the safety program and its F-signature remain untouched. The remaining risk is operational: forcing the CPU into STOP during a download, and on an H-system, the risk of breaking redundancy or leaving a partner CPU with an inconsistent block set.

Why a Downloaded Backup Loses Editable Information

The STEP 7 / TIA Portal Upload to PG function reconstructs the symbol table and the block code of the standard user program, but it discards a number of design-time artifacts that the original project carried. Knowing exactly what is lost is the first step in deciding whether the backup is even editable:

• Comments, network titles, and the symbol table are partial at best; cross-references to charts are gone. S7-FH installations frequently use PCS 7 symbol tables that are not committed to the upload.
• Blocks originally written in SCL upload as compiled STL with no SCL source, so any later edit must be in STL or FBD after a manual decompilation step.
• CFC charts are not recovered from an upload; the engineer sees the compiled chart-instances inside the runtime blocks but not the chart itself. The runtime block contains the chart's flattened network structure without the run-order, the chart-level parameters, or the inter-chart signal routing.
• Blocks that were imported into CFC as type-FB instances are sometimes converted during upload in ways that prevent re-editing. The instance is collapsed into a call to a generated FC whose body is not editable in the offline editor.

The practical effect is that you may be able to view a block, identify the network that needs changing, and re-write it in FBD/STL, but you cannot rely on the backup to be a full re-buildable project. This is why field practice on S7-FH almost always re-creates the project from the original archive (or re-commissions from scratch) before doing anything non-trivial.

CPU State on Download: RUN, RUN with STOP, or Forced STOP

The decisive question is whether the download requires STOP. The answer is a function of the change type, the project type (PCS 7 vs. plain STEP 7), and the F-CPU's safety editor session state. There are three cases that cover the vast majority of field situations:

For an H-system running in redundant mode, the partner CPU takes over cleanly during the brief STOP. In solo mode, the process goes down for the duration of the download. The reason S7-FH systems tolerate this better than S7-300 / S7-400 standard systems is that the H-link is preserved across a STOP/RUN cycle; the partner re-syncs the failed CPU on return without dropping the fieldbus connection to PROFIsafe slaves.

Step-by-Step Block-Level Modification Workflow

1. Take a fresh full upload from both H-CPUs to a new offline project; do not overwrite the existing backup. The two uploads are the only authoritative record of the live program.
2. Compare the two partner CPUs block-by-block in the offline program editor. Any mismatch (time stamp, checksum) indicates a residual inconsistency that must be resolved before any download.
3. Switch the offline project's Use property to STEP 7 only if the project is a PCS 7 master project. Otherwise, leave it as PCS 7 and work through the chart-aware download path.
4. Open the target block in the FBD or STL editor. Add the new logic in a clearly marked network (e.g., // ED: change request 2024-XX, ticket #...) so the edit is auditable in the safety lifecycle file.
5. Save and compile. In STEP 7 V5.x choose Save and Compile with Debug → Check Block Consistency before going online. The check must report zero errors and zero warnings on F-blocks.
6. Download to PLCSIM first. Put the simulated CPU in RUN, modify the block, and confirm the CPU remains in RUN after the download. If the simulator forces a STOP, the change is structural and will also stop the real H-CPU.
7. On the real H-system, switch the standby CPU to solo mode via the H-system operator panel, leaving the master in RUN.
8. Download the modified block to the standby CPU. Verify the standby CPU goes to RUN with the new logic active and that the standby accepts redundancy again.
9. Switch the roles (master → standby) and repeat the download on the now-standby partner.
10. Return the system to redundant mode and re-verify the safety program signature has not changed.

Validating Changes in PLCSIM and H-CPU Solo Mode

PLCSIM reproduces the S7-400FH download behavior with one important caveat: PLCSIM does not enforce PROFIsafe wire-break, F-I/O diagnostics, or the F-CPU's F-signature, so a passing PLCSIM test does not prove the F-system is healthy. It only proves that the standard user program change is internally consistent and that the download is structurally accepted. Use PLCSIM as a structural filter, not as a functional proof.

On the real H-system, the H-CPU operator panel exposes the following states: redundant (RUN-RUN), solo (RUN-STOP), update, link-down, and failure. A block download is always initiated against one specific CPU; the partner is unaffected. After a successful download, the standby CPU is forced to a re-sync cycle that is visible in the diagnostic buffer with specific event IDs:

For S7-1500F systems the equivalent diagnostic entries are surfaced as native TIA Portal events in the online diagnostics view rather than as raw hex IDs, but the meaning is the same: link-up, link-down, resync, and F-stop.

H-System Specific Risks: Redundancy, RAM/Flash, and Link Loss

An S7-400FH can be loaded with the user program either in the internal Flash or on the memory card (RAM external). The Flash is the persistent image; the RAM is the working copy. The H-CPU keeps the two partner RAMs synchronized at runtime, and a download patches the working copy on the target CPU. If the CPU is in Save to Flash on every download mode, a power failure during the write can brick the persistent image. Field practice is to disable auto-save, perform the download in solo mode, and then issue an explicit Save to Memory Card from the operator panel once the change is verified.

Three risks in particular have to be acknowledged before any download on the live system:

1. Link loss during a download. The H-link is briefly interrupted when the standby CPU goes STOP-RUN. If the link is already marginal (aged fiber, dirty connector, EMI), the resync can fail with W#16#5922.
2. Partner mismatch after partial download. If you only download to one CPU and forget the second, the partner's program stays at the old revision and the next STOP-RUN will re-load the older blocks from the partner, silently undoing the change.
3. F-signature confusion. Never include the F-CPU's signature in the standard user program download. The F-signature is computed and re-issued only by the F-system compile path. If a standard download overwrites the F-block container by mistake, the F-CPU raises a signature mismatch on the next safety pass.

On a multiuser TIA Portal project, an additional risk applies: a colleague's safety editor session can hold a lock on the F-block container, and the compile path will refuse to rebuild. Resolve the lock by closing the safety session (or by checking the F-shared DB in the editor) before initiating the standard-program download.

Reverse-Engineering STL to CFC or FBD

If the engineering decision is to live with the uploaded backup and re-build the standard user program, the only realistic approach is to convert the uploaded STL back to FBD network-by-network. Tools such as the STEP 7 Source from Blocks function and reverse-engineering utilities are limited; they will not recover variable names, comments, or chart structure. The engineer is effectively re-drawing the chart by hand from the compiled code. The contributors to the original engineering discussion described this as a multi-week task even on a 6-machine fleet, and one that typically also forces the safety program to be re-built and re-certified.

For each FC / FB in the upload, the practical sequence is:

1. Print the STL with cross-references enabled (Options → Cross-References in STEP 7 V5.x).
2. Walk the call hierarchy from OB1 down, network by network. Mark every FB call site, every multi-instance, and every shared DB access.
3. For each FB call, determine the instance DB and reconstruct the multi-instance structure. Pay particular attention to the FBs' IN/OUT/STAT/TEMP block interface — the upload usually preserves it but may rename the symbols.
4. Re-draw the network in FBD on a fresh CFC/SFC chart in a new PCS 7 master project. Preserve the original run-order by re-creating the chart's sequence and the inter-chart signal routing.
5. Compile, check block consistency, and re-run the PLCSIM validation loop before touching the real H-CPU.

Two failure modes are common in this reverse-engineering work. The first is silently dropping a multi-instance — the resulting chart compiles and even runs, but the next safety pass fails because the F-shared DB sees an unexpected value pattern. The second is mis-typing an instance DB number, which the F-system accepts as a separate instance and then complains about at the first cross-check. Treat the re-build as a re-commissioning project, not a hot-fix.

Data Exchange Between Standard User Program and Safety Program

If the goal of editing the standard user program is to feed new values into the safety program, the data must be written into the F-shared DB or into an F-FB's standard input. Per the SIMATIC Safety documentation, a tag from the standard user program cannot simply be read inside the safety program; it has to be transferred through a controlled mechanism. The TIA Portal V20 documentation on data exchange describes the path explicitly and warns that there is not a simple way to check the validity of the standard tags from the safety program side.

The reference design pattern is:

1. In the standard program, write the value to a tag that the safety program reads through the F-shared DB interface or through a dedicated F-FB input.
2. In the safety program, treat the value as untrusted and validate it (range check, plausibility, time stamp, two-channel disagreement if the value is also acquired by an F-I/O).
3. Route the validated value into the F-runtime group via the F-FB input. Direct access to a standard DB from within an F-FB is not allowed and is rejected by the F-system compile path with the diagnostic message "Access to non-safety DB from F-FB not permitted".

The reverse direction — a safety tag made visible to the standard program — is supported via the F-shared DB's output area. The standard program reads the output as a normal DB tag without any F-implication. This is the standard mechanism used to surface safety state (e.g., an OK flag, an emergency-stop bit) to the HMI and to the standard control logic.

Safety Re-Certification: When Editing Forces a Re-Validation

Editing the standard user program alone does not invalidate the F-signature or the F-CPU's safety acceptance test. However, three side effects can force a re-certification:

• The edited standard block calls an F-block whose interface has been changed — the F-block must be re-compiled and the F-signature regenerated. The acceptance test of every safety function that consumes that F-block must be re-run.
• The edited standard block writes a value that the safety program reads — the safety program's validation logic (range, plausibility, time stamp) must be re-validated against the new value range, and the safety lifecycle documentation must be updated to record the new dependency.
• The change touches a process value that is part of a safety function (e.g., a process interlock that was historically implemented in the standard program). Per IEC 61508 / IEC 61511, the safety function is no longer implemented as documented and a full re-validation against the Safety Requirement Specification is required.

Document the change, the rationale, and the validation evidence in the safety lifecycle file, even if the F-signature itself is unchanged. The TIA Portal Safety Administration view generates a change log that can be exported as a PDF and appended to the safety file; the STEP 7 V5.x equivalent is the Change Log printout from the safety program editor.

Multiuser / TIA Portal: Why STOP Becomes Mandatory

The Siemens Support entry 109761403 addresses a specific question that has tripped up every TIA Portal team that maintains a fail-safe system: why does a change in the standard user program force a STOP-mode download on an F-CPU? The answer is structural: in a multiuser project, the safety editor session and the standard editor session are separate compilation units. When the standard program is recompiled (for any reason — even a comment change in a non-F block), the safety editor must re-validate the F-block container against the new compilation. The F-CPU refuses the resulting collective download in RUN mode and forces a STOP.

Practical mitigations:

• Use a single-editor workflow for any change that touches the standard user program on a project with an active safety editor session. Save the standard program in the safety editor's project tree, not in a separate standard tree.
• Use the Compile button in the safety editor (not the standard editor) to rebuild both halves. This produces a consistent collective download that the F-CPU accepts in STOP mode.
• Schedule all multiuser standard-program changes for a planned outage on F-CPU projects. The STOP duration is short (single-digit seconds for a typical F-block container) but the process implications are not.

Alternatives: Re-Programming From Source vs. Risky Field Edits

The two paths identified in the original engineering discussion have very different cost / risk profiles:

If the client accepts the second path, it is almost always cheaper in the long run than a series of small risky edits, because every edit on the live system carries the same operational risk as the first, and the audit trail of "hot-fix" edits is what the safety reviewer will scrutinize first. Use the hot-fix path only when the process is genuinely one-off and the re-commissioning cost is disproportionate to the change.

Verification Checklist and Field-Proven Caveats

Field-proven caveats to keep in mind:

• Never edit a block that was generated by an SCL source unless the SCL source is also re-imported; the next compile will silently overwrite the STL.
• Never include the F-shared DB or any F-I/O DB in a standard download; the F-system has its own compile path and a standard download of these blocks is rejected at compile time, but a copy-paste error in the block list can still pull them in.
• On an H-system, Save to Memory Card is a separate, blocking operation. Do not chain it with a download — the H-CPU pauses its runtime during the flash write and the PROFIsafe watchdog can trip on the slower partner.
• If the only backup is the uploaded one, treat the project as read-only and document every edit as a re-build rather than a hot-fix. The safety reviewer will read your safety log, and a "hot-fix" entry without a corresponding source revision is a red flag.
• When editing in FBD, preserve the network number ordering. The runtime block's compiled code is order-dependent and the F-system's cross-check on a multi-instance compares compiled code byte-by-byte; a re-ordered network produces a different CRC and a false signature mismatch.

FAQ