Troubleshooting Siemens S7-300/400 FB Inputs Showing Zero Values

Problem Overview: FB Inputs Read Zero Despite Correct Call Site

When a Function (FC) calls a Function Block (FB) in a Siemens SIMATIC S7-300/400 (and the same logic applies to S7-1200 and S7-1500 with the same call-by-reference semantics), engineers occasionally observe a contradiction that defies first-line intuition: the input parameters at the call site in the FC show the expected values in online monitor mode, but every input on the FB side reads 0 or the declared initial value. In a representative field case, FC10 calls FB2 inside an FC that is itself scheduled in OB35. Twenty other call sites also invoke FB2 from elsewhere in the program. The behaviour appears intermittently. On some days the call works correctly; on other days every input reads 0. The temporary fix used in the field was to delete the call statement in FC10 and rewrite the same call statement, which restores operation for some time before the symptom recurs.

This symptom is not a compiler defect and it is not a runtime fault in the strict sense. It is one of three underlying mechanisms:

1. The FB instance being monitored in STEP 7 is not the instance triggered by the FC under inspection.
2. The CYCLE parameter of a PID block (FB41 CONT_C, FB43 PULSEGEN) is misaligned with the actual OB3x interrupt interval, producing apparent zero inputs through the cascade.
3. The instance DB has an online/offline TIMESTAMP mismatch that masks the parameter transfer until the FB is recompiled and the instance DB is reinitialised.

This article walks through each root cause, the diagnostic procedure that distinguishes them deterministically, and the corrective actions validated against STEP 7 V5.6 and TIA Portal V18 through V20 documentation. It assumes familiarity with the SIMATIC block model but starts with the call-by-value versus call-by-reference distinction that is central to the diagnosis.

Call Semantics: Why FC and FB Inputs Behave Differently

FC parameters are passed call-by-value. The user program copies the value of each actual parameter into the FC's local IN, OUT and IN_OUT stack area at the moment the FC is called. The FC receives its own copy and any modification the FC performs is invisible to the caller. FB parameters, in contrast, are passed by reference through the FB's instance DB: the IN parameters are read from the instance DB's IN area, and the STAT fields retain their state across scans. This contract is documented in the TIA Portal block documentation, which states that the user program passes FC parameters as call-by-value for simple data types such as INT, DINT and REAL, while FB parameters are bound to the instance DB.

This semantic distinction matters for the symptom: when the FC call site shows a value of 50.0 for an input, the FC truly has 50.0 in its local stack. When the FB monitor shows 0.0 for the same parameter, the FB's instance DB area for that parameter reads 0.0. Either the parameter was never written into the instance DB, or the monitor is reading a different instance DB. Both possibilities are diagnostic leads.

Root Cause Analysis

Cause 1: Wrong Instance Being Monitored

SIMATIC FBs are instantiated by their Instance DB. A single FB source compiled once can produce dozens or hundreds of independent Instance DBs, each with its own IN, OUT, IN_OUT, STAT and TEMP state. STEP 7 does not automatically know which call path you want to inspect when you open an FB in online monitor mode; it selects the first active instance it encounters in the online call stack or the instance specified in the project tree.

When FB2 is called from twenty different locations and FC10 is one of them, opening FB2 in monitor mode often shows the instance belonging to a different caller (a cyclic OB1 segment, for instance, rather than the FC10 path). The IN parameters of that instance legitimately read 0 because that caller is passing 0 in that scan. The FC10 call site, visible in FC10's monitor window, is correctly transferring its own values into a different Instance DB. The discrepancy is a viewer artefact, not a code defect.

The call environment mechanism (German: Aufrufpfad) is the STEP 7 feature designed specifically to resolve this ambiguity. In STEP 7 V5.x the function is invoked via the menu path Debug > Call Environment (or the corresponding toolbar button). The dialog that opens lists every active call chain that currently invokes the block. Selecting the chain that includes FC10 forces the FB monitor view to evaluate the IN, OUT and STAT fields of the instance DB owned by that chain. In TIA Portal the equivalent function is reached via the right-click context menu on the Instance DB or on the FB header in the call tree: Call path lists every call path that is currently active, and selecting the FC10 to FB2 path synchronises the monitor view to that instance.

