Coder's Corner: The IEC 61131-3 Software Model

Coder’s Corner

By Dr. Ken Ryan, Alexandria Technical College & PLCopen Board Member

Article 2
This is the second in a series of articles focused on writing code using the IEC 61131-3 programming standard. The first few articles will focus on orientation to the architecture of the standard and the data typing conventions. After covering these, this series will explore code writing for a diverse field of application situations.


Figure 1

The IEC 61131-3 standard has a hierarchal approach to programming structure. The software model in Figure 1 depicts the block diagram on this structure. In the first Coder’s Corner we decomposed this structure from the top down. This article will focus on the Task sub-element of the architecture. Tasks are depicted in dark blue just below the Resource level in the software model seen above.

Task: IEC 61131 defines a task as “an execution control element which is capable of invoking, either on a periodic basis or upon the occurrence of the rising edge of a specified Boolean variable, the execution of a set of program organization units, which can include programs and function blocks whose instances are specified in the declaration of programs.”

Tasks are the execution control mechanism for the resource. There may be no specifically defined task or multiple tasks defined for any given resource. If no task is declared the runtime software needs to have a specific program it recognizes for default execution. This would be the default program the PLC will execute in the “RUN” mode. This is analogous to the “Main” program in a C++ environment. As you can see from Figure 1 tasks are able to call programs and function blocks. However, some implementations of the IEC 61131-3 standard limit tasks to calling programs only and not function blocks.

Tasks have 3 attributes:
1. Name
2. Type – Continuous (default, freewheeling), Cyclic or Event-based
3. Priority – 0 = Highest priority

Figure 2

Figure 2 demonstrates the timing of 5 tasks in one project. The tasks are arranged in ascending order with the highest priority task (FastTask) located at the top. Notice that in this example all tasking is “preemptive”. In other words a higher priority task does not need to wait for a lower priority task to complete but can preempt the lower priority task’s access to the controller in order to execute its associated Program Organization Unit (POU). In this case The default task is “calling” P5 and P6. The colored task signals at the top of the diagram indicate that DefaultTask (red) is in the ready state at the far left of the graft. However, since both FastTask (blue) and MainTask (green) are ready at the same time and have respectively higher priority, DefaultTask must wait its turn for execution. Once begun, DefaultTask is next preempted in the middle of P6 due to the recurrence of the 10ms, higher priority FastTask.

Notice also the preemption of MainTask later by EventTask which invokes P2 and has a higher priority than MainTask.

With careful attention to the priority, type, interval and associated program call it is easy to see the rich program execution control that can be applied with proper task management.


Figure 3 is an example of how tasks might be configured in an IEC 61131-3 implementation. (CoDeSys V3)

This is the configuration for the graph example of Figure 2. Each task (alphabetically not priority listed) will have an associated program from among those listed for the application.

We will look at how the attributes of these tasks are configured in the figures that follow. 



Figure 4 outlines the configuration of FastTask

  • Priority = 1
  • Type = Cyclic
  • Interval = 2ms (high speed motion bus cycle)
  • Watchdog = enabled (5ms)
  • Associated POU = MotionProgram




 Figure 4

Figure 5

Figure 5 outlines the configuration of EventTask

  • Priority = 2
  • Type = Event driven
  • Event = SafetyTrigger
  • Watchdog = Not enabled
  • Associated POU = SafetyProgram

Hopefully this small example gives you a sense of the flexibility provided by Task execution. The controller can be unburdened from slower logic tasks in order to focus bandwidth on more processor intense project domains like cyclic motion control and can still have a very robust monitoring for (COS) event driven execution.

It should be noted that multitasking is NOT required by IEC 61131-3 and that not all hardware will support multitasking. However, if implemented, tasking will follow the behavior outlined here. Unique aspects of task configuration are, of course, implementation dependent and the controls vender should be consulted prior to configuration of task with any potential to impact personal safety or equipment security.

The next article in this series will focus exclusively on Program Organization Units with particular attention to the differences between Programs, Function Blocks and Functions.

Code on…