Managing Variable Renaming and Interconnection Updates for User DBs in PCS 7 CFC

In SIMATIC PCS 7, modifying variable names inside a user-defined Data Block (e.g., DB1) does not automatically update existing interconnections in Continuous Function Charts (CFC). Because CFC interconnections store static symbolic identifiers alongside absolute address pointers, changing a DB variable name breaks the symbolic binding. Subsequent CFC compilations abort with errors such as "Interconnection cannot be resolved" or point to invalid addresses. To adapt renamed DB variables cleanly, engineers must use the CFC Chart Reference Data tool to audit all active DB interconnections, delete or rewire obsolete links, and re-establish connections to the updated symbol names.

Data Block Interconnection Mechanics in STEP 7 and CFC

In classic STEP 7 and SIMATIC PCS 7 engineering, data exchange between blocks is predominantly handled via direct graphical block-to-block interconnections within Continuous Function Charts (CFC). However, facilities integrating third-party equipment (such as Modbus gateways, legacy PLC communication buffers, or complex recipe arrays) frequently utilize global shared Data Blocks (e.g., DB1).

When an engineer interconnects a block input (such as Pcs7AnIn.PV_In) to a variable in DB1 (e.g., DB1.Actual_Pressure), the CFC engineering database stores a compound pointer containing:
1. The Symbolic Identifier: "Data_Buffer".Actual_Pressure.
2. The Absolute Address: DB1.DBD 12.

If an engineer subsequently opens DB1 in the DB Editor, alters the variable name to Inlet_Pressure, or inserts a new variable that shifts absolute byte offsets, the CFC database loses synchronization.

Why Renaming Variables in Shared DBs Breaks CFC Links

Unlike modern TIA Portal environments that utilize unified relational symbolic databases with automatic refactoring, classic STEP 7 V5.x and PCS 7 maintain loosely coupled database structures:

DB Editing ActionCFC Database ReactionCFC Compile ReactionRuntime RiskRenaming Variable in DBSymbolic link becomes invalid; CFC retains old nameCompile Error: Symbolic name not found in DBDownload blocked until rewiredChanging Data Type in DBType mismatch between DB element and block inputCompile Error: Data types do not matchDownload blockedInserting Variable Above LinksAbsolute byte addresses shift; symbolic link breaksReads wrong process data if absolute address is usedController executes with corrupted variablesRenaming DB in Symbol TableGlobal DB symbol changes across all chartsRequires 'Check block consistency'Widespread compilation failures

Because the CFC chart does not listen for real-time edit events inside the DB Editor, modifying a DB definition without updating CFC charts creates broken or orphaned pointers.

Auditing Interconnections via Chart Reference Data

To identify every chart and block input affected by a DB variable change:

Open any CFC chart in the project.
Navigate to Options -> Chart Reference Data (or press Ctrl + R).
In the Reference Data window, select View -> Interconnections -> Shared Addresses.
Filter by the specific Data Block (e.g., DB1 or symbolic name "Buffer_DB").
The utility displays a complete table enumerating:
- Target Chart Name
- Target Block Instance and Pin Name
- Connected DB Variable and Address
Export or print this list to serve as an engineering checklist for rewiring.

Step-by-Step Procedure to Rewire Renamed DB Variables

To resolve broken links following a DB modification:

Compile CFC to Expose All Errors:
- In CFC, click Chart -> Compile -> As Program.
- Select Changes only.
- Review the compiler log: every broken interconnection is flagged with an error hyperlink.
Rewire via CFC Editor:
- Double-click the first error in the compile log to jump directly to the affected block pin.
- Right-click the red or faulted interconnection on the block pin -> select Delete Interconnection.
- Right-click the input pin -> select Interconnection to Shared Address....
- In the symbol browser, select DB1 and choose the newly renamed variable (e.g., Inlet_Pressure).
- Repeat for all flagged interconnections.
Alternative: Utilize Textual Interconnections for Mass Rewiring:
- If extensive variables were renamed, disconnect pins and establish Textual Interconnections referencing the new names (e.g., "DB1".Inlet_Pressure).
- Execute Options -> Close Textual Interconnections to bind them simultaneously.

Verification

To verify that all DB interconnections are restored:
1. Recompile the CFC program: Chart -> Compile -> As Program (Changes only).
2. Confirm that compilation finishes with 0 Errors and 0 unresolved textual links.
3. Open Chart Reference Data -> Interconnections -> Shared Addresses; verify that all pins show active, valid links to the updated DB variable names.
4. Download changes to the CPU in RUN mode; verify in online watch mode that live values propagate from the DB to the block inputs accurately.

Limitations and Operational Precautions

Never insert new variables in the middle of an existing shared Data Block on a running production controller. Inserting variables shifts all subsequent byte addresses (e.g., moving DBD 12 to DBD 16). If charts are downloaded while other controllers or WinCC servers still reference the old absolute offsets, severe process data corruption will occur. Always append new variables to the very end of an existing DB, or create a new dedicated Data Block.

Engineer FAQ

Can CFC automatically update renamed DB variables like in TIA Portal?

No. Classic STEP 7 / PCS 7 CFC does not have automatic refactoring for shared DB variables. Renaming must be manually rewired in CFC.

Why should I avoid using global shared DBs in PCS 7?

PCS 7 is designed around the concept of self-contained function blocks with instance DBs. Using global shared DBs bypasses automated OS compile features and increases the risk of addressing errors.

What happens if I change the DB variable name while the CPU is in RUN?

The running controller continues to read the old absolute address until you compile and download the modified CFC program. If byte offsets shifted, the controller will immediately read wrong data.