The diagram illustrates the trap. The default FB2 monitor binds to whichever instance it discovers first. If Instance B (DB71) is discovered before Instance A (DB70), the engineer inspects DB71 and reads 0, even though DB70 received the correct values from FC10.

Cause 2: CYCLE Parameter Mismatch with OB3x

The Standard PID Control library blocks shipped with STEP 7 (FB41 CONT_C, FB42 CONT_S, FB43 PULSEGEN, FB58 TCONT_CP, FB59 TCONT_S) implement discrete-time PID algorithms with an internal sample-time reference. The algorithm uses the CYCLE input to scale its integral and derivative actions so that a step change in setpoint produces the same closed-loop response regardless of how often the block is called. If CYCLE does not equal the actual elapsed time between two successive calls, the controller will integrate too fast or too slowly, derivative-filter incorrectly, or stall on internal state because the assumed time quantum never elapses.

The most common failure mode in the field is a configuration where OB35 is set to 1000 ms but the developer writes CYCLE := 0.1 (100 ms) or leaves CYCLE at the default value 1.0 s on a 100 ms OB. The visible symptom on the FB inputs is the secondary effect: the block's internal PV, ER and LMN values appear frozen or erratic, and a casual inspection of the IN inputs may read 0 if the FB2 wrapper around the PID block is reading the PID outputs and feeding them back into FB2's IN inputs through a path that has not been latched in the current scan.

Siemens documentation explicitly requires that FB41 and FB43 be called in a fixed time slice. The recommended mechanism is OB3x (cyclic interrupt). The recommended CYCLE value is the OB3x period expressed in seconds. The relationship between CYCLE and the discrete integrator is:

integral_increment = error * (GAIN / TI) * CYCLE
derivative_term    = (error - error_prev) * (GAIN * TD) / CYCLE

Halving CYCLE halves the integrator increment per step and doubles the derivative response. Doubling CYCLE saturates the integrator twice as fast and increases overshoot. The closed-loop characteristic equation therefore shifts with CYCLE, and an under-sized CYCLE produces the visual impression of a stalled block.

Cause 3: Instance DB Online/Offline TIMESTAMP Mismatch

Each Instance DB carries a structural fingerprint inherited from its parent FB plus a TIMESTAMP that must match the FB's interface TIMESTAMP. When the FB is modified, recompiled and downloaded without reinitialising the Instance DB, the runtime treats the structure as if it were the old version. The result is unpredictable: parameter offsets can drift by 2, 4 or 6 bytes depending on which fields were inserted or removed, and parameters that used to land at byte offset 4 in the old DB may now land at offset 8 while the FC still writes to offset 4. The Instance DB then contains either a copy of the old values or zero-initialised values for fields that did not exist in the prior version.

This drift is invisible at the FC call site because the FC's view of the FB is always read from the freshly compiled call interface. The Instance DB, however, is loaded from the CPU's online image, which can be several revisions behind if the engineer has hot-swapped the FB code without resetting the Instance DB.

The classic observation in the field is the one reported: deleting the call statement and rewriting the same call statement makes the symptom disappear, only to return two days later. Deleting and rewriting the call forces a recompile of the FC and, in many setups, an implicit reinitialisation of the Instance DB through the implicit download. Two days later another edit cycle or an OB re-trigger exposes the same desynchronisation. The fix is not durable because the underlying instance DB has not been explicitly reinitialised in the source project.

Diagnostic Procedure

Use the following checklist in order. Each step eliminates one root cause with a deterministic verdict.

