Troubleshooting Siemens TIA V15 FB True/False Misinterpretation

1. Problem Overview: The Grey "False" Misinterpretation on Disconnected FB Inputs

When programming a Siemens SIMATIC S7-1200 or S7-1500 PLC in TIA Portal V15, engineers frequently encounter a misleading visual cue on Function Block (FB) Boolean inputs. If a Boolean input pin is left disconnected from any external source, the editor displays the literal text false in grey italic typography. Visually, this looks identical to a programming language expression that would feed a logical FALSE into the FB at every scan.

It does not. The grey false is a static label that reflects the start value loaded into the corresponding instance Data Block (iDB) tag when the PLC initializes. The runtime behavior of that input parameter is governed entirely by the instance DB memory cell, not by the grey label. If a prior scan cycle wrote a TRUE to that parameter — for example, because a previous revision of the network connected a real Boolean tag — the input continues to evaluate as TRUE on every subsequent cycle until an active write occurs.

The behavior is not a defect. It is the documented semantics of the TIA Portal editor and reflects the underlying instance-DB memory model of the S7-1200 and S7-1500 run-time system. The risk arises when engineers treat the grey label as an active constant assignment rather than a passive rendering of the start value. Recognizing the difference between documentation and instruction is the key to avoiding the trap.

2. Root Cause: Instance Data Block Start Values and the Memory Model

Every call to a Function Block in an S7-1200 or S7-1500 program is bound to a dedicated instance Data Block. The instance DB is the runtime memory of the FB. Each INPUT, OUTPUT, IN_OUT, and STATIC parameter declared in the FB interface is materialized as a tag in the instance DB with the same name. When the FB is invoked, the call site reads and writes the iDB tags rather than passing values through a stack frame; this is the central difference between an FB and a Function (FC), and it is the reason the start-value behavior exists.

For each parameter tag, the FB interface declaration in TIA Portal carries three property values that are independent of the editor wiring:

The grey false displayed on a disconnected input reflects the start value. The actual value the FB reads at scan time is the value resident in the iDB tag — which may or may not match the start value, depending on whether any prior code wrote to it. Conceptually, the editor renders the following pseudo-code in your network when the input is disconnected:

// Pseudo-code representing disconnected FB input
IF (input_pin_connected) THEN
    // TIA Portal generates an explicit load instruction
    iDB.input := value_on_input_pin;
ELSE
    // No load instruction is emitted; iDB tag is untouched.
    // The editor displays the iDB start value in grey
    // for documentation only.
END_IF;

The crucial detail is in the ELSE branch: TIA Portal does not generate any code that forces the start value into the iDB tag at runtime. The grey label is documentation, not instruction. The instance DB tag retains whatever value it last held, which is precisely the behavior that catches engineers off-guard. For reference on the instance-DB model and parameter classification in TIA Portal, see the SIMATIC S7-1500 system manual on the Siemens Industry Online Support portal.

3. The TIA Portal Visual Language: Decoding Grey, Blue, and Black

TIA Portal encodes the activation state of every operand in the network using a color and weight scheme. Misinterpreting these cues is the proximate cause of the bug reports associated with this issue. The full color matrix for Boolean inputs is summarized below.

The italic lowercase false on a disconnected pin is identical to the start value of an instance DB Boolean tag with a default of FALSE. Engineers who read "false" as a forcing value are reading the wrong semantic. The display is showing you the initialization state of the underlying memory cell, not the value that the next scan will load. The same semantics apply if the start value is TRUE: the grey label will read true in italic, but a disconnected input still does not generate a load instruction, and a manipulated iDB tag will continue to dominate runtime behavior.

4. Generated Code: What TIA Portal Compiles for Disconnected Inputs

To understand why the editor behaves the way it does, examine the compiled STL/SCL equivalent of a network with both connected and disconnected inputs. Consider the following declaration in an FB interface:

FUNCTION_BLOCK FB_MotorControl
VAR_INPUT
    bEnable  : BOOL;  // start value FALSE
    bStart   : BOOL;  // start value FALSE
    bStop    : BOOL;  // start value TRUE
