Siemens Function Blocks in TIA Portal: FB, FC, DB and Multi-Instances

Direct answer: a Siemens FB is reusable code plus instance memory

A Siemens Function Block (FB) is a reusable program block whose persistent per-instance values are stored in an instance data block (instance DB). The FB defines behavior and an interface; each instance DB gives one call identity its own static values, timer state, sequence state and diagnostics. If three motors use one FB_Motor type, create three independent instances—or deliberately place three multi-instances inside a parent FB—so one motor cannot overwrite another motor's history.

A Siemens Function (FC) does not have an associated instance DB. Use an FC for a calculation or transformation that does not require private state between calls. Use an FB when behavior must remember something: a request latch, timer, edge history, sequence state, first-out error or protocol transaction. Function Block Diagram (FBD) is a graphical language; it is not the same thing as an FB. An FB can be written in LAD, FBD or SCL where the target and STEP 7 edition support that language.

The practical workflow is: define the interface contract, create the FB, let TIA Portal create a dedicated instance DB or declare a multi-instance in a parent FB, call the instance once from the intended OB path, compile, execute normal and negative tests, inspect the exact instance path online and preserve the results.

This page owns the Siemens-specific FB/FC/DB implementation task. The PLC function-block guide owns vendor-neutral type-versus-instance concepts and the 50-block reference library. The Siemens PLC programming tutorial owns the broader TIA Portal workflow from device configuration to controlled download. The STEP 7 legacy guide owns S7-300/S7-400 Classic and migration boundaries.

Why use a Function Block instead of coding everything in OB1?

An FB gives repeated equipment a stable contract and one deliberate state owner. Without that boundary, a motor command might be written in several OB1 networks, a timer might live elsewhere, and the HMI might infer faults from unrelated bits. The program can still run, but a reviewer cannot easily answer who owns command, which feedback completes startup, what survives a scan or which condition latched the first fault.

Move a behavior into an FB when several of these are true:

• the equipment needs state across calls;
• the same behavior appears more than once;
• command, status and diagnostic signals form a coherent contract;
• private timers, edges or step state should not become global tags;
• the behavior needs an isolated test harness;
• a library or versioned interface will be maintained; or
• online diagnosis benefits from one instance path per equipment object.

Do not create a block merely to reduce visible network count. A block with dozens of hidden global reads, direct physical output writes and undocumented static values is reusable in name only. Good encapsulation reduces dependencies; it does not hide them.

Siemens FB versus FC: choose by ownership of state

“FB has memory; FC has no memory” is a useful beginning, but the selection question is really who owns state. An FC can read and write values passed by parameters or shared DBs, so an FC-based design can still affect stored data. It simply does not receive a private instance DB automatically. Conversely, an FB should not become a dumping ground for every value just because static memory is convenient.

Use an FC when the current result should be derived from current inputs and any state is explicitly owned by the caller. Examples include scaling a raw value, checking a range, decoding a status word or selecting a minimum. Use an FB when private history is part of the behavior: a timer, request latch, edge detector, state machine, rate limiter, alarm latch or asynchronous handshake.

An FB is not automatically object-oriented, safe, deterministic or reusable. Those qualities depend on its interface, one-owner rules, call schedule, diagnostics and tests.

Design the FB interface before creating the block

A Siemens FB interface commonly separates inputs, outputs, in-out parameters, static data, temporary data and constants. The exact editor presentation and supported features vary by controller and version. Treat every public parameter as a contract and every static value as instance-owned implementation state.

Define request, command and feedback separately

StartReq says a caller asks to run. RunCommand says ordinary control logic asks the mapped output layer to energize. RunFeedback says the equipment or test model reports achievement. Collapsing them into one Run Boolean hides the exact point where a failure occurred.

Make reset a controlled transition

Reset should not blindly clear every state on every scan it is true. Define whether it is edge-triggered, which causes must be absent, what mode is required and whether feedback must be off. The example accepts a new Reset edge only when disabled and feedback is false. That is a teaching policy; a real equipment requirement may differ.

Keep standard control separate from safety

An input named SafetyOk, EStopHealthy or GuardClosed does not make an ordinary FB a safety function. Emergency stopping, guard monitoring, safe motion and risk reduction require the applicable assessment, fail-safe hardware/software, signatures and validation. The downloadable example is ordinary control only.

Create a Siemens FB and a single-instance DB in TIA Portal

Before creating software, record the exact CPU article number, firmware, TIA Portal/STEP 7 release and update, block access settings, library versions and target language support. As reviewed on 31 August 2026, Siemens identifies TIA Portal V21 as the current major framework release. That fact does not authorize upgrading an installed project or imply compatibility with every CPU.

For a current S7-1200/S7-1500 project, the practical sequence is:

1. create or open the exact configured device;
2. add a new Function Block under Program blocks;
3. name it by behavior, such as FB_MotorEvidence;
4. select LAD, FBD or SCL according to the supported target and team standard;
5. define the complete interface before internal logic;
6. create a cyclic call in the intended OB;
7. let TIA Portal create and name the instance DB, such as Motor_A_DB;
8. connect every required actual parameter deliberately;
9. compile software and inspect warnings, interface impacts and call paths; and
10. test the instance in simulation or an approved isolated target.

