Monitoring S7-1200 FB Instances in TIA Portal: Troubleshooting

Problem: FB Instance Monitoring Returns the Wrong Instance

On the S7-300/400 with STEP 7 V5.x, an engineer can open an FB in online mode, right-click the call environment, and switch the online view to any instance DB that calls the block. The Monitor/Modify window then displays the tag values for the selected instance. On the S7-1200 with early TIA Portal versions (V10.5 and V11), the same workflow silently fails: TIA Portal opens the first call site of the FB regardless of which instance DB the programmer selected, so the tags shown in the work area do not correspond to the instance the engineer intended to diagnose. The symptom is unmistakable in commissioning: a value looks wrong in the FB body, but the same tag is correct in the associated instance DB opened directly from the project tree.

This article documents the root cause, the V11 behavior with its call-hierarchy task card, the workaround that engineers used at the time, and the correct procedure for current TIA Portal versions (V13 SP1 through V19) where the limitation is resolved.

Affected Products, Firmware, and Software Versions

Root Cause: Why the Wrong Instance Is Displayed

The S7-1200 runtime stores FB instance data in instance DBs (or multi-instance DBs when an FB is declared as a STAT of another FB). The compiler assigns a fixed offset table to every FB interface. When the online view opens an FB, the editor must select one of the N call sites and bind the symbolic tag references in the FB body to the matching instance.

STEP 7 V5.x on the S7-300/400 exposed this selection through the Debug > Call Environment menu, which sent a request to the PLC's online interface (the OPUP and OSTATUS OBs) and changed the live binding. TIA Portal V10.5 did not implement the equivalent request for the S7-1200, because the first-generation S7-1200 firmware did not honor the cross-instance switching command over the S7 communication path. TIA Portal V11 added a Call Hierarchy task card that listed all instance DBs, but the binding still pointed at the first compiled call site, so selecting a different row in the card had no effect on the tag display.

The bug therefore has two layers:

1. Compiler/linker generates a single binding to the first instance.
2. Online driver ignores the user's call-environment selection because the target firmware rejects the rebind command.

When the firmware rejection is the limiting factor, no software patch inside TIA Portal can fix the issue; the workaround must come from the project structure (single-call ordering) or from upgrading the CPU firmware / TIA Portal version.

Symptom Matrix

Solution 1 — Upgrade TIA Portal and CPU Firmware (Recommended)

On any current S7-1200 firmware (V4.2 or later, which is the minimum supported firmware for TIA Portal V15 and later) and any TIA Portal version from V13 SP1 onward, the call environment works as expected. To verify the upgrade path before performing it, use the Siemens compatibility tool.

1. Open the Siemens TIA Portal Version & Compatibility Tool and confirm that the installed TIA Portal version supports the connected CPU's firmware. For example, TIA V18 supports S7-1200 firmware V4.2 through V4.6; V19 supports firmware V4.7.
2. Read the CPU's current firmware with Online > Accessible Nodes > Online & Diagnostics > CPU Information.
3. If firmware is below V4.2, perform a firmware update. Use a SIMATIC memory card with the firmware file ("FWUPDATE.S7S") and power-cycle the CPU. The S7-1200 first-generation max firmware is V4.6; second-generation (G2) supports V4.7+.
4. Upgrade TIA Portal to V18 (long-term supported) or V19. Both versions include the call-environment rebind path that early TIA lacked.
5. Recompile the project, download hardware (PLC), then software (blocks only, with "Reinitialize all instance DBs" enabled), and confirm the call environment now switches the online view.

Reference: Siemens KB 88778921 - TIA Portal call environment in S7-1200/1500.

Solution 2 — Reorder the Call Sequence (V10.5/V11 Workaround)

Because the compiler binds the online view to the first call site, the engineer can force a specific instance to "win" the binding by making that call site the first occurrence of the FB in the program scan order. This is the original workaround the Siemens community used before firmware fixes were available, and it remains useful when the PLC cannot be updated.

1. Open the project tree and expand Program blocks > OB1 (or the OB that scans cyclically).
2. Find every network that calls the FB. Record the instance DB name on each call (e.g., "Motor1", "Motor2", "Motor3").
3. Determine which instance you need to monitor. Cut the network that contains its call and paste it into Network 1 of the OB. The pasted call must be the very first network; OB1 network numbering is the compilation order.
4. Recompile, download, and re-establish the online connection. Open the FB, and the values now match the moved instance.
5. To monitor a different instance, repeat the cut-and-paste step. The project must be re-downloaded each time.

Solution 3 — Use a Watch Table Forced on a Specific Instance DB

If the goal is to read or write individual tags of a specific instance, the watch table gives a deterministic view that does not depend on the call environment at all. This is the cleanest way to diagnose field I/O problems on the S7-1200 in V10.5/V11.

