Siemens STEP 7 Instance DB Not Accepted: FB/IDB Mismatch Fix

Problem Description

When a SIMATIC machine program is expanded with additional emergency-stop channels, the standard workflow is to copy an existing Function Block (FB) and its associated Instance Data Block (DB) so the proven logic is reused without re-engineering. The typical fault observed in STEP 7 V5.x / SIMATIC Manager and in TIA Portal (STEP 7 V16-V18) is: the new FB is accepted at the call site inside the FC, but the new instance DB reference is rejected by the LAD/FBD/STL editor with red syntax markers, or it compiles with a type-inconsistency warning. In the example case, blocks FB5307 through FB5310 (existing e-stops) compile cleanly, while a newly inserted FB5331 paired with manually copied DB5331 (symbolic name Estop5IndCat) is not accepted even though the FB symbol shows no error. The compiler also rejects the binding when the user types Estop5IndCat with a stray trailing dot (Estop5IndCat.) instead of the bare symbolic name.

This document walks through the two root causes of the rejected instance DB reference (manually copied IDB that no longer matches the FB interface, and trailing-dot symbolic-name corruption), the diagnostic sequence, the field-proven repair, and the verification procedure for bringing the new emergency-stop channels online without re-validating the safety chain.

Root Cause Analysis

Every multi-instance or single-instance FB in SIMATIC requires an Instance Data Block (IDB) whose internal layout is generated from the FB's VAR_INPUT, VAR_OUTPUT, VAR_IN_OUT, VAR_TEMP, VAR, and STAT declarations. The IDB is therefore owned by the FB. Three failure modes produce the "IDB not accepted" symptom:

1. Structural mismatch between copied IDB and target FB. When the engineer copies an existing IDB and renames it (e.g., DB5307 -> DB5331), the offset and length of every static variable in the renamed DB still reflects the original FB's interface. If the new FB (FB5331) has even one extra STAT variable, one renamed tag, or one altered BOOL/INT/REAL data type, the renamed DB no longer fits. STEP 7 detects this at compile time and refuses the binding.
2. Trailing-dot symbolic-name corruption. TIA Portal and the STEP 7 LAD/FBD/STL editors auto-append a period to a DB name when they detect that the engineer is about to drill into a data element (e.g., Estop5IndCat. prompts the engineer to pick Estop5IndCat.bPressed). When the editor finishes autocompletion on Enter, the literal reference includes the trailing dot. The compiler treats Estop5IndCat (valid DB symbol) and Estop5IndCat. (invalid empty member) as different identifiers and refuses the latter.
3. Non-existent FB number referenced. If the user types a DB number but the corresponding FB was never created, downloaded, or was deleted, the symbol table cannot resolve the call and the editor highlights both the FB slot and the DB slot in red. This is the most trivial case but is often confused with the structural mismatch case.

Which of the three applies can be determined by the exact symptom: a red FB symbol implies root cause #3; a red DB symbol with a valid FB symbol and a name with a trailing dot implies root cause #2; and a red DB symbol with a valid FB symbol and no trailing dot but a compile error pointing at Instance DB structure implies root cause #1.

Symptom: Trailing Dot in the Symbolic Name

The trailing-dot behaviour is a well-known auto-completion artefact. As soon as the editor sees a recognised symbolic name being typed, it appends a period and waits for a member access. If the engineer presses Enter, the reference stored in the network is the dotted form. STEP 7 will then resolve Estop5IndCat. as an attempted member access on an empty member, which is not a valid DB symbol. The red marker appears on the DB operand even though the FB is green.

Quick field test: open the symbol table (or PLC > Symbols in TIA Portal) and search for Estop5IndCat. If the symbol exists and points to DB5331, then the FB call site reference must be the bare name without a dot. The fix at the call site is:

1. Click the red DB operand at the call site (the CALL/instance box).
2. Select the symbolic operand field.
3. Delete the trailing dot so the field reads Estop5IndCat.
4. Press Esc (do not press Enter). Pressing Enter re-triggers autocompletion and re-appends the dot.

The same repair must be repeated in every network that uses the affected DB. Typical affected networks in the sample case are Network 11 and Network 12, but any network that references DB5331 by symbol must be inspected. A project-wide search for the literal text Estop5IndCat. (with dot) in the source STL/SCL confirms whether any other reference has been corrupted.