1. Confirm the symptom in FC10 monitor. Open FC10 online, locate the FB2 call instance and capture the IN input values. Note the Instance DB number (DB70 in the example).
2. Open FB2 monitor with the default view. Record the IN values. If they match FC10 the problem is solved. If they read 0, proceed to step 3.
3. Switch to call environment monitoring. In STEP 7 V5.x use Debug > Call Environment and select the call chain that includes FC10. In TIA Portal right-click the FB2 instance and select Call path, then choose the FC10 entry. Re-check the IN values.
4. If the values are still zero after switching the call environment, verify the TIMESTAMP of the Instance DB matches the FB. Open the Instance DB properties and compare with the FB properties. A TIMESTAMP mismatch requires reinitialising the Instance DB.
5. If the values become non-zero after step 3 the original observation was a viewer artefact. Document the workflow so the next engineer knows to use the call path feature.
6. If FB2 wraps a PID block (FB41, FB43), cross-check the CYCLE parameter against the OB3x configuration. Open the CPU properties, select the cyclic interrupt OB (OB35) and read the period. Compare with the literal in the CYCLE input of FB41 or FB43.
7. Capture the OB3x execution log. Use the diagnostic buffer (Online > Accessible Nodes > Module Information > Diagnostic Buffer) to verify that the OB3x is executing at the configured interval and is not being delayed by higher-priority OBs.
8. Check the diagnostic buffer for programming errors. A TIMESTAMP drift severe enough to write outside the instance DB triggers OB121 (programming error). Entries such as "Area length error when reading", "Block not valid" or "DB no. 70 / area length error" confirm the third root cause.

Solution 1: Enable Call Environment Monitoring

The call environment feature exists in both STEP 7 V5.x and TIA Portal but the menu paths differ. The procedure for STEP 7 V5.6 is as follows.

1. Open the FB online: double-click the FB in the project tree, then Online > Monitor On/Off.
2. From the menu bar select Debug > Call Environment. The Call Environment of Block dialog opens.
3. The dialog lists all call paths from which the FB is currently invoked. If the FC10 path is not visible, click Update to re-scan the call stack.
4. Select the row whose chain reads OB35 > FC10 > FB2 [DB70].
5. Click OK. The FB monitor view now binds to Instance DB70 and shows the parameters as they exist inside that specific instance.

In TIA Portal V18 and later, the equivalent flow is:

1. Open the FB in the project tree.
2. Click Go online and select Monitor on/off.
3. In the program editor the active call path is displayed at the bottom of the window. Right-click the path and select Change call path.
4. Choose the call site corresponding to FC10. The monitor view updates immediately and the instance DB number is shown in the status bar.

The TIA Portal variant has a useful enhancement: the call path indicator shows the recursion depth and the data block number, which eliminates the need to manually match the Instance DB to the call site. The Siemens SIMATIC S7-1200/S7-1500 programming reference documents this behaviour under the section "Calling blocks" in the TIA Portal help portal.

Solution 2: Align CYCLE with OB3x Interval

The Standard PID Control block library (FB41, FB42, FB43, FB58, FB59) is documented in the STEP 7 Standard Library reference. The CYCLE parameter must equal the time between two successive calls expressed in seconds. The table below summarises the recommended values for the most common OB3x configurations on an S7-300/400 CPU. S7-1500 cyclic interrupts share the same period mapping.

To set the value, locate the FB41 instance in the calling FB (FB2 in this article) and update the CYCLE input to match the OB3x period divided by 1000. The reference literal at the call site should be self-documenting:

CALL FB41, DB71
   SP_INT  := #rSetpoint
   PV_IN   := #rProcessValue
   GAIN    := #rGain
   TI      := #rResetTime
   TD      := #rDerivTime
   CYCLE   := 0.1    // OB35 = 100 ms; do not edit without updating OB35 period

If FB41 is called multiple times in the project, this correction must be applied to every instance. The same rule applies to FB43 PULSEGEN, which derives its minimum pulse width from the CYCLE value. A representative calculation for FB43:

minimum_pulse_width = CYCLE / PER_TM
where PER_TM = pulse period in seconds

If CYCLE is 1.0 and PER_TM is 20 s, the minimum pulse width is 50 ms. If CYCLE is incorrectly 0.1, the minimum pulse width becomes 5 ms and the output transistor never reaches a stable duty cycle because the output module cannot toggle faster than its filter constant.

Solution 3: Re-initialise the Instance DB

When the Instance DB and FB TIMESTAMPs diverge, the only safe recovery is to reinitialise the DB. Two methods are available.

1. Reset via STEP 7 menu. Open the Instance DB online, then select Online > Reset Instance DB (STEP 7 V5.x) or Online > Reinitialise instance data block (TIA Portal). Confirm the prompt. The DB retains its number but every STAT field is restored to the FB's initial value, and the TIMESTAMP is updated.
2. Delete and recreate. Right-click the Instance DB in the project tree, delete it, then re-insert the FB call with the same DB number. Download the project. The new DB carries the current TIMESTAMP.

