Resolving Step 7 FB Declaration Table Invalid Entries Error

1. Problem Overview

When editing a SIMATIC S7-300 program in STEP 7 V5.x (typically V5.5 + SPx), an attempt to save a Function Block (FB) that contains corrupted or unresolved STATIC (STAT) variable declarations fails with the message:

The block cannot be saved because the declaration table contains invalid entries.

In the FB declaration editor, the affected rows render in red text. Common visible symptoms include:

• Auto-generated names such as STAT0 and STAT172 appearing in red where the user originally defined named multi-instance STATs (for example, iReg, iPid).
• The compile log reports Multiple instances / type unknown or Declaration cannot be resolved for one or more FBs in the call hierarchy.
• Right-click operations such as Check Block Consistency or Check and Update Accesses complete without effect, and the red entries persist.
• Download to the S7-300 CPU is rejected with Online: Block cannot be downloaded because the offline source block is inconsistent.

This condition is reproducible when an FB (for example, FB2) declares STATIC variables whose type is another FB that has itself been replaced, imported from a non-matching version of the Standard Library, or partially overwritten during an Upload Station to PG round-trip on a 12+ year-old European machine. The dependent FB (for example, FB26) loses its type signature, the parent FB's multi-instance column cannot resolve, and STEP 7 silently substitutes placeholder names (STATn) which are then flagged invalid.

2. Affected Environment and Versions

The error pattern is characteristic of STEP 7 V5.x on the following hardware:

The two-machine topology (SIMATIC 300(A) = original upload, SIMATIC 300(B) = working copy) is common in European press shops, paint lines, and packaging cells where the OEM ships one machine and duplicates the program in-house. Always keep one offline archive untouched; that "golden" upload becomes your recovery reference.

Reference: Siemens STEP 7 V5.5 Programming and Operating Manual and the SIMATIC S7-300 CPU 31xC and CPU 31x Technical Specifications.

3. Root Cause Analysis

The declaration table in a STEP 7 FB has three regions: INPUT, OUTPUT, IN_OUT, STAT (STATIC), and TEMP. The STAT region is special because it can declare instances of other FBs (multi-instances). The compiler stores for each STAT row three pieces of information:

1. Name – symbolic identifier, e.g. iPid1.
2. Data Type – the FB type identifier, e.g. FB 26 or a user-defined UDT.
3. Initial Value and Comment – optional metadata.

When STEP 7 cannot reconcile row #2 with any FB currently loaded in the S7 program (i.e., the interface signature differs from the version of CONT_C the FB was originally compiled against), it performs the following failure cascade:

1. The corrupted FB loses its signature table. On next open, STEP 7 inserts placeholder rows named STAT0, STAT1, ..., STATn in red.
2. The parent FB (FB2) referencing that child FB as a multi-instance in its STAT area now points to a type whose interface no longer matches. STEP 7 also re-labelling those STAT rows red.
3. When you press Save (Ctrl+S) the offline block checks fails with "declaration table contains invalid entries" because the type identifier column is empty or null.
4. The Compiler marks the call sites (NETWORK 9 and NETWORK 12 in FB2 in the reported case) in red because the CAL/CALL instruction references a STAT whose instance DB cannot be sized.

The triggering event is almost always one of:

• Replacing a Standard Library block (CONT_C, CONT_S, PULSEGEN, etc.) with a same-named copy that has been inadvertently modified or that came from a different STEP 7 service pack.
• Copy-pasting FB26 or its instance DB from a second offline program that used a different STEP 7 patch level.
• Upload Station to PG corrupting the block interface when the PLC program was originally downloaded from a STEP 7 version with a newer block check-sum algorithm.

Reference for block structure: Siemens Function Block Programming Guide (CE@PCS7).

4. Pre-Recovery Inventory

Before any destructive operation, perform the following:

1. Archive the working project. File → Archive → User-defined archive path, choose *.s7p via the integrated SIMATIC Manager archiver. Do not skip this step.
2. Identify the corrupted FB(s). In SIMATIC Manager, Options → Block Consistency Check. Note every block that appears in red in the result dialog.
3. Identify the orphaned multi-instance parent(s). Open the Program Structure window (View → Online) and follow the call tree from OB1 → FB2 → FB26. Any red FB on that chain is a candidate.
4. Confirm library origin. In the Libraries pane, expand Standard Library → PID Control Blocks and right-click CONT_C → Properties. Note the Time stamp and Checksum. Compare with the timestamp on the FB26 in your S7 program.
5. Document the network numbers. In the reported case, the broken calls were in NETWORK 9 and NETWORK 12 of FB2. Take a screenshot or printout of each affected network before the recovery so you can manually restore the wiring on the CAL instruction.

