Renumbering PCS7 Function Blocks Across CFC Charts in a Multi-Project

Migrating the FB number of a custom block used throughout a PCS 7 multi-project is a routine but high-risk maintenance task. A single missed symbolic reference, indirect call, or block icon binding can halt an Automation Station at startup or produce a runtime fault that is invisible until a process disturbance exercises the affected path. This reference documents the engineering procedure, the pre-migration risk analysis, and the verification steps required to renumber an FB (for example, FB600 to FB650) inside a SIMATIC PCS 7 V9.x project without an unscheduled process stop.

1. Background: FB Numbering in PCS 7 and Why It Changes

SIMATIC PCS 7 stores compiled S7 blocks in the S7 program of each AS. The block number (the numeric range, e.g., FB600) is the absolute address the CPU uses at runtime; the symbolic name is the alias visible in CFC, SCL, and the symbol table. The two views are linked, but the CPU executes against the absolute number. When the engineer renumbers the block, the symbolic table entry must move in lockstep with the block folder, otherwise the download will produce a "Block not found" or "Symbol resolution failed" fault at the next CPU restart or CFC online update.

PCS 7 V9.0 SPx, V9.1, and V9.2 all behave identically for the purposes of this procedure. Earlier V8.x versions use the same mechanism but a different MDL synchronization path (menu Options → Master Data Library → Synchronize in older releases). The multi-project contains a single AS and a single MDL, which is the simplest topology but is still subject to the same cross-reference analysis that protects more complex plants.

1.1 Block Family Categories Affected

1.2 Why the FB Number Matters at Runtime

At AS startup, the OB100 (restart) and OB101 (hot restart) populate the instance DB references by reading the FB number from the system data. If the block folder contains FB650 but the symbol table still resolves MY_MOTOR_CTRL to FB600, the CFC runtime will either:

• Issue a CPU diagnostic buffer entry: "Block FB600 not found, block FB650 loaded" with SF (system fault) LED on, or
• Pass the instance DB to a wrong block family, producing unpredictable I/O behavior on the next scan.

Both symptoms are preventable with the cross-reference sweep described in Section 3.

2. Prerequisites

Verify the following before touching the project:

1. Project backup: Archive the entire multi-project (right-click project → Archive). Use a timestamped name (for example, PlantX_2024-05-12_preFBrenumber.zip) and store on a network path disconnected from the live engineering workflow.
2. Engineering license: The ES must have a valid PCS 7 engineering license with the CFC option package installed. License verification is at Siemens Support Entry 109751628 (PCS 7 licensing overview).
3. Offline parity: The S7 program on the ES must match the AS (no pending deltas). Check via PLC → Compare Online/Offline. Any difference must be downloaded or discarded first; otherwise the renumbering delta is mixed with a prior unsynchronized change.
4. CPU operating mode: The target AS must be in RUN-P or at minimum RUN with a writable configuration. Some PCS 7 blocks (those using know-how protection or vendor-signed blocks) cannot be overwritten online; a stop is required for the initial download after renumbering.
5. Operator Station (OS) server: The OS picks up the renumbered block automatically through the WinCC variable reconciliation that runs at OS startup. The OS does not need to be stopped, but the OS process image (picture tree, faceplate bindings) must be regenerated in the next OS compile cycle (Section 6.3).
6. Cross-reference index: Build a fresh cross-reference via Options → Cross-References → Generate. The cross-reference index is consumed by the indirect-call search in Section 3.2.

3. Risk Analysis: Direct, Indirect, and Bound References

The success of a renumbering action depends on identifying every call site. There are three categories of references that an engineer must audit:

3.1 Direct Symbolic Calls in CFC

The simplest case. The CFC chart contains a block instance named MOTOR_1 of type MY_MOTOR_CTRL (FB600). The chart's I/O reference is the symbolic name, not the absolute number. Renumbering the block folder entry and the symbol table entry is sufficient; the CFC does not need to be edited.

3.2 Indirect Calls (Absolute FB Number in a Variable)

An indirect call passes the FB number through a data word, typically used in equipment module (EM) or unit (UE) supervisory patterns. The CFC source contains statements such as:

CALL #FB_PTR   // WORD or INT, e.g., 600
     FB_NUMBER :=#FB_PTR
     INSTANCE  :=#MOTOR_DB

When the FB number is hard-coded as a constant, the engineer must search the source manually. The constant 600 may appear as:

• Decimal literal: 600
• Hex literal: W#16#258 (0x258 = 600 decimal)
• BCD: B#(2,5,8) (rare but present in some legacy blocks)