Symptom: Manually Copied IDB Does Not Match the FB Interface

The instance DB is a binary image of the FB's STAT and parameter declarations. When an engineer copies an existing IDB in the project tree (right-click > Copy, then Paste with a new DB number), the binary contents are copied verbatim. Renaming the DB number alone does not regenerate the static layout. The new DB5331 retains the exact byte offsets of DB5307, even though the engineer intends it to back FB5331. If FB5331 differs from FB5307 by even one byte of additional STAT storage, every variable in the new DB is misaligned with the FB's expectations.

Confirmation procedure:

1. Open the original FB (e.g., FB5307) and write down the count of STAT variables and the total length of the STAT section (visible in the interface view).
2. Open the copied IDB (e.g., DB5331). If the project setting "Know-how protection" is active the IDB contents are hidden, but the block length in bytes can still be inspected via Properties > Block Properties.
3. Open the target FB (FB5331) and inspect its STAT section. Compare length to the IDB length. Any difference confirms a structural mismatch.
4. If the mismatch is confirmed, the copied IDB is unrecoverable for the new FB. It must be deleted and regenerated.

The correct method, used in every Siemens training course for S7-300/S7-400 and S7-1200/S7-1500 programming, is to let the FB generate the IDB. The editor binds the new IDB to the FB in one operation, guaranteeing that the binary layout matches the interface declaration at the moment of generation. This is the same workflow that the SIMATIC S7-300/400 Programming with STEP 7 manual (entry point at Siemens Industry Online Support) describes as "calling an FB for the first time" and that the TIA Portal help describes under "Instance DB (creating for an FB)".

Diagnostic Procedure

Run the following sequence before changing anything in the program. Each step is non-destructive.

1. Capture compiler output. Compile the affected FC and capture every warning and error. STEP 7 classic: PLC > Compile. TIA Portal: Project tree, right-click the device, Compile > Software. Record the exact message text, the network number, and the operand identifier flagged.
2. Verify FB existence. In the project tree confirm that the FB number referenced at the call site exists. Right-click > Object Properties and check the Author, Family, and Revision. A "block does not exist" or "symbol unresolved" message indicates root cause #3.
3. Verify symbolic name. Open Symbols and search for the DB's symbolic name. Confirm the spelling, including absence of trailing dot, and that the Data Type column lists FB-DB or INSTANCE-DB.
4. Compare lengths. Compare the byte length of the FB's STAT section to the byte length of the IDB. The two must be equal for a clean binding. Any difference indicates root cause #1.
5. Check know-how protection. If the IDB or FB is know-how-protected, only the lengths are visible, not the symbol contents. The engineer must coordinate with the original programmer or OEM to obtain a non-protected source.

Step-by-Step Resolution

The resolution below assumes the engineer has confirmed root cause #1 (manually copied IDB) and optionally root cause #2 (trailing dot). The steps reproduce the field-proven fix that converts a rejected FB5331 / DB5331 pair into a clean, downloadable program.

1. Delete the offending IDB. In the project tree, right-click DB5331 and select Delete. If the project was previously downloaded to the CPU, also perform PLC > Delete Block on the CPU side, or in TIA Portal use "Online > Download to device" with the "Delete all" option unchecked and just the new block selected.
2. Confirm the FB at the call site. Open the calling FC and locate the new FB call. Confirm the FB number is correct (e.g., FB5331 or FB5310 depending on which FB is actually intended). If using symbolic call, confirm the symbol resolves to an existing FB.
3. Trigger automatic IDB generation. In STEP 7 classic, click on the DB operand slot of the CALL box. Type the new DB number (e.g., 5331) and confirm. The editor will offer to create a new instance DB; click Yes. The new IDB is generated and bound to the FB in one operation. In TIA Portal, drag the FB from the project tree onto the network, then right-click the instance-DB slot and select "Instance DB..." -> "New"; assign the number and symbolic name.
4. Assign symbolic name. Set the symbolic name to the desired value (e.g., Estop5IndCat). Verify the symbol table now lists this name pointing to the new DB number. Avoid pressing Enter inside the name field; press Tab to commit.
5. Inspect for trailing dots. Click the symbolic operand field of the instance DB at the call site. Confirm there is no trailing dot. Repeat for every network that references this DB.
6. Compile and download. Compile the program. All warnings and errors should clear. Download the new FB and new IDB to the CPU. In TIA Portal, use "Download to device" with the "Consistent download" option to ensure the CPU restarts the OB scan only after the new blocks are consistent.
7. Cross-check the existing working pairs. For sanity, repeat the compile check for the previously working pairs (FB5307/DB5307, ..., FB5310/DB5310) to ensure the deletion of DB5331 and any rename did not cascade.