END_VAR
VAR_OUTPUT
    bRun     : BOOL;
END_VAR
BEGIN
    bRun := bEnable AND (bStart OR NOT bStop);
END_FUNCTION_BLOCK

The diagram below maps the network wiring to the resulting compilation path:

Network wiring cases and the resulting compiled instruction sequence:

The case to study is Network A. No load instructions are emitted. The iDB tags bEnable, bStart, and bStop retain whatever value they hold in the iDB memory. After a fresh download and STOP-to-RUN transition, the iDB tags are loaded with their start values (FALSE, FALSE, TRUE respectively), so bRun correctly evaluates to FALSE. After a warm restart, the start values are reloaded, and the same result holds. But if the iDB tags have been manipulated from a watch table, an HMI, or any other code path that writes to them directly, the displayed grey false no longer reflects reality. This is the precise reason Siemens documentation describes the disconnected state as a documentation aid, not a forcing mechanism.

5. Reproduction Procedure in TIA Portal V15

The following steps reproduce the behavior on a stock TIA Portal V15 installation with an S7-1500 or S7-1200 PLC. The behavior is identical for the entire S7-1500 and S7-1200 product range supported by TIA Portal V15.

1. Open TIA Portal V15 (or V15.1, V16, V17) and create a new project. Add an S7-1500 CPU or S7-1200 CPU as the target device.
2. In Program blocks > Add new block > Function Block, create FB_TRUE_FALSE with the interface shown in Section 4 above (three Boolean inputs, one Boolean output).
3. Drag FB_TRUE_FALSE into OB1. TIA Portal auto-creates DB_TRUE_FALSE_FB as the instance DB. Open the iDB and inspect the start values: bEnable = FALSE, bStart = FALSE, bStop = TRUE.
4. On the FB call in OB1, wire a Boolean tag tagInputA (declared in a separate global DB DB_Tags) to the bEnable input. Compile and download. Force tagInputA = TRUE from a watch table. Confirm via the iDB online view that DB_TRUE_FALSE_FB.bEnable reads TRUE.
5. Right-click the wire to bEnable and select Delete (or click the pin and press Delete). The editor now shows false in grey on the bEnable input.
6. Click Monitor all (the glasses icon in the toolbar). The grey false label is rendered, but the online value of DB_TRUE_FALSE_FB.bEnable remains TRUE. The FB logic continues to behave as if the input were TRUE.
7. Now wire a literal blue FALSE constant to the bEnable input. Compile and download. The online value of DB_TRUE_FALSE_FB.bEnable immediately becomes FALSE on the next scan and the FB behavior changes accordingly.

6. Affected Versions and Platform Compatibility

The grey-label behavior of disconnected FB inputs is a feature of the TIA Portal editor and the S7-1200/S7-1500 run-time architecture, not a defect of any specific version. The behavior is reproducible on every TIA Portal release from V14 SP1 onward. The following compatibility table summarizes the editor and firmware versions in which the behavior has been verified against official Siemens documentation and field-deployed hardware.

The same semantics apply to multi-instance DBs (also called "FB-in-FB" instances), which share the parent FB's instance DB. Optimized and non-optimized instance DBs both exhibit the same start-value behavior, although the online view of optimized DBs requires symbolic access only and may not be available through absolute addresses in the watch table. Firmware compatibility and S7-1500 system manual details are available on the Siemens Industry Online Support portal under the SIMATIC S7-1500 product tree.

7. Defensive Programming Workarounds: Three Reliable Patterns

Three patterns reliably prevent the grey-False misinterpretation from causing runtime surprises. Choose the one that fits your project conventions and safety category.

7.1 Pattern A — Always Wire an Explicit Blue Constant

The simplest and most defensive pattern. On every Boolean input that is not driven by a tag, wire a blue TRUE or FALSE constant. This guarantees the network emits a load instruction on every scan and the input is forced regardless of iDB memory state. The same approach can be used in Ladder Logic and Function Block Diagram, where you place a normally-open or normally-closed contact labelled with the constant.