Each variant must be detected and updated. The cross-reference tool indexes the symbol table and the S7 program source, but does not parse indirect parameter lists. A manual grep across the S7 sources is the correct defensive action.

3.3 Bound References (OS Faceplates, SFC, WinCC Archives)

The OS faceplate designer generates a structural reference to the block's I/O at OS compile time. The binding survives the AS download but the OS compile must be re-executed for the new block number to take effect. The SFC (Sequential Function Chart) compiler also produces a transition/step reference to the FB number. Both require regeneration.

4. Pre-Migration Cross-Reference Procedure

Execute the following steps in the order shown. Do not skip the cross-reference even if the engineer "knows" the block is only used in CFCs; empirical evidence in the field shows that hidden indirect calls appear in 10–15% of multi-project audits.

4.1 Generate the Cross-Reference

1. Open the S7 program of the AS in the SIMATIC Manager.
2. Select the program node, then Options → Cross-References → Generate.
3. Wait for the index to complete (1–5 minutes depending on program size).
4. Right-click the FB in the block folder and select Cross-Reference Information.

The resulting table lists every symbol that resolves to FB600, grouped by location: CFC chart, SCL source, instance DB reference, and OS variable. Export to CSV for offline review.

4.2 Search for Indirect Calls

Open the S7 sources folder in the SIMATIC Manager. Use Edit → Find and Replace with the following patterns, one at a time:

Pattern 1: CALL FB{6,0,0}      // decimal
Pattern 2: W#16#258                // hex equivalent
Pattern 3: 600                     // bare literal in any context

For the bare literal, review every hit. The number 600 is ambiguous (it could be a setpoint, a sample count, or a motor speed in RPM); confirm each hit is an FB number reference before changing it. Replace the verified hits with 650 (or the new target number), recompile the SCL source, and re-export the cross-reference.

4.3 Validate the Master Data Library

The MDL holds the type definition of the block. If the type is updated in the MDL, every instance in the AS is updated atomically during the next CFC compile. Verify:

• Open the MDL in the SIMATIC Manager.
• Locate the block type in Blocks → FB-types or Sources.
• Confirm the type version number is consistent with the version in the AS block folder.
• Check Options → Charts → Type Updates for pending type-instance reconciliations.

If the MDL contains a stale version of the type, propagate it via Options → Master Data Library → Synchronize with Project. This step is not strictly required for renumbering (the FB number is in the type's container, not the type's source), but is best practice before any mass update.

5. Renumbering Procedure

The procedure is identical for type blocks and stand-alone instance FBs. The engineer renumbers in three steps: symbolic table, block folder, and CFC recompile.

5.1 Update the Symbol Table

1. Open S7 Program → Symbols in the SIMATIC Manager.
2. Locate the row where Symbol = MY_MOTOR_CTRL and Address = FB 600.
3. Change the address to FB 650. Do not modify the symbolic name.
4. Save and close the symbol table. The change propagates to all consumer views in the project.

5.2 Renumber the Block in the Block Folder

Two methods are available; use method A for clarity and reproducibility.

Method A: Cut and Paste with Renumbering

1. Open the block folder of the AS S7 program.
2. Right-click the FB (e.g., FB600), select Rename.
3. Change the number to 650. Confirm the prompt that warns about dependent symbols.
4. The block is now FB650 in the block folder. The associated instance DBs (e.g., DB600) must be renamed as well if the engineer follows the PCS 7 convention of matching DB number to FB number. To rename a DB, right-click and select Rename.

Method B: Delete and Re-import

1. Delete the FB (and matching instance DB) from the block folder. Confirm the cascade prompt.
2. Open the S7 source of the block (in the S7 program → Sources folder), edit the FUNCTION_BLOCK FB600 declaration to FUNCTION_BLOCK FB650.
3. Recompile the source. The block is regenerated as FB650 with a fresh timestamp.

Method B is preferred when the engineer also wants to make code changes; method A is faster for number-only renames.

5.3 Update Instance DB References

If the engineer chooses to keep the DB numbers (e.g., DB600) unchanged, no action is required beyond the FB rename. If the DB numbers are also being migrated (e.g., DB600 to DB650), execute Rename on each instance DB. The CFC charts contain the symbolic name of the instance DB, so the binding survives, but verify by re-opening the CFC and inspecting the block header (right-click the block → Block Properties) to confirm the new instance DB number is displayed.

5.4 Recompile the CFC Charts

1. Select the AS in the plant view.
2. Right-click → Charts → Compile.
3. In the compile dialog, set the scope to Entire program and the target to Offline S7 Program.
4. Enable the option Generate all blocks (full regeneration) rather than incremental. This forces every chart to rebuild its block instance map and detect any unresolved symbol.
5. Click Compile. The compile log must complete with zero errors and zero warnings. Treat any warning as a hard failure until investigated.

