IEC 61131-3 Functions and Function Blocks: What is the difference?

IEC 61131-3 Functions and Function Blocks: What is the difference?

Engineers that understand the power of both function blocks and functions has a great advantage when programming applications. This article describes these programming features of the IEC 61131-3 language standard and provides clear guidelines for the selection and use of each.

This article looks more deeply into the software model promulgated by that standard and, in particular, discusses the similarities and differences between Functions and Function Blocks.


Figure 1 depicts the software model outlined by IEC 61131-3.

Decomposition of this model begins at the “Configuration” level which encompasses the presence of multiple controllers in a distributed environment. Packaging lines represent an example of this level since a single line may contain multiples stages of the packing operation. This line might include a cartoner, case erector, case packer, shrink-wrapper, labeler, and palletizer each with its own controller. Beneath this level is the “Resource” level which represents a single control resource such as a PLC or Programmable Automation Controller. If the control resource is designated with “multi-tasking capability the next level of decomposition accounts for this capabiilty by standardizing the configuration and of the “Tasks” charged with execution control of the resource project.

Whether under control of the tasks, or simply by direct call from the firmware scheduler, the goal is the execution of finite “modules” of functionality in the form of Program Organization Units (POUs). The IEC 61131-3 software model defines 3 types of POU:

1) Programs
2) Function blocks
3) Functions

This article is intended to differentiate between the latter 2 program organization units, function blocks and functions, and provide clear guidelines for the selection and use of each.

MEMORY IS THE KEY The key to understanding the difference between function blocks and functions is an appreciation for a software object’s need or lack of need to maintain information in the form of “internal memory” between invocations.

Let’s compare two activities (functional objects) which one might choose to “invoke” during the execution of a normally daily routine:

1) BrushTeeth
2) AnswerEmails

In the first example there might be a set of inputs such as:

1) Morning
2) BadBreath
3) ObligatorySocialInteraction

All of which collectively invoke the need to execute the BrushTeeth function. The single output from this function might be: CleanTeeth.

Since there is no conditional result to this activity, there is no need to store information about the “last” invocation of the “BrushTeeth” object. It is not necessary to “remember” how many strokes of the brush were used last time or whether brushing started with an up-stroke or a down-stroke. There is no requirement for storing this information since this data will have no impact on how BrushTeeth is executed tomorrow. Thus, the BrushTeeth function is invoked when needed , its result reaped and the instructions removed from memory upon completion of the activity.

Another way of stating this is that for the same input parameters this method will have the same output every time. This is the classic description of a function.

“Given the same input parameters a function will always return the same result.”

Let’s look at a software example of a function. Suppose we are asked to develop the code for a controller that will allow it to calculate the hypotenuse of a right triangle when supplied with the value of two input variables: SideA and SideB.

For the standard 3, 4, 5 triangle we know that, no matter how many times we feed a SideA value of (3) and a SideB value of (4) to this function, it will always return the value of 5 for the Hypotenuse. In other words, there is no “unique” output for this function predicated on the number of times it is invoked. The reason that the same value is returned EVERY time is because there is no internal memory for the function which would impact its execution differently from one invocation to the next.

Given this explanation of a function it becomes apparent that the decision regarding whether and when to use a function is centered on the need for memory within the object.

Ask yourself: Will this object ALWAYS return the same output ANY time it is supplied with the same inputs?
If the answer is YES you have just described a function. If, in contrast, there will be different outputs based on the condition of internal memory, it should be coded as a function block.

There are some additional attributes to a function that need to be considered.

1) A function does not have “outputs” in the strictest sense of the term. Instead it has a return value.
2) The return value will have the same identifier as the function itself.
In other words, when I invoke the Hypotenuse function the value of the result is returned in the identifier Hypotenuse.
3) Since the Function identifier (Hypotenuse) is the “container” for the result value, it must be assigned a data type.
For example: If the data type for SideA and SideB is REAL then Hypotenuse will most likely also return a REAL value.
Written in Structure Text the call to Hypotenuse (shown in Fig. 2 in Function Block Diagram) would be as follows: FinalSide:= Hypotenuse (SideA:=Side1, SideB := Side2);
In this case both the variable FinalSide and the function identifier Hypotenuse would be declared as having the REAL data type.
4) Because the Hypotenuse function will be invoked only when needed and since it will always return the same value whenever it is supplied with the same parameters, it is unnecessary to create copies (instances) of the function and therefore unnecessary to distinguish these instances with unique instance identifiers.
We will see that this is in direct contrast with the requirement for function blocks which can be “instantiated” and which must provide instance identifiers.


Unlike the BrushTeeth function, the AnswerEmail object requires internal memory. In this case it IS important that memory be retained in order to correctly respond to the input parameters. Imagine a situation where the input: “Have you finished that article for” was always met with the same output: “NOT YET!!!”.

It is obvious that accumulated data regarding the current state of the process will influence the output in response to the same input.

In contrast to functions, function blocks can change their output even when the inputs are identical from one invocation to the next.

A classic example of a function block is the TimeOnTimer (TON) function block which is standard with IEC 61131-3 compliant Integrated Development Environments (IDEs).

Fig 3 shows the variable declaration and code icon for a TON function block. This is just the “blueprint” for a TON and as such outlines the input and output data which is associated with this software object.

Looking at the inputs we see:

1) IN is an input of the BOOL data type
2) PT is an input of the TIME data type

Looking at the outputs we see:

1) Q is an output of the BOOL data type
2) ET is an output of the TIME data type
Since the ET variable retains the elapsed time of the TON it is conceivable that any unique copy (instance) of the TON function block could have a unique value for this variable. Given this, the repeated input of a TRUE state for the IN variable could result in a unique (different) value for the PT output. Thus, we see the principle difference between functions and function blocks is the fact that internal memory allows function blocks to return different outputs despite repetition of the same input. This means that any time we wish to use the TON function block we need to create a separate “instance” of the blueprint for the TON. This process is known as instantiation and results in reservation of the memory needed to host the data needed by the software object. In the case of the TON function block this means that every copy of the TON will contain the 6 variable listed in the declaration section of the object description. For this reason it is necessary to give each “instance” of the TON a unique instance identifier.

Here is a list of the attributes of a function block:

1) Function blocks must first be crated as “class” objects. That is, the blueprint of the object must be declared and all input, internal and output variables created.
2) The function block has no “return value” as was seen with the function but rather can return a number of separate outputs as declared in the variable definition for the class object.
3) Function blocks must be instantiated from the class object.
4) Each instance of the class object must receive an instance identifier.

Hopefully, this information will ease some of the confusion regarding the differences between functions and function blocks as standardized by IEC 61131-3. Happy coding!

Dr. Ken Ryan is Director of the Center for Applied Mechatronics at Alexandria Technical College in Alexandria, MN. He has been teaching IEC 61131-3 courses for students at the Center and for industry clients throughout North America for 10 years. The Center for Applied Mechatronics offers on-site and online PLCopen Certified IEC 61131-3 training for technology providers, OEMs and end users.

Dr. Ryan is also a PLCopen board member.

click here to visit the PLCopen website