Siemens S7-1200/1500 Block Types: OB, FC, FB, DB Reference

Overview: The Siemens S7 Block Model

Every Siemens S7-1200 and S7-1500 user program is built from four block types defined by the IEC 61131-3 standard: Organization Blocks (OB), Functions (FC), Function Blocks (FB), and Data Blocks (DB). Choosing the correct block type is not a stylistic preference; it determines whether the block carries persistent state, how parameters are passed, how the block is called, and how it behaves under program fault conditions. A wrong choice typically surfaces during commissioning as lost retentive data, duplicate tags, FBs that cannot be called multiple times, or "Instance DB required" compile errors.

Siemens publishes a dedicated S7-1200/S7-1500 Style Guide for PLC Programming as a primary reference. TIA Portal's block editors in V15.1 and later (current at the time of writing: V18/V19) and STEP 7 Professional use the same block model, so the rules below apply to both controller families unless explicitly noted.

Block Type Summary

Organization Blocks (OB): The System Interface

OBs are the only blocks the S7 CPU operating system calls directly. Each OB has a fixed priority class, a fixed triggering event, and a fixed set of local TEMP variables. Logic placed inside an OB executes once per trigger. OBs cannot be called from other code blocks; only the OS can start them.

OB Categories on S7-1200/1500

On S7-300/400 the cyclic scan was effectively limited to OB 1, which forced all logic into a single block. S7-1200 and S7-1500 remove that restriction: you can split the program across several OBs (e.g. a 10 ms cyclic OB for PID, a 100 ms cyclic OB for HMI update, OB 1 for sequencing) without having to nest everything in OB 1.

OB Local Variables

Each OB has a fixed interface table. For OB 1, the most-used locals are:

• OB1_EV_CLASS - event class (B#16#11 = standard cyclic)
• OB1_PRIORITY - priority class (1 for OB 1)
• OB1_PREV_CYCLE - previous cycle time in ms
• OB1_MIN_CYCLE - minimum cycle time since start
• OB1_MAX_CYCLE - maximum cycle time since start

Use OB1_PREV_CYCLE for cycle-time monitoring and alarm generation. On S7-1500 the same information is exposed as system tags in the Diagnostics folder.

Functions (FC): Stateless Code Blocks

An FC is a subroutine that has no memory of its own. It holds its inputs, outputs, in-out tags, and a small TEMP area only while it is executing. When the FC exits, the TEMP data is gone. Inputs and outputs are passed by value (a copy is made at call time) - this is the default and it is also the source of the most common FC mistake.

Use an FC when:

• The logic is purely functional: input values produce output values with no internal state.
• Examples: FC_LinearScale(), FC_Mux4to1(), FC_ASCIItoInt(), FC_ComputeChecksum().
• The block will be called from many places and you do not need per-call memory.

Do not put timers, edge flags, or step machine state in an FC. Without an instance DB, the FC cannot retain that data between scans, and a value that works in one scan will be lost the next.

FC Parameter Passing

Function Blocks (FB): Stateful Code Blocks

An FB is a code block that owns its instance DB. The instance DB holds all the FB's STAT (static) variables, so memory persists between scans. This is how Siemens implements a class-instance model: the FB is the type, the instance DB is the object.

Use an FB when the logic represents a real device or a stateful object:

• Motor, valve, cylinder, conveyor, drive, PID loop, recipe, alarm handler, modbus slave, HMI screen controller, sequential function chart, state machine.

Each call to the FB can be passed a different instance DB; the FB code is identical, but the state is separate. This is the primary reason the FB/DB pair is preferred over FC for any non-trivial automation code.

FB Parameter Passing

The key difference vs. an FC: STAT variables. The instance DB is the FB's persistent memory. Timers instantiated inside the FB persist as part of that DB. Edge-flag bits, last-step numbers, runtime counters, and last-error codes are all STAT data and that is why an FB is the right block type to contain them.

Multi-Instance FBs

When one FB contains another FB call, the contained FB can share the parent's instance DB. This is called a multi-instance. It removes the proliferation of tiny DBs and keeps the call hierarchy clean. To enable, in the contained FB's call interface, set the instance selection to Multi-instance; the parent FB's instance DB will then hold both objects' static data.

Data Blocks (DB): The Three Subtypes

The DB is the storage block. It contains only data, no executable code (in user DBs). There are three kinds of DB on S7-1200/1500:

Global DB Design Notes

• Group tags by function or by device rather than by data type.
• Use derived PLC data types (UDTs) for any structure used in more than one place (e.g. UDT_MotorAxis, UDT_RecipeRow).
• For retentive data, enable Setpoints under DB properties; in the S7-1500, use the Retain attribute on individual tags.
• Watch the size: large arrays of REAL in global DBs consume load memory. A 1000-element REAL array is 4 KB in the S7-1500.

Optimized vs Non-Optimized Block Access (S7-1500)

On S7-1500 (default) and S7-1200 (V4.0 and later), every new block is optimized: the compiler assigns symbolic addresses, and tags are stored in a non-contiguous, symbolic layout that the firmware resolves by name. Legacy non-optimized (absolute) blocks store tags in fixed byte offsets that match the old S7-300/400 address model.

Block Selection Decision Matrix

Programming Conventions and the Siemens Style Guide

The Siemens S7-1200/S7-1500 Style and Programming Guidelines document recommends:

1. One FB per real-world device or per logical subsystem (e.g. FB_Motor_3, FB_Heater_Bank2).
2. Use FCs for mathematical or conversion functions and library code that has no state.
3. Place FB interface tags first, in/out tags second, static data last - this makes scan and review easier.
4. Use parameter instances of standard timers/counters (TP, TON, TOF, CTU, CTD) as STAT inside FBs, not as global tags.
5. Use UDT (user-defined data types) to group tags that travel together; declare input/output sections using UDTs when the structure is reused.
6. Enable know-how protection with a password on finished library blocks; never on blocks that are still in development.
7. Version library blocks in the TIA Portal project library; do not hand-edit blocks in deployed programs.

Calling Blocks: Cross-Block Mechanics

A call to an FC copies the parameters in at the start of the call and copies outputs back at the end. A call to an FB uses the instance DB as the working area. Calling an FB without an instance DB - or with the wrong one - is a compile error. TIA Portal will refuse to compile an FB call whose instance DB was deleted or renamed.

Calls in SCL/ST are direct:

// Calling a function
retVal := FC_LinearScale(IN := aiRaw, HI_LIM := 100.0, LO_LIM := 0.0, BIPOLAR := FALSE);

// Calling a function block with an instance DB
iDB_Motor_3(IN := iStart_3, OUT_STATUS => qStatus_3);

// Calling a multi-instance FB
iMotorLocal(IN := iStart, OUT_STATUS => qStatus);

Calls in LAD/FBD are inserted from the right-side toolbox as Call boxes; the instance DB dropdown is mandatory for FBs.

Common Pitfalls and Diagnostics

Block Libraries, Versioning, and Reuse

Both the S7-1200/1500 program blocks and the user-defined types (UDTs) belong in the project library. A library type is a master copy in the Master copies folder; a library instance is a reference used in the project. Updates to the master copy can be propagated to all instances via the Update instances command. This is the equivalent of centralized code reuse in mainstream languages and the recommended way to maintain shared FB libraries across multiple PLCs.

For cross-CPU libraries, ensure that the library FB compiles on every target firmware. S7-1500 firmware V2.0 introduced the optimized-block access model; FBs compiled for V2.0 may not load on V1.8 controllers. Always check the Compatibility list in the library's properties before release.

Verification: Confirming a Healthy Block Architecture

After any program change, perform these checks before download:

1. In the project tree, every FB call has an instance DB. TIA Portal reports orphan FBs in the Compile output.
2. No global tags duplicate FB STAT content. Search the symbol table for tag names that exist in both a global DB and an instance DB.
3. No timer or counter is used inside an FC. Use Cross-reference on TP/TON/TOF/CTU/CTD to find FC-resident instances.
4. All error OBs (OB 80-87, OB 121, OB 123) that the program depends on are present. The PLC > Diagnostics > Module information lists missing OBs.
5. OB 1 cycle time and cyclic interrupt OB cycle times are below 80% of their configured maximum. Read OB1_PREV_CYCLE and the cyclic OB's cycle time tag under Diagnostics > Cycle time.
6. Library blocks are at the same version in the project and in the PLC. Compare the version stamp under Block properties > Information.

FAQ