// Ladder equivalent on every FB call
|---[ FALSE ]--------( FB_MotorControl.bEnable )---|
|---[ "DB_Tags".bStart ]--( FB_MotorControl.bStart )---|
|---[ TRUE ]---------( FB_MotorControl.bStop )---|

Disadvantage: every unused input must be wired, which clutters the network. On a large FB with 20+ Boolean inputs this becomes visually noisy, and it is easy to miss a single input during peer review.

7.2 Pattern B — Force Start Values in the FB Itself

Add a single code block at the very top of the FB that overwrites the input with its desired default. This pattern is useful when the FB is called from many sites and you cannot guarantee every call site wires the input.

FUNCTION_BLOCK FB_MotorControl
VAR_INPUT
    bEnable  : BOOL;  // start value FALSE
    bStart   : BOOL;  // start value FALSE
    bStop    : BOOL;  // start value TRUE
END_VAR
VAR
    bEnable_OverrideActive : BOOL;
END_VAR
BEGIN
    // Defensive default — always force disconnected inputs to a known state
    IF NOT bEnable_OverrideActive THEN
        bEnable := FALSE;
        bStart  := FALSE;
        bStop   := TRUE;
    END_IF;
    bRun := bEnable AND (bStart OR NOT bStop);
END_FUNCTION_BLOCK

Because TIA Portal does not provide a built-in "is_connected" probe on inputs, the conventional approach is to maintain a STATIC flag (bEnable_OverrideActive) that the calling site sets to TRUE when a real value is wired. A simpler and more common variation is to assign the iDB tag from a static default at the top of the FB code and let the input overwrite it when the call site provides a value. Disadvantage: adds code and runtime overhead. Risk: if the iDB tag has been corrupted to match the default by accident, the override may be skipped and the corrupted value may persist.

7.3 Pattern C — Initialize the Instance DB After Download or Warm Restart

Configure the instance DB to be reinitialized on STOP-to-RUN transition. The iDB start values are then reloaded on every warm restart, ensuring the FB inputs begin in a known state. The cleanest implementation is to write the desired defaults to the iDB tags in OB100 (warm restart) or OB101 (hot restart) before any FB call executes.

// In OB100 — Warm Restart
"DB_MotorControl_iDB".bEnable := FALSE;
"DB_MotorControl_iDB".bStart  := FALSE;
"DB_MotorControl_iDB".bStop   := TRUE;

Disadvantage: reinitialization loses any state that the FB may have legitimately written to its STATIC variables during the previous run. Use only when the FB is genuinely stateless between restarts. For FBs that carry operating state (counters, latches, sequences), prefer Pattern A or Pattern B and accept the start-value behavior.

8. Related Behaviors: Multi-Instances, Watch Tables, and HMI Access

The grey-label semantics apply to every parameter type, not just Boolean. Integer, Real, Byte, Word, and DWord inputs all display their start values in grey when disconnected. The same retention behavior applies: the iDB tag is not written by the network, and the FB reads whatever value the iDB tag currently holds.

Three related phenomena frequently confound the same engineers who encounter the grey-False behavior.

Watch-table manipulation: When the input is disconnected, the iDB tag is directly modifiable from a watch table. This is the intended behavior — Siemens documents that the iDB is the runtime memory of the FB and that any tool that can write to the iDB can manipulate the FB state. The watch table does not see the grey label; it sees the raw memory cell. Engineers debugging a runtime issue frequently write a value to the iDB tag from a watch table, observe the FB behavior change, and then exit the watch table without realizing that the value they wrote persists. On the next warm restart the start value is reloaded, but in the interim the FB behaves with the manipulated value.

HMI tag write-back: When an HMI tag is bound to an iDB tag, the HMI can write directly to the iDB memory at runtime. If the HMI writes TRUE to a Boolean input tag that is not wired in the network, the iDB tag is forced TRUE regardless of the grey label. The same behavior applies to OPC UA servers that expose iDB tags symbolically. The HMI does not know — and does not need to know — that the tag is also an FB input parameter; it simply reads and writes the cell.