Do not call the same equipment instance twice from unrelated paths to imitate two independent objects. Both calls read and write the same instance data. If one call uses Motor A parameters and the second uses Motor B parameters, whichever executes later can overwrite state and outputs in ways that are difficult to diagnose.

Single instances versus Siemens multi-instances

A single instance uses a dedicated instance DB associated with one FB call. A multi-instance is an FB instance declared in the static section of another FB; the child instance data is nested inside the parent's instance DB. Both approaches provide instance state. The choice affects ownership, online navigation, interface evolution and reuse.

Choose multi-instance because the parent genuinely owns the child lifecycle, not merely to shorten the project tree. A pump-station FB containing two pump FBs can be coherent. An entire plant placed inside one giant parent FB creates an enormous state and download-impact boundary.

Worked SCL example: motor request, feedback timeout and first-out error

Download the Siemens SCL motor FB reference. It provides inputs, outputs, static edge/timer state and an example instance call. Adapt it to the exact STEP 7 project; do not treat a text file from a tutorial as an approved production library.

The core command and timeout pattern is:

#StartEdge := #StartReq AND NOT #StartOld;
#StartOld := #StartReq;

IF #StopReq OR NOT #Enable OR NOT #Permit OR #Faulted THEN
   #RequestLatched := FALSE;
ELSIF #StartEdge THEN
   #RequestLatched := TRUE;
END_IF;

#RunCommand := #RequestLatched
               AND #Enable
               AND #Permit
               AND NOT #Faulted;

#StartTimer(IN := #RunCommand AND NOT #RunFeedback,
            PT := #StartTimeout);

IF #StartTimer.Q THEN
   #Faulted := TRUE;
   #ErrorId := 16#0101;
   #RequestLatched := FALSE;
   #RunCommand := FALSE;
END_IF;

This example makes the policies visible:

The error value is an editorial convention, not a Siemens system error code. In a maintained library, publish the identifier namespace, meaning, severity, reset rule and version. Avoid a magic integer known only to one HMI screen.

Call the same type through separate instances

After TIA Portal creates Motor_A_DB, connect actual parameters at the call. Create Motor_B_DB for the second motor. Do not rename an instance without reviewing HMI/SCADA references, external symbolic consumers, test scripts and documentation. Optimized versus standard access and symbolic versus absolute consumers can materially change that impact.

Trace behavior scan by scan

An online snapshot can show RunCommand = TRUE and RunFeedback = FALSE, but it cannot tell whether feedback is still inside its allowed delay or the timer should already have faulted. Record values across scans or with an appropriate trace.

Assume Enable and Permit are true, Start rises on scan 2, feedback appears on scan 5 and the timeout has not expired:

Now repeat with feedback absent beyond the timer preset. The expected evidence is timer Q true, request false, command false, fault true, state 90 and error 16#0101. If only the final fault bit is saved, you cannot prove that command preceded the missing feedback or that the timeout duration was correct.

Why conditional FB calls are risky

If the FB is not called, its internal logic, timer call and output assignments do not execute for that cycle. Values already stored in the instance DB do not become a modeled disabled state automatically. Call the equipment block in the intended execution path and pass Enable := FALSE so it can apply its documented disabled policy. Conditional calls can be valid when deliberately designed, but the skipped-call behavior must be explicit and tested.

Compile, simulate and run the 12 acceptance tests

Download the Siemens FB acceptance-test CSV. It includes startup, valid start, normal feedback, stop priority, denied start, lost permit, feedback timeout, rejected/accepted reset, independent single instances, independent multi-instances and interface-change impact.

Simulation proves logic only within the modeled environment. Record TIA Portal, STEP 7 and PLCSIM version, represented CPU/firmware, task/cycle assumptions, simulated signals, exclusions and source checksum. It does not prove field wiring, output circuits, motor response, network timing or a safety function.

Siemens' TIA Portal Test Suite can support application testing and style checks in supported configurations, but product option availability, supported targets and licenses are version-specific. A CSV and watch trace remain useful even without Test Suite because they make expected behavior explicit.

Diagnose the exact instance online

Online diagnosis begins with identity. Confirm the intended CPU and approved work boundary, then open the exact call environment and instance. Watching the FB type without the intended instance context can show meaningless or unavailable status because static values belong to a DB path.

Use cross-references to find every call and every writer. Use online/offline comparison under the approved site procedure before changing code. Avoid indefinite forces; if an authorized isolated test requires one, record the force owner, purpose, duration and removal verification. Monitoring and forcing are different actions with different risk.

Interface changes, optimized access and download impact

Changing an FB input, output, static variable or nested multi-instance is not a cosmetic edit. It can affect caller signatures, instance DB layout, initialization, symbolic clients, library versions, test baselines and download behavior. The impact depends on CPU, STEP 7 version, optimized-access setting and the specific change.

Do not promise “no reinitialization” from a generic tutorial. Use TIA Portal's exact compile/download messages, Siemens documentation for the target/version and a representative test. Preserve a verified backup and rollback plan before production changes.

