A TIA program is organised into blocks that call each other. There are four kinds. To understand which one you need, start by asking where its data lives between calls.
Memory is the dividing line. An FC (function) takes inputs and returns results without an instance DB of its own. An FB (function block) gets a private instance DB to remember state across scans. An OB is where the OS calls in. A DB is just data.
sqrt(). It has no private instance memory to keep between calls.Here OB1 calls two blocks every scan, both trying to count a pump's run-hours. FC_Hours is a plain function. Its working number is a temp that does not retain its value between calls, so this example cannot accumulate the total there. FB_Pump has an instance DB, so its total survives scan after scan. Run the pump and watch only one meter climb.
#runHours." But #runHours is a temp, initialized to 0 on each call in this simulation.#runHours is a static var in the instance DB, so it persists.An FB gives its instance a place to remember data such as a timer value, a counter, a step number or a state machine's state. The instance DB keeps that data between calls. Use an FC for a calculation that does not need its own instance memory.
Write FB_Pump once, then call it for every pump on the site. Give each pump its own instance DB to keep the same behaviour with separate memory. A bug fix in the FB applies to all of those instances, while Pump_1's hours remain separate from Pump_2's.
FUNCTION_BLOCK "FB_Pump" VAR running:Bool; runHours:Real; END_VAR // VAR = static = remembered // call it three times — three private instance DBs: "Pump_1"(running := %I0.0); // DB30 "Pump_2"(running := %I0.1); // DB31 "Pump_3"(running := %I0.2); // DB32
The three pumps use one block of code and keep their data in three separate instance DBs. The Execution Model lesson introduced those DBs; this example shows how you use them when the same equipment appears several times in a project.
During execution, blocks call each other. The operating system starts that chain by calling the OB. Press Run one scan and follow the execution: OB1 calls FC_Scale (which forgets), then FB_Conveyor (which remembers, in its instance DB), which reads a recipe from a global DB. The call-stack and memory ledger update as the scan proceeds, letting you see exactly where each value lives and what survives to the next scan.
🔴 TEMP is not retained between calls · 🟢 STATIC lives in the instance DB from scan to scan · 🟡 a global DB holds data for the program.
Follow the execution and storage in this example: the OS calls an OB, the OB orchestrates FCs and FBs, and they read/write DBs. The calls show which block runs next. The DBs show where the values are stored and which ones remain available on the next scan.
Once you know the four block types, check the timing, instance layout and addressing choices in your project:
📅 OBs are more than OB1
OB100 runs once at startup (init values). OB30–38 are cyclic interrupts that fire on a fixed time base. Use them for PID logic that needs a defined interval independent of OB1's scan time. Hardware-interrupt OBs fire on an input edge; error OBs (OB82/121…) let your program react to a fault. Whether a missing error OB sends the CPU to STOP depends on the event: an S7-1500 stays in RUN with no OB82 loaded.
🧠 Multi-instance: an FB inside an FB
A TON is itself an FB. When you declare it as a static var inside your FB, its memory nests inside your instance DB, without a separate DB for each timer. This is multi-instance: one tidy instance DB holds your FB's state and all its sub-instances.
📦 Optimized vs standard DB
Optimized DBs (the S7-1200/1500 default) have no fixed byte addresses. The CPU packs them for speed, and you access each variable by name only. Standard DBs keep classic %DBx.DBWy offsets for legacy access. Inserting a tag in a standard DB shifts the addresses below it, which can break a client that uses those addresses.
➗ Use an FC for a stateless calculation
An FC needs no instance DB for stateless work such as scaling, a CRC or unit conversion. You can call that calculation wherever it is needed without creating a DB for each use. Choose an FC when the answer depends only on its inputs, and an FB when each instance needs to keep its own state.
You need a reusable conveyor controller that holds its own state machine and a TON timer, callable for each of 12 conveyors. What do you build?