Verification Procedure

After the new IDB is generated and bound, verify with both offline and online checks before restoring the safety chain to production.

1. Offline consistency. In STEP 7 classic: PLC > Consistency Check. In TIA Portal: Project tree > right-click the device > Compile > Software (rebuild). The "Block consistency" dialog must report zero errors.
2. Symbol table consistency. Open the symbol table and confirm every FB has a unique DB number, and every DB symbol is unique and correctly mapped.
3. Online block list. Connect to the CPU and open Online > Block Status. Confirm that the new DB exists on the CPU and that the FB exists. Both should show the same timestamp as the download.
4. Monitor the STAT section. Open the new IDB online (Monitor/Modify). Confirm that the STAT variables update as the e-stop button is pressed. This proves the IDB is actually bound to the running FB.
5. Force / test the safety input. In a controlled commissioning state, force the e-stop input to TRUE and verify that the safety output path trips and that the STAT flag indicating "pressed" is set. This validates end-to-end that the FB and IDB are wired correctly.

Best Practices and Prevention

The IDB binding error is one of the most common avoidable mistakes when scaling STEP 7 code. The following practices prevent recurrence.

• Never copy an IDB. Treat the IDB as an artefact owned by the FB. Always let the FB generate the IDB. This is the recommended workflow in the Siemens STEP 7 programming manual (Siemens Industry Online Support, search "Instance DB").
• Use a block-numbering convention. Reserve an IDB number range per FB family. For the e-stop family FB53xx, use DB53xx with the same numerical suffix; this makes the FB-IDB pairing self-documenting and easier to audit.
• Avoid symbolic references that differ only by trailing dot. Symbol-table editors should reject symbol names that already exist with a trailing dot. Configure the project's symbol consistency check to flag duplicate or near-duplicate symbol names.
• Leverage know-how protection carefully. Know-how-protected FBs are reusable, but the engineer must keep a non-protected source under version control to be able to regenerate an IDB after a future interface change.
• Document FB/IDB pairs in a block list. Maintain a spreadsheet or wiki of FB number, IDB number, symbolic name, revision, and last validation date. The list is invaluable when scaling a program from 8 e-stops to 12 e-stops.
• Use multi-instance FBs for safety logic. Instead of one FB per e-stop, consider a parent FB that contains multi-instances of a child e-stop FB. The child FB owns its STAT data inside the parent's IDB, eliminating the risk of mis-bound standalone IDBs entirely.

Troubleshooting Matrix

Field-Proven Configuration Examples

STL snippet of a correct FB call with auto-generated IDB at NW 11:

CALL  FB 5310 , DB 5310      // existing E-Stop 4
     IN   :=EStop4I

STL snippet of a corrected new FB call at NW 12 after the fix (IDB regenerated, symbolic name correct):

CALL  FB 5331 , DB 5331      // new E-Stop 5
     IN   :=EStop5I

For symbolic call, the equivalent in TIA Portal FBD looks like:

Estop5IndCat(
    IN := EStop5I,
    Pressed => EStop5_PressedFlag
);

Note that the symbolic block reference Estop5IndCat is typed without a trailing dot. After the editor autocompletes, press Esc to commit the bare name. If the engineer presses Enter, the autocompletion will append a dot, producing the rejected form Estop5IndCat..

Standards and References

Programming FBs and IDBs for safety logic falls under the Functional Safety programming expectations in IEC 61131-3 (program organisation, FB/IDB structure) and IEC 62061 / ISO 13849-1 (safety lifecycle). Reference these standards when documenting the change to the safety chain, but do not rely on them as a substitute for re-running the safety validation after a code change. Siemens provides SIMATIC Safety-specific documentation under F-CPU and F-I/O manuals on Siemens Industry Online Support; consult them when the e-stop logic is realised with F-FBs and F-IDBs.