Merging S7-300 Projects: Uploaded Blocks with Symbol Tables

1. Problem Definition and Scope

During the lifecycle of a Siemens SIMATIC S7-300 station, engineers routinely end up holding two parallel STEP 7 V5.x project files that drift out of sync. The two artifacts are:

• Prog1 – the original engineering project containing the symbol table, network comments, block names, SCL/STL/FBD sources, hardware configuration (HW Config), net data, and connection tables.
• Prog2 – an upload-to-PG (programming device) image pulled from the live CPU using the STEP 7 menu PLC > Upload Station to PG (or via NetPro upload). It contains the executable blocks but no symbol table, no comments, no HW Config, no connection tables, and typically only a stripped-down program structure.

The objective is a single STEP 7 project that contains the latest running CPU code and the engineering symbols so that the program is documented, searchable, and can be modified online without losing readability. There is no one-click merge tool in SIMATIC Manager. The merge is a manual, structural, block-by-block operation that requires discipline and version control.

2. What STEP 7 Upload-to-PG Produces (and What It Omits)

Understanding the contents of a CPU upload is critical before attempting a merge. The Upload Station to PG function reconstructs a partial project in the S7 Program node as follows:

The implication is clear: a merge must restore the symbol table, comments, source files, and connection data on top of the executable blocks retrieved from the CPU. The blocks themselves are byte-for-byte equivalent (provided the upload completes cleanly), so logic preservation is automatic. Readability and engineering context are not.

3. Block-by-Block Merging Strategy

The recommended approach is to treat the uploaded project (Prog2) as the runtime source of truth and graft the documentation assets from Prog1 onto it. The high-level flow is shown below.

3.1 Pre-merge Workspace Preparation

1. Make a backup copy of Prog2 (entire .s7p folder, including the S7PROG, OMBS7 and Global subfolders). Store as a zip with a timestamped filename.
2. Make a backup copy of Prog1 for reference.
3. Open Prog2 in SIMATIC Manager and trigger PLC > Compile and Download Objects with the option Consistency Check to verify the upload produced internally consistent blocks.
4. Open the reference data on Prog2 (Options > Reference Data > Display) to understand the cross-block call structure. This drives the merge order (start with leaf FBs, work up to OB1).
5. Open reference data on Prog1 and lay the two cross-reference prints side by side. Blocks called from identical OBs in both projects can be migrated in bulk.

4. Rebuilding the Symbol Table

The symbol table is the single most labor-saving asset in any S7-300 merge. Prog1's symbols must be transplanted into Prog2's S7 Program > Symbols editor.

1. In Prog1, right-click Symbols > Export > save as ASCII text (.txt) or use Options > Symbol Table > Export to a CFG/SDF file.
2. Open the exported file in a spreadsheet. Verify the columns: Symbol, Address, Data type, Comment.
3. In Prog2, right-click Symbols > Import. Select the file from step 1.
4. After import, open the symbol table in Prog2 and confirm the row count matches Prog1 exactly. STEP 7 will silently truncate duplicate symbol rows – a known hazard that can hide typos.

4.1 Symbol Table Hygiene

• Maximum symbol length is 24 characters (STEP 7 V5.x limit).
• Special characters allowed: letters, digits, underscore; the first character must be a letter.
• Symbol comments allow up to 80 characters per row.
• Duplicate absolute addresses are tolerated by the editor but block compilation will warn – fix them before recompiling.

5. Block Type Handling – Detailed Procedures

5.1 OB (Organization Block) Merge

Organization blocks define the cyclic, time-driven, and interrupt-driven entry points. OBs uploaded from Prog2 must have their interface (OB1: temp variables; OB35: period in ms; OB100: start-up type) verified against Prog1. In almost all cases the OB shell is identical between two recent versions of the same project, so the procedure is:

1. Copy the Prog1 OB block file (OB1.AWL / OB1.SCL) into the Prog2 S7 Program > Blocks folder.
2. Recompile from source (File > Compile in the SCL/STL editor).
3. Compare online vs. offline (PLC > Compare Blocks) to confirm byte equivalence with the running CPU.

If Prog2 was uploaded cleanly, the compiled machine code inside the OB will already match the running CPU; replacing the source file only adds back the comments and symbolic operands visible in the editor.

