Troubleshoot a CFC PV Input Showing Zero While Its Connected Output Is Nonzero

A custom CFC block showing PV = 0 while its connected selector output shows 18.29 needs an instance-level diagnosis, not an assumed CFC bug. Compare the actual online parameters, connection and runtime calls, inspect existing forcing, and review the custom block's declaration and assignments. CFC V9.0 SP5 documents that forcing can replace a connected input value and can write back through an INOUT. That is a verified mechanism to check, but it is not a confirmed cause in this case.

Establish Which Values Are Being Compared

The reported observation is a selector output of 18.29 connected to a custom block's PV input, while that input displays 0. Other instances of the same custom block work. Simulation and alarm settings remain operable, but neither observation proves that this particular input is receiving and retaining the expected value.

Before changing the program, confirm the exact AS, block instance, compiled/downloaded project and parameter being monitored. Compare the online source output, destination PV and any faceplate tag separately. An OS display value and a CFC online parameter are different observation points.

Check the Exact Interconnection and Runtime Calls

Use a preserved project copy for the engineering review:

Inspect the actual connection endpoint, data type and any structured member. A line drawn near PV is not a sufficient check of the intended member and source.
Confirm that the selector and custom block are in the intended compiled/downloaded program.
In CFC, select Edit > Run Sequence... and inspect their task, group and insertion positions.
Check whether either call is disabled, scheduled at another interval or present at an unintended additional insertion point.
Compare the failing instance with a working one using the same verified block version.

These are diagnostic comparisons, not a confirmed explanation for the zero. Run-sequence and instance differences must be observed before they are treated as causes. CFC V9.0 SP5 manual, chapter 10.11

Inspect Existing CFC Forcing

CFC V9.0 SP5 documents forcing as replacement of an interconnected input's normal value with a configured force value. That provides a specific mechanism to inspect when the source and input disagree.

In the block input's object properties, inspect Add forcing, Forcing active and Force value if the chart folder supports forcing. The documented display uses a red rectangle when forcing is added and active; a green rectangle indicates it is added without being active.

For INOUT, the manual states that the force value is also written to the connected block's output. This behavior is more specific than a claim that every output-to-INOUT connection has a product bug.

Inspect existing settings only. Do not enable forcing or remove an operational force without authorization for the actual process. Manual, chapter 14.3, pp. 396–397

Review the Custom Block Source

Determine whether PV is declared as IN, IN_OUT or another actual interface form. Compare the compiled type used by the failing instance with its intended source and a working instance.

Review assignments to PV and any internal value used by the faceplate, including initialization, simulation selection and reset branches. Also review external writes that could affect an IN_OUT target or the displayed OS value. A source-level write or branch must be identified before calling it an overwrite fault.

No exact CFC release, custom source, screenshot or verified historical defect entry was provided. Do not replace the diagnosis with an assumed version bug or change the interface solely because an IN_OUT exists.

Verification

After identifying and correcting an actual mismatch in an isolated test, observe the selector output and destination input under several controlled values, including zero and a nonzero value. Confirm the expected downstream calculation and the correct faceplate value.

Verify the intended runtime calls and force state again. A temporary match at one value does not establish that initialization, simulation selection or later execution will preserve the intended behavior.

Limitations and Operational Precautions

The exact block implementation and root cause remain unverified. The forcing mechanism and editor controls here are scoped to CFC V9.0 SP5 and must be checked against the installed release.

Preserve the project, force settings and running configuration. An interface/type change, recompilation or AS download can affect dependent instances and requires a reviewed deployment and rollback plan. Do not bypass process interlocks or manipulate a live PV merely to test whether the display changes.

Engineer FAQ

Does the mismatch prove that CFC failed to transfer the signal?
No. First distinguish observation point, connection, runtime scheduling, forcing and custom-code behavior.

Does an IN_OUT declaration prove a software defect?
No. Its actual use and writes must be inspected; no applicable defect or corrective update was established.

Technical References

Siemens — CFC for SIMATIC S7 V9.0 SP5, November 2020, A5E41356073-AF — chapter 10.11 runtime sequence; chapter 14.3 interconnected-input forcing, indicators and INOUT writeback.

CFC connected input value mismatch

Troubleshoot a CFC PV Input Showing Zero While Its Connected Output Is Nonzero