The full-regeneration option is slower but eliminates the residual reference cases that incremental compiles can mask. For a project with a single AS, full regeneration typically completes in under five minutes.

6. Download to the Automation Station

6.1 Determine Online vs Stop-and-Load

For a pure FB number renumber with no code or interface change, the CPU typically allows an online download without stopping. The instance DBs are preserved because their absolute number is unchanged. If the engineer also renamed the instance DBs, the download requires Initialize instance DB enabled, which resets the process state to the initial values declared in the FB source.

6.2 Online Download Procedure

1. Right-click the AS → Download.
2. Select Entire program to target device if the engineer wants a clean load. Alternatively, select Changes only for a delta download (faster, requires the same prerequisites as Section 6.1).
3. In the download dialog, set Initialize instance DBs per the case in Section 6.1.
4. Confirm the prompt that asks for block overwrite authorization.
5. Monitor the online progress; a successful download produces a green status bar and a CPU RUN state.

6.3 OS Recompile and Reload

After the AS download, recompile the OS to refresh the faceplate bindings:

1. Open the OS server project in WinCC Explorer.
2. Select OS Project Editor → Compile OS.
3. In the compile dialog, set Scope to Complete and Scope of picture compilation to Complete.
4. Execute the compile. The OS compile regenerates the picture tree, the faceplate DLLs, and the alarm/message configuration.
5. Perform an OS delta download (or full download) to push the new bindings to the runtime OS.

The OS step can be deferred to the next planned OS maintenance window if the process does not exercise the affected block's faceplate in the immediate term. However, the engineer should not defer indefinitely: a stale OS binding can produce a yellow "variable not connected" triangle in the faceplate the first time an operator opens the affected equipment.

7. Verification and Commissioning

Verification is a multi-stage procedure that exercises the migrated block on the live AS before the engineer declares the migration complete.

7.1 Online Comparison

Open PLC → Compare Online/Offline. The result must show zero differences for the renamed FB and the affected instance DBs. A non-zero difference indicates that the offline block folder is out of sync with the AS — a condition that should never persist in a healthy project.

7.2 Monitor the CPU Diagnostic Buffer

Open the online diagnostic buffer (right-click the AS → PLC → Diagnostic Buffer). The post-download buffer must contain:

• OB100 restart entries (if the CPU went through a stop-run cycle)
• No "Block not found" entries
• No "I/O access error" entries
• No SF (system fault) events

If any fault is present, the migration has a residual reference that the cross-reference sweep missed. Execute the rollback procedure in Section 8 immediately.

7.3 Function Test in Test Mode

PCS 7 supports a Test Mode on CFC charts that allows the engineer to toggle block inputs and observe outputs without modifying the live process. Activate test mode on the affected chart:

1. Open the CFC chart in the online view.
2. Right-click the block → Test Mode → On.
3. Toggle the enable input from 0 to 1; verify the corresponding output transitions in the VAT (Variable Table).
4. Toggle the fault simulation input; verify the alarm is raised in the OS message system.

The test must cover at least the following cases for the renamed block:

7.4 Long-Duration Soak Test

For blocks that participate in closed-loop control (PID, motor speed, valve positioning), execute a 24-hour soak test. Verify the process is stable and the OS archives are writing without gap. The PCS 7 OS maintains a Tag Logging Slow and Tag Logging Fast archive; the renamed block's tags must appear in both.

8. Rollback Procedure

The engineer must be able to revert the migration in a single work shift if verification fails. The rollback uses the project archive from Section 2.1.