5.2 FB and FC Merge

Function Blocks (FB) and Functions (FC) carry their interface declarations at the top of the block. If Prog2 and Prog1 were derived from the same engineering baseline, the IN, OUT, IN_OUT, STAT and TEMP sections will match. The merge procedure per FB/FC is:

1. In Prog1, open the FB/FC, select all in the source view, copy (Ctrl+C).
2. In Prog2, open the corresponding FB/FC, select all in the source view, paste over the existing content.
3. Recompile. STEP 7 will regenerate the interface description (the block header) based on the new source.
4. Compare online/offline. Any discrepancy is a red flag that the running CPU has a different program version than the engineering archive.

5.3 DB (Shared Data Block) Merge

Shared DBs declared with absolute addresses (DB with assigned user-defined structure) must have every Address > Symbol > Type > Initial Value > Comment row verified. Procedure:

1. In Prog2 open the DB in declaration view.
2. From Prog1 copy the declaration view (or the SCL source if the DB was defined as DATA_BLOCK).
3. Paste the declaration into Prog2 and recompile.
4. Compare the online DB actual values against the recompiled offline DB. Watch for initialization mismatch warnings – STEP 7 will only re-initialize a DB on download if the structure has changed.

6. Instance DBs, SFC/SFB Calls, and System Data Blocks

6.1 Instance DBs

Instance DBs hold the runtime values for FB instances. When you replace the FB source in Prog2, the existing instance DBs remain valid because their layout is dictated by the FB interface, not by the FB code. STEP 7 will warn but still allow the recompile if the FB interface has not changed.

However, if a STAT variable was added to the FB in Prog2 (runtime), instance DBs in Prog2 already contain the new STAT; instance DBs in Prog1 do not. In this case the correct path is:

1. Identify all instance DBs of the modified FB using reference data (Program Information > Cross References).
2. Open the instance DB in Prog2 and confirm its structure matches the new FB interface.
3. Delete the corresponding instance DBs in Prog1 before transplanting code, otherwise the old Prog1 instance DBs will follow the merge and re-introduce a stale interface.

6.2 SFC and SFB Calls

System Functions (SFC) and System Function Blocks (SFB) live in the CPU firmware, not in the PG project. STEP 7 maintains them in the Standard Library. After upload, Prog2 contains only the call sites (CALL SFCxx / CALL SFBxx instructions) inside user blocks. The block names themselves are never uploaded.

To restore readable calls:

1. Open Standard Library > System Function Blocks in Prog2 (it's usually already visible under Libraries in SIMATIC Manager).
2. STEP 7 will resolve the names automatically when the project is recompiled.
3. If a call shows as ?SFC 20 ? after recompile, the standard library is missing or the CPU firmware version differs. Confirm the CPU MLFB against the SIMATIC Manager target.

6.3 System Data Blocks (SDB)

SDBs contain HW Config (rack/slot topology, parameter records), net data, connection tables, and global data definitions. Prog2's uploaded SDBs are usually partial; Prog1's SDBs reflect the full engineering design. Merge sequence:

1. Open HW Config in Prog1. Verify it still matches the physical rack on the plant floor.
2. If the physical hardware is unchanged, copy Prog1's System Data container into Prog2 (drag-and-drop in SIMATIC Manager).
3. Recompile HW Config in Prog2 (Station > Save and Compile).
4. Download only the System Data to the CPU (PLC > Download > Selected Module) – never download the full program while the plant is running.

7. Using the STEP 7 Block Compare Tool

STEP 7 V5.x includes a built-in block comparison engine reachable via Options > Compare Blocks. After the merge, it is the primary verification tool.

Recommended workflow after merge:

1. Open Prog2's S7 Program > Blocks container.
2. Run PLC > Compare Blocks > Online/Offline. Every block that shows different must be investigated before the merge is considered complete.
3. For each differing block, open PLC > Monitor/Modify to confirm the live CPU is operating on the expected logic.
4. Save a printed PDF of the comparison results and attach to the project's revision history.

8. Online Verification and Commissioning Checks

A merged project must pass the following checks before being trusted as the live engineering archive:

1. Block consistency: PLC > Check Block Consistency > Generate Module Drivers in SIMATIC Manager. Resolve every reported error; warnings about unused tags can be ignored.
2. Reference data regeneration: Options > Reference Data > Regenerate. Confirm no unresolved references appear at the bottom of the cross-reference list.
3. Online block list parity: PLC > Accessible Nodes > select CPU > PLC > Upload to PG a second time into a scratch folder. Run Compare Blocks between the scratch folder and the merged Prog2. Expect zero differences.
4. Download guard test: with the plant in a safe state, attempt PLC > Download. STEP 7 will prompt for each block that would change. If the prompt shows no blocks, the merge is runtime-equivalent. If it shows blocks, decide case-by-case whether to download.
5. Diagnostic buffer review: PLC > Diagnostic/Setting > Diagnostic Buffer. Confirm no OB121/OB122 programming errors were thrown during the merge work. Resolve any that appeared.

9. Worked Example – 150-IO Sample Project

A typical small machine application with 150 digital I/O, 1 FB-based sequencer, 1 PID block, and 8 shared DBs typically takes 3–5 working days for a mid-level STEP 7 engineer to merge. The timeline:

This matches the field-reported effort of four days for a 150-IO structured project. Smaller projects (~50 I/O) can be merged in a single day by the same engineer; larger projects (>500 I/O with several FBs) require weeks and a structured change log.

10. Edge Cases, Pitfalls, and Recovery

10.1 Know-How-Protected Blocks

If a block in Prog2 was uploaded with know-how protection (block password), STEP 7 will show it as a block with only the interface visible – the code section is sealed. The merge for that block consists of leaving Prog2's copy intact and only restoring the symbol mapping in the symbol table; you cannot recover the source from Prog1 because the upload broke the unprotection.

10.2 Different CPU Firmware

If Prog1 was built for CPU 315-2 DP (FW V3.x) and Prog2 was uploaded from a CPU 315-2 PN/DP (FW V4.x), certain SFCs may be at different version numbers. The compare tool will highlight every SFC as different. Action: target the firmware version of the live CPU when re-opening the merged project, or migrate the live CPU to match Prog1's engineering baseline.

10.3 Memory Layout Shifts

If the live CPU has had modules added or removed since Prog1 was last touched, every absolute address symbol that crossed a module boundary is wrong. Use the reference data printout of Prog1 to identify symbols in affected slots, then re-assign addresses in the merged symbol table before downloading.

10.4 Corrupt Upload

If the upload-to-PG fails partway (typical with MPI/DP cables on noisy plant floors), Prog2 may be missing blocks. Always repeat the upload into a fresh directory and diff the block list with the live CPU via PLC > Accessible Nodes > Block List. The live block list is the canonical inventory.

10.5 Versioned Source Files Lost

If Prog1's SOURCES folder (.scl, .awl, .fbd files) is intact, transplanting the source files into Prog2 and recompiling is the cleanest path. If Prog1's source files are missing, the merge must be done on the compiled blocks – comments cannot be recovered and the merged project will be comment-free.

11. Long-Term Version Control Recommendations

A one-off merge solves the immediate problem but does not prevent future drift. Recommended practices for any S7-300 program under continuous engineering:

• Archive per download: after every online download, copy the entire .s7p folder to a dated archive folder. Use a naming convention such as ProgName_YYYYMMDD_HHMM.
• CVS/SVN/Git: store the .s7p folder in a version control system. STEP 7's block files are binary but version control can still detect insertions, deletions, and timestamp changes – use it as a guard, not as a diff tool.
• External diff tool: for source-only projects, Git + a text-aware diff viewer (e.g. Beyond Compare, WinMerge) provides the cleanest history.
• Change log: keep a per-station change log in the project's Documentation folder. Every download entry must list: changed blocks, author, plant area, ticket number.
• Periodic re-merge drill: once per year, perform the merge between the engineering archive and a fresh upload. It exercises the procedure and surfaces undocumented drift before an emergency forces a merge under pressure.

Refer to the SIMATIC S7-300 System Manual for firmware/catalog references, the STEP 7 V5.5 Programming and Operating Manual for block-level syntax, and the STEP 7 V5.x Migration / Compatibility Notes when mixing TIA Portal-migrated blocks with legacy V5.x sources.

12. Frequently Asked Questions