5. Recovery Procedure (Step-by-Step)

The following sequence restored the project to a compilable, downloadable state on a SIMATIC 300(B) CPU 315-2 DP. It addresses both the child FB (FB26) and the parent FB (FB2) that references it.

5.1 Replace the Corrupted Standard Library Block

1. In SIMATIC Manager, open the Libraries task card and navigate to Standard Library → PID Control Blocks.
2. Locate FB "CONT_C" (block number 26 in the PID Control library, or whatever block number your corrupted FB26 happens to use).
3. Right-click and select Copy.
4. Navigate to S7 Program(2) → Blocks in your offline S7-300 station. Right-click and select Paste. Confirm any Object already exists dialog by choosing Overwrite.
5. The new CONT_C now carries the canonical interface from your current STEP 7 installation. Open it once to confirm the Declaration view shows the standard INPUT/OUTPUT columns and no red STAT rows.

Reference: Siemens Standard PID Control Blocks Manual (CE@PCS7 AP Library V8.x).

5.2 Check and Update Accesses on the Child FB (FB26)

1. Open FB26 in the LAD/FBD/STL editor.
2. From the menu, choose Edit → Check and Update Accesses (shortcut: Ctrl+F7). STEP 7 will scan every CAL / CALL / instance reference inside FB26 and re-bind it to the freshly pasted CONT_C type.
3. STEP 7 will issue a dialog stating that interface declarations have been replaced. Click OK. The auto-generated STATn rows in FB26 should clear; valid multi-instance names (if any) re-appear in black.
4. Save FB26 (Ctrl+S). The save should now succeed without the "declaration table contains invalid entries" error.

5.3 Update Block Calls inside FB26

Because the freshly pasted CONT_C has a different interface signature than the version FB26 was originally compiled against, every CALL site inside FB26 now shows a red instruction. In the reported case these were at NETWORK 9 and NETWORK 12.

1. In FB26, navigate to each red CALL instruction.
2. Right-click the red call box and choose Update Block Call.
3. STEP 7 inserts a fresh CALL/CAL block with all current inputs and outputs listed. The previous wiring is replaced with placeholders (default initial values).
4. Manually re-wire each input/output. Use the screenshots or printouts you captured in Section 4 to restore the original signal connections (for example: SP_INT := iSetpoint, PV_IN := iProcess, LMN := iOutput).
5. Save FB26 again.

5.4 Check and Update Accesses on the Parent FB (FB2)

1. Open FB2 in the LAD/FBD/STL editor.
2. Press Ctrl+F7 to invoke Check and Update Accesses on the parent block.
3. STEP 7 rebuilds the multi-instance references declared in FB2's STAT area. The red STAT0 and STAT172 rows should resolve to the canonical names from FB26 (or to whatever FB number the multi-instance now uses).
4. Save FB2 (Ctrl+S). The error dialog no longer appears.

5.5 Compile and Download

1. Select all blocks under S7 Program(2) → Blocks.
2. Right-click → Compile. The status bar should report No errors.
3. Connect to the CPU online.
4. PLC → Download. Choose Entire program or select only the corrected FBs (FB2, FB26, CONT_C, and the affected instance DBs).
5. CPU should accept the download and enter RUN.

Reference: SIMATIC S7-300 Automation System Installation Manual.

6. Multi-Instance FB Reconstruction Details

Multi-instance FBs are a STEP 7 feature that lets a parent FB hold instances of other FBs in its STATIC region. This avoids the proliferation of standalone instance DBs. The internal layout looks like:

FB2 (parent)
|-- STAT
|   |-- iReg : FB 10         -- 32 bytes
|   |-- iPid1 : FB 26 (CONT_C) -- 240 bytes
|   |-- iPid2 : FB 26 (CONT_C) -- 240 bytes
|   |-- iAux : FB 100        -- 64 bytes
|-- TEMP
    |-- tRetVal : INT

When CONT_C's interface changes (which has happened between STEP 7 V5.1 and V5.5 SP5 as Siemens added and removed parameters such as COM_RST, SP_TRACK, or DEADB_W), the offsets and sizes of every multi-instance in every parent FB that holds a copy of CONT_C become invalid. STEP 7 catches this mismatch only when the parent FB is opened and recompiled. The placeholder STATn rows are STEP 7's way of saying "I see there should be a STAT here, but I do not know what it is called."

