F-Call Block Placement in SIMATIC Safety: OB1 vs Cyclic OB

Overview

The F-Call block is the entry point for the safety program in a Siemens SIMATIC S7-300F/400F (S7 Distributed Safety) or S7-1500F (SIMATIC Safety in TIA Portal) controller. Unlike standard user code, the F-Call must be executed inside a cyclic interrupt organization block (OB3x), not in OB1. This article covers the three engineering reasons behind that constraint, the configuration parameters that govern it, the sizing formulas, and the verification steps used by field engineers to confirm correct placement.

What the F-Call block does

The F-Call block is a special function call that:

• Invokes the F-runtime group FB, which contains the actual safety program (F-FBs, F-FCs, F-DBs, F-I/O DB).
• Provides a deterministic execution context with priority higher than OB1.
• Allocates the F-local-data area in which the safety program stores its temporaries, instance data, and passivation state.
• Enforces the F-monitoring time, the upper bound for a complete safety program cycle.

Per SIMATIC S7 Distributed Safety - Configuring and Programming, the F-Call is the only legal interface between the standard user program and the F-runtime group.

Why the F-Call Belongs in a Cyclic Interrupt OB

Three firmware-level constraints in the S7 CPU make OB3x mandatory; OB1 is not adequate for any of them.

1. Priority of the execution context

OB1 runs at priority class 1, the lowest priority in the S7-300/400 and S7-1500. Cyclic interrupt OBs OB30 through OB38 run at priority 7 to 24 (S7-300/400) or 2 to 24 (S7-1500, configurable). Because the F-runtime group must not be preempted by standard program execution beyond the configured F-monitoring time, it must run at a higher priority than OB1. The F-Call is placed in a cyclic interrupt OB whose priority exceeds the priority of any other OB that may legitimately preempt it.

OB priority and cycle in S7-300/400

OB	Type	Default priority	Default cycle
OB1	Main cyclic	1	Free cycle
OB10	Time-of-day	2	Configured
OB20	Delay	3–6	Configured
OB30	Cyclic interrupt	7	Configurable 1-60,000 ms
OB35	Cyclic interrupt	12	Configurable, default 100 ms
OB38	Cyclic interrupt	24	Configurable 1-60,000 ms

The F-Call is placed in OB35 by default because 100 ms cycle with priority 12 leaves ample headroom for typical F-runtime groups and keeps the F-monitoring time budget intact. TIA Portal's SIMATIC Safety application allows any cyclic interrupt OB; STEP 7 S7 Distributed Safety defaults to OB35.

2. F-local-data size

Safety blocks consume more local data than standard blocks because every F-FB/F-FC must duplicate its inputs for cross-checking, store passivation state, and hold signature information. The standard OB1 local-data stack on an S7-300F is fixed; a cyclic interrupt OB has its own local-data stack whose maximum size is configured in the CPU properties (HW Config → CPU → Local Data). On the S7-300F, the maximum local-data area per priority class is configured in the Local Data dialog and must be sized to hold the F-runtime group stack frame. Failing to size it correctly causes a priority-class error and an F-CPU STOP.

To size it: in HW Config open the CPU, select the Local Data tab, find the priority class of the cyclic interrupt OB hosting the F-Call, and increase the Local data (bytes) value to the size reported by the safety program generator (visible in the safety program properties or in the F-CPU diagnostic buffer after download). On the S7-1500F this is automatic; the safety program generator reserves local data in the priority-class table.

3. F-monitoring time and cycle determinism

The F-monitoring time is the maximum interval between two successive calls of the F-runtime group. If the second call is later than F-monitoring time, the F-CPU assumes the safety program is no longer executing within budget and transitions the affected F-shutdown groups to PASSIVATED, then to STOP if the fault is not cleared. Calling the F-Call from OB1 risks:

• OB1 free-cycle variance: a single long standard program scan (a recipe change, a synchronous PROFIBUS cycle, a large recipe download) can exceed the F-monitoring time and passivate the F-I/O.
• Lower priority: any OB of priority > 1 (time-of-day OB10, delay OB20, another cyclic OB30-OB38) can preempt the safety call within OB1, lengthening the safety cycle beyond the configured F-monitoring time.

Placing the F-Call in OB35 makes the safety program run at fixed intervals, independent of the OB1 free cycle. The OB35 phase offset can also be tuned to interleave safety execution with standard execution to avoid I/O-strobe collisions on PROFIsafe modules.

Configuration Parameters

Four parameters must be coordinated when placing the F-Call in a cyclic interrupt OB.

F-Call placement parameters

