OB vs FC vs FB in TIA Portal: Why Do We Really Need an FB?

OB vs FC vs FB in TIA Portal: Why Do We Really Need an FB?

One common question I hear during TIA Portal and Siemens PLC training is:

“Sir, if we can do programming in OB and FC, then why do we need an FB? Is FB really necessary?”

My answer is always:

Yes, FB has a very important purpose.

For a beginner, OB, FC, and FB can look very similar. All three are program blocks, and we can write logic inside them.

But they are designed for different programming requirements.

Once a student understands the difference between these three blocks, PLC programming becomes much easier—and more importantly, the student starts thinking like an automation engineer rather than simply writing ladder logic.

Let's understand it in a simple way.

 

 

OB – The Organisation Block

OB stands for Organisation Block.

You can think of the OB as the entry point or organiser of the PLC program.

The PLC executes different OBs based on the type of OB and the event that triggers them.

For example, the OB1 is commonly used as the main cyclic program block.

Inside OB1, we can call:

• FCs
• FBs
• Other program structures

A simple structure could look like:

OB1 → FC1 → Logic

or:

OB1 → FB1 → Instance DB

So, OB does not necessarily contain all the detailed machine logic.

Instead, it helps organize how the program is executed.

For a simple machine, we might have:

OB1

→Motor Control
→ Conveyor Control
→ Pump Control
→ Valve Control
→ Alarm Logic

But as the machine becomes larger, putting everything directly into OB1 can make the program difficult to understand and maintain.

This is where FCs and FBs become extremely useful.

 

FC – Function Block Without Retained Instance Memory

FC stands for Function.

FCs are very useful when we want to create reusable logic that does not require its own instance memory.

For example, an FC can be used for:

• Mathematical calculations
• Scaling
• Comparisons
• Signal processing
• Common interlocks
• Data conversion
• Simple calculations
• Reusable logic

Suppose we have an analog input from a pressure sensor.

We receive a raw value from the PLC and need to convert it into engineering units such as:

0–27648 → 0–10 bar

Instead of putting all the scaling calculations into OB1, we can create an FC for the calculation.

The OB can call the FC and provide the required inputs.

The FC performs the calculation and returns the result.

This makes the program cleaner and easier to maintain.

But there is an important point:

An FC does not have its own instance DB.

Therefore, it does not have the same type of dedicated instance memory that an FB has.

This makes FC very suitable for calculations and logic where dedicated persistent state is not required.

 

FB – Function Block with Memory

Now comes the most important question:

Why do we need FB?

The major advantage of an FB (Function Block) is that it is designed to work together with an Instance DB (Instance Data Block).

The Instance DB stores the data associated with a particular FB instance.

This allows the FB to maintain its own data and state between calls.

This becomes extremely useful when we are developing reusable equipment or machine-control logic.

Let's take a practical example.

 

Example: Controlling 10 Motors

Suppose a manufacturing machine has:

10 motors.

Every motor has:

• Start command
• Stop command
• Motor feedback
• Trip feedback
• Permissive conditions
• Interlocks
• Running status
• Fault status
• Reset command

We could create separate logic for every motor.

But that would create a lot of repeated programming.

Instead, we can create one standard motor-control FB.

For example:

FB_Motor

Inside this FB we can develop the complete motor logic.

Then we can create multiple instances:

Motor 1 → FB_Motor + Instance DB
Motor 2 → FB_Motor + Instance DB
Motor 3 → FB_Motor + Instance DB

And so on.

Each motor uses the same standard logic, but each instance has its own data.

This is one of the most powerful concepts in structured PLC programming.

 

Why Is Instance DB Important?

Think of the FB as a standardized machine component and the Instance DB as the memory/data associated with that particular component.

For example:

FB_Motor

contains the standard motor-control logic.

The Instance DB contains data for:

Motor 1

Another Instance DB contains data for:

Motor 2

Another Instance DB contains data for:

Motor 3

The logic is standardized, while the instance data is separated.

This provides significant advantages in large automation projects.

 

A Simple Real-Life Analogy

Imagine you have a motor-control template.

The template says:

“When Start is pressed and all permissive conditions are healthy, start the motor. If a trip occurs, stop the motor and generate a fault.”

You don't want to rewrite this entire logic ten times.

Instead, you create one standard FB:

FB_Motor

Then you use it for:

Motor 1
Motor 2
Motor 3
Motor 4
...
Motor 10

Each motor gets its own instance data.

This is similar to creating one standard design and using it for multiple machines.

 

Where Are FBs Commonly Used in Industry?

In real industrial automation projects, FBs are commonly useful for equipment and systems that have their own state, parameters, commands, feedback, or operating modes.

Examples include:

Motor Control

Start, stop, trip, feedback, permissives, interlocks and reset.

Pump Control

Auto/manual operation, start/stop, feedback, pressure conditions, alarms and protection.

Valve Control

Open/close commands, feedback, timeout monitoring and fault detection.

Conveyor Control

Start/stop, sequence, sensors, interlocks, speed control and fault handling.

Compressor Control

Operating modes, pressure conditions, alarms, permissives and protection.

Machine Sequence

Step control, sequence status, timers, transitions and fault conditions.

The exact architecture depends on the machine and programming standard, but the principle remains the same:

Create reusable logic and manage the associated data in a structured way.

 

Why Not Put Everything in OB1?

A beginner may think:

“If OB1 can do everything, why should I create FCs and FBs?”

Technically, a lot of logic can be written directly in OB1.

But imagine a large manufacturing line with:

• 50 motors
• 20 valves
• 10 conveyors
• Multiple pumps
• Several sensors
• Safety interlocks
• Alarms
• Sequence control
• HMI communication

If everything is written inside OB1, the program can become difficult to understand, troubleshoot, modify and maintain.

Good PLC programming is not only about making the machine run.

It is also about creating a program that another engineer can understand months or years later.

That's why structured programming matters.

 

The Real Industrial Advantage: Standardization

One of the biggest benefits of FB programming is standardization.

Suppose an organization develops a standard motor FB.

The same FB can potentially be used across multiple projects according to the company's programming standards.

This means engineers don't need to develop motor logic from scratch every time.

They can reuse the tested structure.

This can improve:

• Development time
• Troubleshooting
• Maintenance
• Standardization
• Program readability
• Project consistency

And when a standard function needs improvement, the organization can manage that improvement systematically according to its software architecture and project requirements.

 

The Simplest Way to Remember OB, FC and FB

For beginners, I usually explain it in three simple lines:

OB

OB organizes and executes the program.

FC

FC performs logic without its own instance DB.

FB

FB performs logic with associated instance data stored in an Instance DB.

Or even more simply:

OB → Program execution

FC → Reusable logic/calculation

FB → Reusable logic + instance data

This simple understanding gives students a strong foundation for advanced Siemens PLC programming.

 

Is FB Always Necessary?

There is one important clarification.

FB is not required for every piece of PLC logic.

You should not use FB simply because it exists.

If you need a simple calculation, scaling operation, comparison, or reusable logic without dedicated instance data, an FC may be a better choice.

If you have a reusable equipment function that needs associated data and state, an FB is often a better architecture.

The objective is not:

“Use FB everywhere.”

The objective is:

“Choose the correct block based on the programming requirement.”

That is the mindset an automation engineer should develop.

 

Final Thought

When students first start working with TIA Portal, OB, FC and FB can appear to be just three different programming blocks.

But they represent something much more important:

Different approaches to structuring an industrial control program.

As machines become more complex, structured programming becomes increasingly important.

The goal of PLC programming is not only to make the machine work.

It is to make the program:

Readable.
Reusable.
Maintainable.
Scalable.
Standardized.
Easy to troubleshoot.