1. Stop any ongoing process that depends on the renamed block. Coordinate with operations to bring the affected unit to a safe state.
2. De-archive the project from the timestamped backup.
3. Open the restored project, perform PLC → Download with the entire program scope.
4. Restart the CPU in the standard restart mode (cold or warm, per the plant's normal procedure).
5. Verify the diagnostic buffer is clean and the OS faceplate shows the expected state.
6. Resume the process.

The downtime required for a full project restore and download depends on the AS scan load and the size of the S7 program. For a single-AS project with a moderate S7 program (5,000–15,000 blocks), a full restore and download completes in 20–45 minutes.

9. Edge Cases and Field-Proven Pitfalls

9.1 The 600-to-650 Hex Mismatch

A common error is to search for the decimal literal only. As noted in Section 3.2, the same value can appear as W#16#258 (hex), DW#16#00000258 (DWord hex), or B#16#02, B#16#58 (byte pair). The cross-reference tool does not normalize these representations. Use a regex pattern or a hex-aware search:

Search all S7 sources and all SCL files. The PCS 7 standard library uses a similar pattern internally, so false positives are expected and must be filtered manually.

9.2 SFC Transition Implicit Calls

SFC transitions can call the FB by absolute number in a generated SCL source. The SFC compile step hides this call from the CFC view. After the FB renumbering, re-compile the SFC charts:

1. Select the AS in the plant view.
2. Right-click → Charts → Compile SFC.
3. Verify the SFC compile log for any "old block number" reference.

9.3 The Block Icon View Designer

The OS uses a WinCC picture window with a block icon. The icon's tag prefix is built from the block's symbolic name and the instance DB's number. If the DB number changed (e.g., DB600 to DB650), the OS compile regenerates the icon correctly. If the engineer only changed the FB number, the icon is unchanged and no OS action is required beyond a delta download for safety.

9.4 Know-How Protection

Blocks from a third-party library (e.g., a vendor's actuator controller) are know-how protected. Renumbering is not possible without the vendor's source. The vendor must provide a migration tool or the engineer must leave the block in its original FB number range. PCS 7 standard driver blocks (CH_AI, MOT_SPEED, etc.) are not know-how protected but are versioned; always use the version that matches the PCS 7 release line.

9.5 Multi-Instance Block Containers

If the FB600 contains a multi-instance of another FB (FB500) as a static variable, the renumbering must propagate to the instance declaration. The SCL source for the FB must be edited; the renumbering is not contained to the block folder. Example:

FUNCTION_BLOCK FB650
VAR
    INNER_CTRL : FB500;  // multi-instance of FB500
END_VAR
BEGIN
    INNER_CTRL(EN := TRUE, ...);
END_FUNCTION_BLOCK

Renumbering the outer FB from 600 to 650 does not affect the inner FB500, but the engineer must verify that the inner block is not also being migrated in the same change set. Concurrent renames must be ordered: inner blocks first, outer blocks second.

10. Automation and Scripting

For multi-project migrations involving dozens of FBs, the engineer can use the PCS 7 Automation Interface (C#/VB.NET) to script the renumbering. The relevant API surface is in the SIMATIC PCS 7 Automation Interface documentation at Siemens Industry Online Support. The high-level steps in code are:

// 1. Open the project
var project = Process.OpenProject("C:\\PlantX\\PlantX.s7p");

// 2. Locate the block
var blockFolder = project.AS[1].S7Program.Blocks;
var fb600 = blockFolder.Find("FB600");

// 3. Read the block content
var blockContent = fb600.Read();

// 4. Delete the old block
blockFolder.Delete("FB600");

// 5. Create the new block with new number
var fb650 = blockFolder.Create("FB650");
fb650.Write(blockContent);

// 6. Update the symbol table
var symbolTable = project.AS[1].S7Program.SymbolTable;
symbolTable.SetAddress("MY_MOTOR_CTRL", "FB 650");

// 7. Recompile and download
project.AS[1].Compile();
project.AS[1].Download();

The automation interface reduces the manual error rate for large migrations, but does not replace the cross-reference sweep — the script will not detect indirect calls that the engineer did not pre-document.

11. Standards and References

The following Siemens documentation applies to FB renumbering in PCS 7 V9.x:

• SIMATIC PCS 7 V9.1 documentation portal
• PCS 7 CFC Programming Manual
• PCS 7 SFC Programming Manual
• PCS 7 Master Data Library Configuration

Verify the documentation revision matches the PCS 7 release installed on the ES. The principles described in this reference are stable across V8.2, V9.0, V9.1, and V9.2, but specific menu paths and dialog options may differ between releases.

12. Quick-Reference Checklist

Use the following checklist on the day of the migration:

1. [ ] Project archive completed and verified
2. [ ] Cross-reference generated and exported to CSV
3. [ ] Indirect call search executed (decimal, hex, byte-pair)
4. [ ] MDL type version verified
5. [ ] Symbol table updated (FB600 → FB650)
6. [ ] Block folder entry renamed (FB600 → FB650)
7. [ ] Instance DB rename decision made (keep or change)
8. [ ] CFC charts recompiled (full regeneration, no warnings)
9. [ ] SFC charts recompiled
10. [ ] AS download completed (online or stop, as required)
11. [ ] Diagnostic buffer verified clean
12. [ ] Online/offline comparison verified zero delta
13. [ ] Test mode exercised on affected chart
14. [ ] OS compile and delta download completed
15. [ ] 24-hour soak test scheduled
16. [ ] Rollback path tested on engineering workstation

A complete checklist execution for a single-AS project with one renamed FB takes 90–120 minutes of focused engineering time, excluding the 24-hour soak test.