Parameter	Location	Typical value	Constraint
OB index	Project tree → Program blocks	OB35	OB30-OB38 (S7-300/400) or any cyclic interrupt OB (S7-1500)
OB cycle time	CPU properties → Cyclic interrupts	100 ms	Configurable 1-60,000 ms; cycle > 0
OB phase offset	CPU properties → Cyclic interrupts	0 ms (default)	Use to desynchronize multiple cyclic OBs
F-monitoring time	F-CPU properties → Safety	100 ms (default)	Must be ≥ 2 × OB cycle + F-runtime group exec time + margin
Local-data area	CPU properties → Local Data, priority class 12 (OB35)	≥ F-runtime group stack frame	Must be sized before download
F-runtime group signature	F-CPU properties → Safety → Signature	CRC of safety program	Readback-protected, used for change detection

F-monitoring time sizing formula

A conservative lower bound for F-monitoring time is:

F_monitoring ≥ 2 × T_OB_cycle + T_F_RT_max + T_margin

Where T_OB_cycle is the OB35 cycle (e.g., 100 ms), T_F_RT_max is the worst-case execution time of the F-runtime group measured under maximum process load, and T_margin is a 20-50% safety margin to absorb CPU load peaks and PROFIsafe retransmissions. With OB35 at 100 ms and a typical F-runtime group at 5-20 ms, F-monitoring time of 100 ms is the standard factory setting and is appropriate for most applications. Tighten to 50 ms only when the process safety time demands it and the F-runtime group has been profiled under full load.

Procedure: Place the F-Call in OB35

1. Open the S7 project in STEP 7 (S7 Distributed Safety) or TIA Portal (SIMATIC Safety).
2. Open the F-CPU. In TIA Portal, expand Program blocks and locate the existing OB1.
3. Add a new OB. In STEP 7: Insert → S7 Block → Organization Block, select OB35. In TIA Portal: Add new block → OB → Cyclic interrupt.
4. Set OB35 cycle. In the CPU device configuration, open Properties → Cyclic interrupts, enter the cycle (e.g., 100 ms), and apply phase offset if needed.
5. Open the new OB35. Drag the F-runtime group FB (e.g., F_RUNGR_1) from the project tree into OB35, or insert a CALL instruction to the F-runtime group FB.
6. Configure the F-runtime group. In F-CPU properties, set F-monitoring time, F-runtime group signature, and access protection password.
7. Size local data. In CPU properties → Local Data, raise the size for the OB35 priority class (12 by default) to the value reported by the safety program generator.
8. Compile and download the safety program. STEP 7/TIA will flag local-data overflows as errors; resolve them by raising the local-data area for the OB35 priority class.
9. Verify the F-runtime group is running. The F-CPU diagnostic buffer records the F-runtime group start. The safety summary in the online view shows F-runtime group: active.

STEP 7 ladder example (OB35)

OB35 : "Safety_Cyclic"
  CALL  FB 100           // F-runtime group FB
   F-MON_TIME  := T#100ms
   F-RTMGR_ID  := 1
   ACK_NEC     := I 0.0
   ACK         := Q 0.0
   Q_F_STATUS  := MW 100

TIA Portal SCL example (OB35)

// OB35 - Cyclic interrupt, 100 ms
"F_RUNGR_DB"(F_MON_TIME := T#100ms,
             F_RTMGR_ID := 1,
             ACK_NEC    := "Safety_AckNeeded",
             ACK        := "Safety_Ack",
             Q_F_STATUS => "Safety_Status");

Verification

After download, run these checks in order:

1. Diagnostic buffer. Open Online → Diagnostics → Diagnostic Buffer. Look for entries "F-runtime group started" and "Safety mode active". Any "Local data stack overflow" or "OB not loaded" entries indicate a sizing or download fault.
2. Cycle statistics. In Online → Module Information → Scan cycle time, confirm OB1 free cycle remains below 80% of OB35 cycle. If OB1 approaches F-monitoring time, reduce standard program scan or raise F-monitoring time.
3. F-monitoring time stamp. Online → Safety → F-runtime group shows the configured F-monitoring time, the maximum measured runtime, and the time of the last two calls. Maximum runtime must be strictly less than F-monitoring time.
4. Forcing test. With the safety program in RUN, force an F-I/O passivation (e.g., disconnect the PROFIsafe slot or short an F-DI). Confirm the F-CPU passivates the channel, sets the F-DB passivation bit, and resumes after the ACK_NEC/ACK handshake.
5. Priority-class check. Online → Module Information → Performance Data confirms OB35 is loaded with the expected priority and local-data size.

