Understanding OB, FC, and FB Blocks in Siemens TIA Portal: Why FB Really Matters

If you have spent any time inside Siemens TIA Portal, you have seen the Program Blocks folder in the project tree. It usually contains a Main [OB1], a handful of Function Blocks (FBs), a few Functions (FCs), and one or more Data Blocks (DBs). For a student or beginner, this raises an obvious question: since logic can technically be written inside an FC or even directly in the OB, why do we need a separate FB block at all? Is it necessary, or is it just an extra layer of complexity?

 

The short answer is yes, FB is genuinely necessary, and once you understand what each block type is designed to do, the reason becomes clear. OB, FC, and FB are not three interchangeable ways of writing the same logic. Each one has a distinct job in the structure of a PLC program, and using the right block for the right task is what separates a clean, scalable program from a messy one that becomes difficult to troubleshoot as a project grows.

The Organization Block (OB): The Program's Entry Point

Every PLC program needs a starting point, and that is exactly what the Organization Block provides. OB1, commonly called Main, is the cyclic program that the CPU scans repeatedly, over and over, for as long as the PLC is in RUN mode. Other blocks such as FCs and FBs do not run on their own; they are called from inside the OB, either directly or through a chain of calls that eventually traces back to it.

Think of the OB as the conductor of an orchestra. It does not play every instrument itself, but it decides which sections play, in what order, and when. In a real project, OB1 is usually kept fairly clean and readable, calling smaller, well-organized FC and FB blocks rather than containing hundreds of lines of raw logic. This is good programming practice because it keeps the overall program structure easy to follow, even for someone who did not originally write it.

The Function (FC): Logic Without Memory

An FC, or Function block, is the right tool when you need to perform logic that does not need to remember anything between scans. Classic examples include calculations, unit scaling, analog value conversion, comparisons, and common interlock conditions shared across multiple parts of a machine.

The defining characteristic of an FC is that it has no dedicated memory of its own. Every time the FC is called, it executes using only the input values it receives at that moment, produces an output, and then finishes. Once the scan moves on, the FC does not retain any internal state. If you need the same calculation performed for different signals throughout the program, an FC is efficient because it is stateless and reusable without carrying baggage from one call to the next.

This works perfectly for logic like "convert this raw analog value into engineering units" or "compare these two setpoints and output true if the difference exceeds a threshold." There is nothing to remember here; the same inputs will always produce the same outputs, call after call.

The Function Block (FB): Logic With Memory

This is where things get more interesting, and where the beginner's question really gets answered. An FB is used specifically when the logic needs memory, meaning it needs to retain values, states, or conditions from one scan to the next.

Every FB is automatically paired with its own Instance Data Block, often visible in the project tree as something like "Block_2_DB_1" or a similarly named DB directly beneath the FB. This Instance DB is the FB's private memory. It stores internal variables, timer values, previous states, and any other data the block needs to remember across scan cycles.

The motor control example shown in a typical TIA Portal training project illustrates this perfectly. A Start/Stop Motor FB1 block is called with a linked instance data block, and inside it, simple ladder logic uses a Stop contact, a Start contact, and a Motor coil, along with a sealing-in contact that feeds back around the Motor output to latch the circuit. That seal-in contact is exactly why memory matters. Once the Start button is pressed and released, the logic must remember that the motor is running so it stays on. Without a way to retain that state between scans, the motor would only run for the single scan cycle during which the Start button happened to be pressed. That is not how a real motor control circuit is supposed to behave.

Now imagine scaling this up to an actual industrial project with ten motors, each requiring its own start, stop, trip, and feedback logic. Writing this in an FC would not work well because FCs do not retain state on their own; you would have to manually manage separate memory bits for every single motor, which quickly becomes unmanageable and error-prone. With an FB, you simply call the same Start/Stop Motor block ten times, each with its own separate instance data block. The logic is written once, but each motor gets its own independent memory, its own start/stop state, and its own feedback tracking, all without duplicating a single rung of ladder logic.

Putting It All Together

To summarize the roles in the simplest possible terms:

• OB runs the program. It is the cyclic entry point that calls everything else, in order, every scan.
• FC is for logic without memory. It performs a task using only its current inputs and does not remember anything afterward. Ideal for calculations, scaling, and comparisons.
• FB is for logic with memory. It retains internal state through its Instance Data Block, making it essential for anything that must remember a condition across scan cycles, like a latched motor, a sequencing step, or a running timer. 

This is precisely why FB blocks dominate real industrial programming for equipment like motors, pumps, valves, conveyors, compressors, and multi-step machine sequences. All of these devices share one thing in common: they need to remember their current state. A pump that is running needs to stay running until it is told to stop. A conveyor moving through a sequence needs to remember which step it is currently on. None of that is possible with stateless logic alone.

For beginners still getting comfortable with TIA Portal, the best way to internalize this difference is to build the classic Start/Stop Motor circuit inside an FB, call it multiple times with different instance data blocks, and observe how each instance behaves completely independently. Once you see ten separate motors running from one block of reusable logic, each with its own memory, the purpose of the FB block stops being an abstract concept and becomes an obvious, practical necessity.