The recommended best practice is to enable the option "Update Instance DBs" in the download dialog of TIA Portal or to use Compile and download objects in STEP 7 V5.x. This option forces the engineering station to mark every dependent instance DB for reinitialisation at download time, eliminating the manual reconciliation step.

Verification

After applying the corrective action, run the following verification sequence.

1. Bring the CPU to STOP, then RUN. Confirm a clean restart with no OB121 entries in the diagnostic buffer.
2. Open FC10 online and confirm the FB2 call inputs read the expected values.
3. Open FB2 online using the call environment dialog, select the FC10 call chain, and confirm that the same values appear on the IN inputs of the FB instance.
4. Force a parameter change at the FC10 call site (write 50.0 to SP_INT for example) and confirm the FB instance receives the new value within one OB3x cycle.
5. For PID applications, perform a step response test. With the loop in manual, set MAN to 50 percent, switch to automatic and record the PV trend. Confirm the response time matches the expected TAU = TI / (1 + GAIN) approximation, which only holds if CYCLE is correct.
6. Inspect the diagnostic buffer for OB3x priority-class errors, scan time overruns or OB85 entries. None should be present.
7. Force a CPU restart (STOP/RUN) and confirm that the FB instance initial values populate the instance DB as expected. This validates the reinitialisation.

PID Block Specific Considerations

When FB41 or FB43 is wrapped inside a multi-purpose FB such as FB2, the wrapper often performs a context-dependent selection of setpoint, process value and limits. The symptom of zero inputs at the FB level can be exacerbated if the wrapper reads a non-volatile setpoint from a global DB and the global DB has not been initialised. The chain then looks like this:

OB35 (100 ms) > FC10 > FB2 [DB70] > FB41 CONT_C [DB71]
                      |
                      +-- reads from DB100.rSetpoint
                      +-- reads from DB100.rPV

If DB100 has not been downloaded with non-zero values, every FB41 input that derives from DB100 reads 0 even though FB2 received correct values from FC10. Always verify that all referenced data blocks are loaded with their intended initial values before debugging the call chain itself.

For FB43 PULSEGEN specifically, the CYCLE parameter controls the minimum pulse width. If CYCLE is too large relative to the desired output pulse width, the output will be permanently OFF (or permanently ON for a saturated input), which is easy to misread as "the FB inputs are zero." A quick sanity check is to monitor the LMN output of FB41 and the QPOS_P / QNEG_P outputs of FB43. If LMN is non-zero and QPOS_P is permanently FALSE, the CYCLE parameter is at fault, not the input wiring.

FB41 also requires that the MANUAL/AUTOMATIC switch (MAN_ON) be evaluated. When MAN_ON is TRUE the controller ignores SP_INT and uses MAN. If MAN is 0 and the loop appears dead, the operator has probably left MAN_ON at TRUE from a previous manual session.

Prevention: Coding Standards

The following standards, drawn from the STEP 7 programming style guide and the TIA Portal block best-practice documentation, prevent recurrence of the symptom.

• Place all cyclic FBs (PID, motion, sampling, integrator) inside an OB3x. Never invoke them directly from OB1 with conditional logic.
• Document the CYCLE parameter as an explicit literal at the call site, with a comment stating the OB period: CYCLE := 0.1 // OB35 = 100 ms.
• Restrict the call environment to a single instance per FB unless multi-instance is intentional. A single Instance DB eliminates the "wrong instance" confusion entirely.
• Use multi-instance FBs (FB-in-FB) when a wrapper needs an internal instance of FB41. The TIMESTAMP is then managed by the parent FB and reinitialisation is centralised.
• After every FB modification, perform Check block consistency and download all dependent Instance DBs in the same session.
• Enable "Update Instance DBs" in the TIA Portal download dialog or use Compile and download objects in STEP 7 V5.x. This avoids the manual DB reinitialisation cycle that produces the intermittent failure.
• Adopt a naming convention that ties the Instance DB number to the calling FB: DB70 for FB2 callers, DB71 for FB41 inside FB2, etc. The number itself becomes a debugging hint.
• Document the call chain in the FB header comment so a future engineer can identify the call environment without browsing the entire project.

Troubleshooting Matrix

Frequently Asked Questions