Common Errors and Edge Cases

Error: "OB not loaded; priority class error"

Cause: the F-Call is in OB35 but OB35 was not downloaded, or the local-data area for priority class 12 is too small. Fix: download OB35 explicitly; in CPU properties → Local Data, raise the size for priority class 12 to the value reported by the safety program generator.

Error: F-I/O passivates randomly under load

Cause: standard program in OB1 sometimes exceeds F-monitoring time, or a second cyclic interrupt OB (e.g., OB32) preempts OB35. Fix: profile OB1 with the S7-300/400 cycle-time trace, shorten long standard blocks, and adjust the phase offset of the preempting OB so it does not run concurrently with OB35.

Edge case: S7-1500F in TIA Portal

S7-1500F uses the same rule: the F-runtime group is called from a cyclic interrupt OB. TIA Portal's SIMATIC Safety application creates a default cyclic interrupt OB (OB123 or any free cyclic OB) for the F-runtime group. Local-data sizing is automatic. The F-monitoring time and F-runtime group signature are configured in the safety program settings. Reference: SIMATIC Safety - Configuring and Programming in TIA Portal.

Edge case: Multiple F-runtime groups

S7-400F and S7-1500F support multiple F-runtime groups. Each must be called from its own cyclic interrupt OB, or from the same OB if the calls are sequential and the combined runtime plus cycle fits within the F-monitoring time of each group. Never call two F-runtime groups from OB1; the priority and local-data sizing constraints of the second group will not be satisfied.

Edge case: F-CPU in RUN but F-runtime group STOP

Cause: the F-Call is in a cyclic interrupt OB whose cycle was set to 0 ms, or whose phase offset aligns with a higher-priority OB. Fix: in CPU properties → Cyclic interrupts, confirm the OB35 cycle is > 0 and the phase offset does not collide with OB10/OB30/OB38.

Edge case: OB35 cycle change in RUN

The OB35 cycle can be changed in RUN on the S7-1500F via the SFC (Set OB35 cycle time). On S7-300F/400F the change requires STOP. Always re-check F-monitoring time after a cycle change, because a faster OB35 cycle does not automatically tighten the F-monitoring time budget for the safety program execution.

Why OB1 Is Not "Wrong", Just Risky

Calling the F-Call from OB1 will not produce a syntax error and the F-CPU may start and pass initial self-test. It violates the S7 Distributed Safety firmware contract, however, because OB1 priority is fixed at 1 and its free cycle is non-deterministic. Under load the safety program will eventually exceed F-monitoring time, the F-CPU will passivate F-I/O, and the application will go to STOP. Siemens documentation treats the cyclic interrupt OB placement as a normative requirement, not a recommendation. The same reasoning applies to TIA Portal's SIMATIC Safety; the F-runtime group is not allowed to be called from OB1 in any certified configuration.

Related Concepts

The F-Call placement rule sits on top of three wider S7 safety concepts that are worth understanding before commissioning:

• PROFIsafe: the protocol over PROFINET or PROFIBUS that carries the F-I/O data with a safety signature (CRC over the user data, sequence number, and control byte). PROFIsafe timing is independent of the F-Call cycle, but the F-CPU must be ready to process the next PROFIsafe frame within its monitoring time; the F-Call in OB35 guarantees that readiness.
• F-shutdown groups: when a safety condition is violated, the F-runtime group assigns the affected F-DB outputs to a shutdown group and passivates them. The passivation transition time is part of the F-monitoring time budget.
• F-CPU access protection: the safety program is password-protected (separate from the standard CPU password) and the F-CPU enters safety mode only after a successful password check. The F-monitoring time is enforced from the moment safety mode starts.

For an overview of the S7-300F hardware, see SIMATIC S7-300 Automation System, CPU 31xF and CPU 31x Manual.

Summary

The F-Call block must run in a cyclic interrupt OB (typically OB35 at 100 ms) because:

1. Priority must be above OB1 (priority 1) so the safety program is not preempted by standard program execution.
2. Local-data area for the OB's priority class must be large enough to hold the F-runtime group stack frame, and that area is sized in CPU properties.
3. F-monitoring time requires a deterministic, periodic execution context, which only a cyclic interrupt OB provides.

Place the F-Call in OB35, set the cycle to 100 ms, size the local-data area for the OB's priority class to the value reported by the safety program generator, and verify via the diagnostic buffer and the F-runtime group online view that the maximum measured runtime is below F-monitoring time. On the S7-1500F, the placement is created automatically by SIMATIC Safety in TIA Portal; the same priority and monitoring-time rules still apply.