Siemens function-block design checklist

Before releasing an FB or library type, verify:

1. one sentence defines the block's responsibility;
2. every input has polarity, units, validity and edge/level semantics;
3. outputs separate request acceptance, command, feedback achievement and diagnosis;
4. static values are genuinely instance-owned history;
5. Temp values are not expected to persist;
6. every independent equipment object has an independent instance;
7. stop, disable, permit loss, fault and reset priority are explicit;
8. timers define trigger, preset owner, reset and restart behavior;
9. Error IDs are documented and first-out behavior is tested;
10. the intended OB path calls the instance at the required rate;
11. all 12 baseline tests pass on the recorded environment;
12. interface/download impacts and external consumers are reviewed; and
13. standard control is not presented as a safety function.

Quick answers for Siemens PLC programmers

Frequently asked questions

What is the difference between an FB and FC in Siemens TIA Portal?

An FB has per-instance memory in an instance data block, making it suitable for stateful behavior. An FC has no associated instance DB and is a stronger fit for a calculation or transformation without private history. An FC can still read or write caller/global data, so “no memory” should not be mistaken for “cannot affect stored values.”

What is an instance DB in a Siemens PLC?

An instance DB stores the interface and static values for one FB instance. It distinguishes Motor_A timer/state/error history from Motor_B even though both use the same FB type. The exact memory layout, optimized-access behavior, initialization and retentivity depend on the target and project configuration.

Can I reuse the same instance DB for two FB calls?

Only when both calls intentionally operate on the same logical instance and the resulting call-order behavior is designed and tested. Do not reuse one instance DB to represent two independent motors, valves or transactions. Their prior inputs, timers, state and outputs will interfere.

What is the difference between a single instance and multi-instance?

A single instance normally has its own named instance DB. A multi-instance is declared as static data inside a parent FB, with its child data nested in the parent's instance DB. Multi-instances are useful for coherent composite equipment but expand the parent's change and test boundary.

Does a Siemens Function Block have to be written in FBD?

No. “Function Block” names the stateful program-block type; “Function Block Diagram” names a graphical language. In supported TIA Portal targets, an FB can be implemented in languages such as LAD, FBD or SCL. Exact language availability depends on controller, STEP 7 edition and project.

Why is my Siemens FB not executing?

Check the active CPU, operating state, OB call path, call condition and exact instance. Confirm the block is called by an executing organization block and that the online view is opened in the intended call environment. A compiled FB that is never called does not execute.

What happens if a Siemens FB is not called every scan?

Its internal instructions and assignments do not execute during skipped calls, while existing instance data can remain stored. Timers and outputs therefore do not automatically follow the disabled behavior you intended. Either call the block consistently with an explicit Enable input or specify and test conditional-call semantics.

How should I test a Siemens function block?

Test startup, normal request/feedback, stop priority, denied start, lost permissive, missing-feedback timeout, reset rejection/acceptance and multiple-instance independence. Record the exact tool/CPU environment, instance path, stimulus, state, command, feedback, timer and error output. Use the downloadable 12-case CSV as a baseline.

Can changing an FB reinitialize an instance DB?

Some interface or static-layout changes can affect instance DBs and initialized values; the exact result depends on CPU, block access, STEP 7 version, the edit and download method. Read the compile/download messages, inspect affected blocks and test restart/data behavior on a representative target. Never assume a generic no-impact rule.

Can a Siemens FB be used as a safety function?

An ordinary standard FB does not become safety-rated because it checks a Boolean named SafetyOk. Safety-related control requires a risk assessment, suitable fail-safe hardware and software, protected engineering lifecycle, approved instructions and validation against the required safety performance. Keep the example in this guide outside that claim.

Sources and version boundary

This independent guide was researched on 30–31 August 2026. Siemens documentation for the exact CPU, firmware, STEP 7 release and project is the implementation authority. The current-version statements below can change after review.

• TIA Portal V21 release — Siemens
• SIMATIC STEP 7 in TIA Portal — Siemens
• Overview of block types in STEP 7 V20 — Siemens TIA documentation
• Function block (FB) — Siemens TIA documentation
• Programming guideline for S7-1200 and S7-1500 — Siemens
• S7-1200 G2 system manual — Siemens
• S7-1500 and ET 200MP system manual — Siemens
• S7-1500 diagnostics function manual — Siemens
• Diagnostics overview for S7-1200 and S7-1500 — Siemens
• TIA Portal options including simulation and testing — Siemens
• TIA Portal Test Suite application-test example — Siemens
• S7-1200/S7-1500 safety programming guideline — Siemens
• SIMATIC S7-1200 G2 product overview — Siemens
• SIMATIC S7-1500 product overview — Siemens
• SCE technical support and educational downloads — Siemens
• Industrial cybersecurity for automation — Siemens
• IEC 61131-3:2025 publication record — IEC
• IEC 61131-3 programming-language context — PLCopen

The SCL example, scan trace, tables, test CSV and six figures are original editorial artifacts. They are educational references, not Siemens-authored application code, a target compatibility statement, a safety library or permission to modify an installed controller.