Siemens SCL: Calling Function Blocks from OB1 Source Files

Overview

The most common beginner failure in Siemens SCL (Structured Control Language) for the S7-300/S7-400 family is writing a syntactically valid organization block that compiles but never executes user logic. The classic symptom: a function block is declared, an instance DB is generated, and the OB calls it as FB10.DB10(); with no parameters and no body in the call site. The block goes through cyclic OB1 execution, the CPU is in RUN, and yet the outputs never change. This article documents the correct SCL source-file pattern for calling an FB from OB1, the role of the instance DB, and how parameter passing works under the hood.

Audience: engineers who program Step 7 V5.x in SCL, who edit .scl source files by hand or via the SCL Editor, and who need predictable cyclic execution of a self-written FB from OB1.

Prerequisites

• Step 7 V5.5+ or compatible SCL Compiler (SCL V5.3 SP6 or later recommended for S7-300/400).
• Configured S7-300 or S7-400 station in SIMATIC Manager with a CPU 314/315/317/319 or 412/414/416/417.
• S7 Program with at least one source file container in the S7 project's Sources folder.
• Working knowledge of SCL keyword blocks: FUNCTION_BLOCK, DATA_BLOCK, ORGANIZATION_BLOCK, VAR_INPUT, VAR_OUTPUT, VAR, VAR_TEMP.
• Reference: SCL for S7-300/400 Programming Manual (entry ID 109751606).

Why the OB1 Source Compiles but Does Nothing

The SCL compiler treats an empty parameter list on an FB call as legal. It does not warn that the FB will execute with the initial values declared in its VAR / VAR_INPUT sections. If the engineer writes:

ORGANIZATION_BLOCK OB1
VAR_TEMP
  info : ARRAY[0..19] OF BYTE;
END_VAR

FB10.DB10();
END_ORGANIZATION_BLOCK

the call is interpreted as: execute FB10 using the instance DB10, take all inputs from their stored instance values, do not write any inputs from process images, and discard the outputs back to the instance. When the FB is purely combinational and reads its inputs only from VAR_INPUT, this means the logic runs once with whatever the instance DB last held — typically all zeros — and never reflects I0.0, I0.1, etc.

The OB1 template that the SCL compiler generates from Insert > Block > Organization Block contains the VAR_TEMP info : ARRAY[0..19] OF BYTE; reserved area (20 bytes required by the S7-300/400 system software) but no logic. Engineers often copy that template and add a single line, expecting it to "just work."

Reference: SCL Source File Structure for an FB + Instance DB + OB1

The minimal complete SCL source file that compiles and runs is shown below. The three blocks must coexist in the same compilation unit; the SCL compiler resolves the cross-references between FB, DB, and OB during the Compile step.

FUNCTION_BLOCK FB10
VAR_INPUT
  START : BOOL;
END_VAR
VAR_OUTPUT
  RUN   : BOOL;
END_VAR
VAR
  // Static (instance) variables
END_VAR
BEGIN
  RUN := START OR RUN;        // latching logic, classic seal-in
END_FUNCTION_BLOCK

DATA_BLOCK DB10  FB10
//
// Block Comment...
//
BEGIN
END_DATA_BLOCK

ORGANIZATION_BLOCK OB1
VAR_TEMP
  // Reserved
  info : ARRAY[0..19] OF BYTE;
  // Temporary Variables
END_VAR

FB10.DB10(
  START := I0.0,
  RUN   := Q0.0);
END_ORGANIZATION_BLOCK

Step-by-Step: Building and Calling the FB in OB1

1. Create the source container. In SIMATIC Manager, right-click the S7 program's Sources folder, choose Insert New Object > SCL Source. Name it (e.g., MainProgram).
2. Declare the FB interface. In the source, write the FUNCTION_BLOCK FB10 header. Declare START : BOOL under VAR_INPUT, RUN : BOOL under VAR_OUTPUT. Place any internal latches in VAR (these become instance-DB-resident static variables).
3. Write the FB body. The BEGIN ... END_FUNCTION_BLOCK section holds the actual algorithm. For a seal-in: RUN := START OR RUN;. The static instance variables persist across calls — this is the whole point of an FB versus an FC.
4. Declare the instance DB. DATA_BLOCK DB10 FB10 tells the SCL compiler to generate DB10 with the layout of FB10. The body can be empty; the compiler fills it from the FB declaration.
5. Call from OB1 with explicit parameters. Use positional or named assignment. Named assignment is preferred because it is self-documenting and order-independent:

   FB10.DB10(
     START := I0.0,
     RUN   := Q0.0);