1. Create a new watch table (Project tree > Watch and force tables > Add new watch table).
2. Drag tags from the instance DB into the watch table, or type them as "Instance_DB".TagName (e.g., "Motor_DB".SpeedSetpoint). For multi-instance data inside another FB, the syntax is "Parent_DB".ChildFBName.TagName.
3. Click Monitor all (glasses icon). The values shown are the live contents of the instance DB and update on every OB1 scan.
4. To write, type the new value in the Modify value column and click Modify now (force one-shot) or Modify all (triggered) with a trigger condition such as Trigger: permanent or Trigger: once, at start of scan.

Reference: Siemens KB 77485910 - Using watch tables in TIA Portal.

Solution 4 — Open the Instance DB Directly in Online View

Most commissioning engineers do not need the FB body view at all. The instance DB itself shows every STAT variable of the FB, complete with the actual values, comments, and the cross-reference to the FB source. Open the instance DB with Right-click > Open in online mode (or Right-click > Monitor/Modify in older TIA versions). The data view is identical to what the FB body would show once the call environment is fixed.

This is the recommended path for value-only diagnostics. Use the FB body view only when you need to step through networks in a logical sequence (for example, watching the execution of a complex algorithm).

Solution 5 — Configure the Call Hierarchy Task Card Correctly (V11)

The V11 call hierarchy task card, while limited, can still be useful to enumerate all call sites and to confirm that the binding goes to the wrong instance. Use it as a diagnostic tool, not as a fix.

1. With the FB open in the editor and the PLC online, click Show call hierarchy in the task card on the right edge of TIA Portal.
2. The card lists every call site of the FB and the corresponding instance DB. Confirm that the project contains all expected instances; a missing row indicates a re-declared FB whose call has been lost.
3. The first row is always the binding. If you need to monitor another instance, switch to Solution 2 or Solution 3.
4. Capture the task-card list to a screenshot for the project documentation; this is useful for the change-log of the program.

Verification: Confirming That the Right Instance Is Being Monitored

After applying any of the solutions above, verify the result with a controlled test. The procedure works on every TIA Portal version and every S7-1200 firmware.

1. Add a temporary Tag_Trace : INT; STAT variable to the FB. Set a constant value in Network 1 of the FB (for example, Tag_Trace := 1234;).
2. Build the project and download it.
3. Open each instance DB of the FB online. Confirm that exactly one instance DB shows Tag_Trace = 1234 and the others show 0 (or default).
4. Open the FB in online mode and verify that the displayed value of Tag_Trace matches the instance DB that has 1234. If the values match, the call environment is bound correctly.
5. Remove the Tag_Trace variable and the test assignment, recompile, and download.

Edge Cases and Field-Proven Caveats

Several additional situations can mask or amplify the call-environment bug. Capture them in the project commissioning checklist.

• Multi-instance depth. The S7-1200 allows up to 8 levels of multi-instance nesting (FB inside FB inside FB...). When the depth is exceeded, the compiler emits a warning and the deeper FBs share the same instance block, which can look like a monitoring bug. Use Project > Compiler > Show messages to verify.
• Optimized vs. non-optimized blocks. S7-1200 FB instance DBs are optimized by default in TIA V13 SP1 onward. Optimized blocks cannot be monitored by absolute address. If your diagnostic relies on the legacy absolute view, set the FB's Attributes > Optimized block access to false (not recommended for new projects but supported for legacy migration).
• Know-how-protected blocks. A know-how-protected FB does not expose the tag names in online mode. Use the corresponding instance DB (which is not know-how-protected) to read the data values.
• Renamed instance DBs. Renaming an instance DB in the project tree does not automatically recompile the call sites. A full software rebuild (Right-click PLC > Software (rebuild all blocks)) is required; otherwise the online view points to the old name.
• Library-derived FBs. When an FB comes from a global library, the instance DB is generated from the library's type FB. Updating the type version forces regeneration of every instance; if the call site has not been refreshed, the online view may show tags from the previous version.
• Cold-restart after firmware update. After upgrading the CPU firmware, perform a memory reset (MRES) and re-download the project; otherwise the call-environment cache in the old firmware survives and continues to bind to the first instance.

Recommended Diagnostic Procedure (Field Checklist)

1. Confirm the TIA Portal version (Help > About) and the CPU firmware (Online & Diagnostics). Cross-check with the Siemens compatibility tool.
2. If TIA < V13 SP1 or firmware < V4.2, plan the upgrade first; do not invest in workarounds that the upgrade will obsolete.
3. Open the instance DB online and record the live values. This is the authoritative source of truth.
4. Open the FB online. If the displayed values match the instance DB, the bug is not present. If not, follow Solution 2 (reorder) or Solution 3 (watch table) to continue commissioning.
5. Document the temporary call reordering in the change log. Reorder back to the natural execution order after the upgrade is complete.
6. After upgrade, repeat the verification with the Tag_Trace test variable to confirm the new build binds correctly.

Related Siemens Documentation

Engineers maintaining legacy S7-1200 systems should bookmark the following primary sources:

• TIA Portal V13/V14 - "Monitoring blocks" function in S7-1200/1500
• S7-1200 Programmable Controller - System Manual (2023 edition)
• STEP 7 Professional V18 - Programming and Operating Manual
• Using watch tables in TIA Portal

FAQ