Multi-instance FB: When an FB is called as a multi-instance inside another FB (also called "FB in FB" or "local instance"), the instance tags of the inner FB are STATIC tags of the outer FB. The same retention semantics apply, but the grey label now appears on the inner FB call within the outer FB code. The start values of the inner FB parameters are loaded when the outer FB is first called, and the inner FB parameter tags are retained in the outer FB's iDB for the lifetime of the program. Multi-instance FBs are particularly susceptible to the issue because the outer FB typically contains many inner FB calls with long parameter lists, and the engineer may wire only a subset of the inputs.

9. Common Pitfalls and Field-Experienced Issues

The following pitfalls have been documented in machine-building and process-control deployments. They are presented as a troubleshooting matrix for quick reference.

10. Safety Implications and SIL-Relevant Considerations

The grey-False behavior has direct implications for safety instrumented functions (SIF) built on F-CPU or F-FB blocks in TIA Portal Safety (S7-1500F / ET 200SP F-CPU). Although the safety editor uses a different color scheme and the F-iDB model is more strictly controlled, the underlying principle still applies: an unwired safety input falls back to its iDB start value, and the safety logic must be validated to ensure that the start value is the safe state.

For SIL 2 and SIL 3 applications, the following rules apply:

• Every F-FB input must be wired to an active constant or to a tag that is itself driven by a safety input, sensor, or other F-tag. Unconnected safety inputs are not permitted in a verified safety program.
• The safe state for every Boolean input must equal its iDB start value. If the safe state and the start value differ, the F-FB will report a discrepancy fault on first scan.
• Discrepancy analysis must account for the iDB retention semantics. A retained input value that was valid before a power cycle may be invalid on restart if the safe state has changed due to a reconfiguration.
• Watch-table manipulation of F-iDB tags requires the safety password and is logged in the safety audit trail. Operators should be aware that any F-iDB write persists across warm restarts only if the affected tag is configured retentive.

11. Verification and Monitoring Procedures

After applying a workaround, the following procedure verifies that the FB input behaves as expected at runtime.

1. Open the FB call in OB1 (or wherever it is invoked). Confirm that the input pin is wired to either a blue constant or a blue tag reference. If it is grey, the pin is disconnected and the workaround is incomplete.
2. Compile the project (Project > Compile all > Software (rebuild all)). Resolve any compiler warnings related to unused inputs. TIA Portal V15 and later emit a warning of severity "Warning" for FBs that contain unused input parameters; treat this as an error in safety-relevant code.
3. Download the project to the CPU. Select Stop > Download to device > all blocks to ensure the iDB is fully overwritten with the new compiled version. A partial download that omits the iDB will leave the previous iDB memory state intact.
4. Place the CPU in RUN. Open the iDB online view (Project tree > Program blocks > FB > right-click instance DB > Open in monitor mode). Verify that the parameter tag value matches the expected start value.
5. From a watch table, manually force the iDB tag to the opposite of the expected start value. Trigger a STOP-to-RUN transition (or download the blocks again). Confirm that the iDB tag is reinitialized to the start value on the transition.
6. From a watch table, manually force the iDB tag while the CPU is in RUN. Confirm that the FB logic reflects the forced value immediately. This proves the input is reading the iDB tag, not a stale value.
7. Repeat steps 1–6 for every FB call in the project. Use the Cross-reference view to enumerate all FB calls and verify each input. The cross-reference view is reached via Project tree > right-click FB > Cross-references or via the menu Edit > Cross-references.

For S7-1500 CPUs with security diagnostics enabled (TIA Portal V17+), the cross-reference view also reports unused or unwired inputs under Security > Unused parameters. Use this view to catch disconnected inputs at the project level rather than on a per-call basis. For users of TIA Portal V15, the same information is available through the Compile > Messages window after enabling the warning level for "Unused FB parameter" in Options > Settings > PLC programming > Compiler > Warnings.

12. Frequently Asked Questions