6. Compile the source. Right-click the source file in SIMATIC Manager and choose Compile > All (or use the SCL Editor's Compile > Selected Objects). Check the compiler output window for errors such as Unknown identifier or Type conflict.
7. Download the blocks. In SIMATIC Manager, select the Blocks container and download to the target CPU. After download, perform a Cold Restart only if the DB initial values need to be reset; a warm restart is sufficient to load the new logic.
8. Verify in Monitor/Modify. Open FB10 in the LAD/FBD/STL editor, switch to Monitor mode, and toggle I0.0 on the simulator or in the process. Q0.0 should latch when I0.0 is pulsed true.

How Parameter Passing Actually Works

Siemens SCL compiles an FB call into a sequence of STL-like operations. For FB10.DB10(START := I0.0, RUN := Q0.0), the compiler generates code that:

1. Copies the value of I0.0 into the START slot of instance DB10.
2. Calls the FB10 code with DB10 as the instance base register (DI/DB register pair).
3. Inside the FB, the body RUN := START OR RUN; resolves as DB10.RUN := DB10.START OR DB10.RUN; — note the right-hand RUN reads the previous latched value, and the left-hand RUN writes the new value back to the instance.
4. On return, the compiler copies DB10.RUN to the assigned actual parameter Q0.0.

If the engineer writes FB10.DB10(); with no parameters, step 1 is skipped for inputs and step 4 is skipped for outputs. The FB executes but uses the instance DB's stored values verbatim. Because the S7-300/400 clears newly generated instance DBs to zero on download, the latching expression RUN := START OR RUN always evaluates to 0 OR 0 = 0. The output stays at zero forever.

Positional vs. Named Syntax

SCL accepts both styles. Positional:

Named (recommended for readability and maintenance):

FB10.DB10(
  START := I0.0,
  RUN   := Q0.0);

When the FB has multiple IN/OUT/IN_OUT parameters, the named form prevents the silent-miswire class of bug. Mixed forms are permitted; trailing parameters can be omitted by name with the := syntax.

Common Errors and Their Compiler Diagnostics

Verification Checklist

• Compile clean. No errors, no warnings in the SCL output window.
• Blocks visible. Blocks > FB10, DB10, OB1 are present in the S7 program container.
• DB10 has the right layout. Open DB10 in the LAD/FBD/STL editor. It must show START and RUN as BOOLs of the instance view, not as blank bytes.
• Online monitor. In Monitor/Modify, force I0.0 = 1. Q0.0 should follow on the first scan, then stay latched when I0.0 returns to 0. DB10.RUN must mirror Q0.0.
• Watch the OB1 call site. In online Monitor on OB1, the FB10.DB10(START := ...) line shows the current input and output values in the right-hand pane.
• Diagnostic buffer clean. CPU > Diagnostic Buffer shows no OB1 stack overflow, no Unknown FB, no Type conflict in instance DB.

Alternative Patterns: Passing Parameters via Move Instructions

Some legacy SCL code populates the instance DB inputs with explicit := assignments to the DB symbol before the call:

ORGANIZATION_BLOCK OB1
VAR_TEMP
  info : ARRAY[0..19] OF BYTE;
END_VAR

DB10.START := I0.0;       // pre-fill instance input
FB10.DB10();              // call without parameter list
Q0.0 := DB10.RUN;         // copy instance output to process image
END_ORGANIZATION_BLOCK

This pattern works and is sometimes preferred for code generation from external tools because the call line itself has no parameters. The trade-off: you lose the type checking that named parameter assignment provides. A misspelled symbol on the DB10. line fails to compile, but it does not warn about the loss of the latched state across a re-download with a "warm restart only" reset.

Migrating the Same Pattern to S7-1200/1500 / TIA Portal

The SCL syntax is essentially identical, but the surrounding conventions differ:

• OB1 in S7-1200/1500 is the main cyclic OB, generated by default as Main [OB1]. The VAR_TEMP info : ARRAY[0..19] OF BYTE; reserved area is not required on S7-1500 — TIA Portal's SCL compiler manages the start information internally.
• Instance DBs are single-instance or multi-instance; for single-instance the call is "MyFB"(START := I0.0, RUN := Q0.0); with the DB name as a string, or the call is implicit when the FB is inserted as a multi-instance under another FB.
• The optimization of the RUN := START OR RUN pattern is best implemented as RUN := RUN OR START; to keep the right-hand RUN in the instance-DB static area on S7-1500 as well. See the SCL for S7-1200/1500 (entry ID 109751608) manual, section 3.5, for parameter-passing semantics.

Field-Proven Caveats

• Initial values vs. actual values. The instance DB retains its last values across CPU warm restart unless the engineer explicitly reinitializes. For latching logic, this is usually desirable. For startup-into-safe-state designs, the FB body must explicitly clear RUN := FALSE on first scan using an OB100 or a one-shot FirstScan flag.
• Re-download of a single FB. If you re-download only FB10 and the FB interface changed (new VAR_INPUT added), DB10 must also be re-initialized. SCL's Compile > All handles this; a manual block download does not. See FAQ: "After changing the FB interface the instance DB is not updated" (entry ID 15364459).
• Block consistency offline. When using the SCL source-file approach, the offline Blocks container is populated only by the SCL compiler. Editing FB10 in the LAD/FBD/STL editor after a SCL compile will cause a "block was changed externally" message the next time you compile the source. Decide on one source of truth (SCL source file) and stick to it.
• Cyclic time. The S7-300 OB1 call from the SCL source generates a call tree that the compiler tries to optimize. If OB1 calls FB10 which calls FB11, the cyclic time grows. The SCL manual recommends measuring with CPU > Module Information > Scan Cycle Time after every change.

Quick Reference: OB1 SCL Template (Copy-Paste)

ORGANIZATION_BLOCK OB1
VAR_TEMP
  // Reserved for S7-300/400 system software (do not remove)
  info : ARRAY[0..19] OF BYTE;
  // User temporary variables
  nScanCount : INT;
END_VAR

// --- cyclic logic begins here ---
FB10.DB10(
  START := I0.0,
  RUN   := Q0.0);

nScanCount := nScanCount + 1;
// --- end cyclic logic ---
END_ORGANIZATION_BLOCK