The Check and Update Accesses function (Ctrl+F7) walks the declaration table top to bottom, looks up each declared type in the program-wide symbol table, and re-resolves the binding. If the referenced FB is also corrupted, it leaves the row red and the operator must repair the referenced FB first.

7. Manual Declaration Repair (When Step 5 Fails)

If Check and Update Accesses still leaves red rows, perform a manual reset on the declaration table. This is the procedure that yy1 validated in the original case:

1. Open FB2.
2. Select all rows in the STATIC declaration region.
3. Press Delete to clear the table.
4. Re-enter each multi-instance declaration manually. The minimum required is:

Name     | Data Type | Initial Value | Comment
---------|-----------|---------------|-----------------------------
iReg     | FB 10     |               ; regulator instance
iPid1    | FB 26     |               ; closed-loop controller 1
iPid2    | FB 26     |               ; closed-loop controller 2

5. Do not enter any value in the Address column. The address is computed by the compiler and is not user-editable for multi-instances.
6. Press Ctrl+F7 to re-bind the access paths.
7. If FB26 still appears red after this, repeat steps 1-5 on FB26 itself. Do not attempt to delete the STATn rows individually; delete the entire STATIC region as a block.
8. Save FB2 and FB26.

Reference: STEP 7 V5.5 Programming and Operating Manual — Chapter 6 (Block Programming).

8. Verification

After completing the recovery, run the following verification matrix:

If the CPU faults immediately after download with SF / BF LEDs lit, the instance DB likely retained a stale snapshot. Delete the instance DB on the CPU, re-download, and let the OB100 (or OB101 for restart) re-initialize the STAT areas on the first scan.

9. Common Pitfalls and Red Flags

10. Prevention and Library Hygiene

Long-term prevention requires controlling the block source of truth.

1. Maintain a vendor library archive. Export Standard Library → PID Control Blocks as a separate *.s7l project and check it into version control (SVN, Git, or a Siemens PLM repository).
2. Never modify a library block in place. If you need a custom variant of CONT_C, copy it to the S7 program, rename it (e.g., CONT_C_USER), and modify the copy.
3. Tag every FB with its STEP 7 service pack. Use the Block Properties → Comment field to record Created: STEP 7 V5.5 SP3. This makes round-tripping safe.
4. Run Block Consistency Check after every Upload Station to PG. Schedule it as part of the standard restoration SOP.
5. Document multi-instance offsets. In FB2's header comment, list the size of each STAT child (e.g., iPid1 = 240 bytes). This lets you spot interface changes immediately.

Reference: SIMATIC S7-300 CPU 31xC Technical Specifications and the S7-300 Module Data Reference Manual.

11. Quick Reference Diagnostic Flowchart

1. Does the FB save fail with "declaration table contains invalid entries"? → Yes: proceed to step 2.
2. Are STAT rows rendered in red? → Yes: go to step 3.
3. Is the type column of the red rows blank or showing STATn? → Yes: go to step 4.
4. Is the FB being used as a multi-instance in a parent FB? → Yes: go to step 5.
5. Does the original FB (FB26) come from Standard Library → PID Control Blocks? → Yes: replace it from the library and run Check and Update Accesses on FB26 first, then FB2.
6. Did Check and Update Accesses clear the red rows on FB26? → No: delete and manually re-declare the STATIC region (Section 7).
7. Did FB2 still show red rows after Check and Update Accesses? → No: save and download.
8. Does the download succeed and the CPU enter RUN? → Yes: recovery complete.

12. Field Commissioning Notes

When applying this procedure on a live European machine during a weekend recovery window, observe the following safety and operational points:

• Place the machine in Maintenance / Safe Stop state per the machine's CE declaration before any PG connection. The MPI/PROFIBUS cable should be connected only after the safety circuit is verified.
• Disable the CPU's Restart OB processing temporarily if the machine is mid-batch. OB100 will re-initialize all STAT areas and may cause a process bump.
• Capture a final online snapshot of all instance DBs (PID setpoints, integrator states, valve positions) before download. Some of these values are tuned in the field and not stored in the offline project.
• After download, perform a single dry-run cycle in manual mode (PID in MANUAL = TRUE) before returning the line to auto.
• If the machine is part of a two-station setup, apply the fix to both stations and perform a parallel cross-compare (Options → Compare Blocks) to guarantee identical block checksums.

Frequently Asked Questions