Troubleshoot Unexpected SCL Function Results as FC Calls Increase in PCS 7

If an SCL FC returns inconsistent values only after more calls are added inside an FB, do not assume that the local data stack is the cause. First verify every call's actual parameters, return/status handling and initialization of temporary values, then inspect CPU diagnostics and the compiled call structure for local-data allocation or nesting problems. The reported PCS 7 case lacks the CPU, versions, code and diagnostic buffer, so it does not establish a single root cause.

What the Symptom Establishes

The original report says the FCs worked when tested separately, compile completed without warnings or errors, and results appeared unpredictable after more calls were added in FB logic. That narrows the investigation to the integrated execution context but does not identify whether the defect is in call parameters, data initialization, shared state, execution order, local-data allocation or another runtime interaction. “Random” describes the observation; it is not a diagnostic result.

Check Inputs, Outputs and Temporary Data First

Compare each FC call site with its interface: confirm that actual input and output operands have the intended type, address and lifetime; check that return/status values are captured and interpreted consistently; and verify that every value read on every execution path has been assigned first. In particular, do not rely on an FC TEMP variable retaining a previous call's value. Test repeated invocations with distinct known inputs and trace the input, intermediate and output values at each call boundary.

Check Call Structure and Local Data

Siemens STEP 7 documentation describes local data allocation per priority class and permits configuring local-data amounts for S7-400 CPUs. The S7-300/400 system-function documentation identifies local-data allocation errors and excessive block-call nesting as execution-abort causes reported through OB88. These facts make local-data exhaustion or excessive nesting a diagnostic possibility, not a conclusion from the symptom alone. Repeated FC calls can affect execution and temporary storage demand, but the source reply's statement that each FC call stores all FB variables on the stack is not supported by the available Siemens documentation and should not be used as the diagnosis.

Diagnostic Procedure

Record the exact CPU order number, firmware, STEP 7 and PCS 7 versions, compiler messages, affected OB and any OB88 or diagnostic-buffer events.
Compare the known-good and failing versions of the call structure. Count nesting depth and identify which OB/priority class executes the FB and FCs.
At each call site, log or monitor the input values, relevant global/DB state, returned outputs and status. Check for aliasing or reused output destinations that cause later calls to overwrite earlier results.
Audit all FC execution paths for reads of unassigned TEMP variables, missing assignments, conditional outputs and implicit assumptions about prior-call contents.
If the CPU diagnostics or compilation data indicate local-data pressure, check the configured allocation for the applicable priority class and the documented requirements for the exact CPU. Do not increase stack allocation speculatively or move blocks to a different OB without evaluating timing and interrupt behavior.
Change one factor at a time in a backed-up test project, compile and validate the result under representative call frequency and interrupt load before deployment.

Why Moving a Block to a Slower OB Is Not a General Fix

The source reply speculates that a slower OB could be interrupted by a faster OB and require additional local data. Although interrupt execution and priority-class local data are relevant to S7-400 resource planning, changing task assignment also changes execution timing and process behavior. No evidence in the source establishes that moving this FB to another OB prevents the reported inconsistent outputs. Treat task reassignment as a project-specific redesign requiring timing analysis and validation, not a stack workaround.

Expected Results and Verification

A diagnosis should explain the observed values at call boundaries and match CPU/compiler diagnostics. For a data-flow defect, corrected assignments or parameter wiring should produce the expected output for each controlled input vector. For a resource limitation, the CPU's documented diagnostics or configured local-data use should support that conclusion, and the corrected project should execute without the corresponding event while maintaining application timing. A clean compile alone does not prove runtime correctness.

Verification

Repeat the same input sequence with the original and corrected call structure in a test environment. Inspect each call's inputs, outputs and status, along with relevant DB state and CPU diagnostic information. Exercise paths that previously produced inconsistent results and include the applicable interrupt workload. Confirm the function contract, not merely that the CPU remains in RUN.

Limitations and Operational Precautions

The source omits CPU model, exact versions, FC/FB code, call count, OB assignment, memory configuration and CPU diagnostic data. Siemens manual PDFs were discoverable but could not be opened during this research because the document host returned HTTP 403; their indexed excerpts support the narrow local-data and OB88 points, but exact CPU-specific instructions need confirmation in an accessible, applicable manual. Do not increase local-data allocation, restructure interrupt assignments or download changes to a production CPU without backup, impact assessment, controlled validation and a rollback plan.

Engineer FAQ

Does adding FC calls prove local-data overflow? No. The symptom can have other causes, including incorrect parameters, overwritten destinations or values read before assignment. Use code review and CPU diagnostics to discriminate.

Can an FC TEMP variable be used to retain a value between calls? Do not rely on that behavior. Assign every value before reading it in each execution path; use an explicitly persistent storage mechanism when persistence is required and appropriate.

What Siemens diagnostic points toward local-data allocation? The S7-300/400 system-function documentation identifies local-data allocation errors and excessive block-call nesting among execution-abort causes reported through OB88; check the exact CPU's applicable diagnostics.

Should local data be increased immediately? No. First establish a local-data limitation from CPU/compiler evidence and check the correct priority class and CPU manual. A speculative adjustment can obscure the actual programming defect.

Can moving the FB to a slower OB resolve inconsistent values? It is not established as a general fix. It changes scheduling and may alter timing; verify the specific project and process requirements.

Technical References

Siemens, Programming with STEP 7, Manual, 04/2017, A5E41552389-AA, §4.2 “Blocks in the User Program”; indexed text describes temporary local data and configurable local data per priority class on S7-400. The PDF returned HTTP 403 when opened: https://support.industry.siemens.com/cs/attachments/download/109751825/STEP_7_-_Programming_with_STEP_7.pdf
Siemens, System Software for S7-300/400 System and Standard Functions, Volume 1/2: Organization Blocks, Reference Manual, 04/2017, A5E41675609-AA; indexed OB88 description lists excessive block-call nesting and local-data allocation errors. The PDF returned HTTP 403 when opened: https://support.industry.siemens.com/cs/attachments/109751826/STEP_7_-_System_and_Standard_Functions_for_S7-300_and_S7-400.pdf