dl-breadcrumbs__homedl-breadcrumb-item__separatorConfiguration and programmingdl-breadcrumb-item__separatorProgramming with CODESYSdl-breadcrumb-item__separator...dl-breadcrumb-item__separatorAutomation Builderdl-breadcrumb-item__separatorProgramming of Applications dl-breadcrumb-item__separatorTask Configuration
dl-pagination__prev-inactivedl-pagination__prev-activedl-pagination__next-inactivedl-pagination__next-active
Task Configuration dl-permalink__symbolPermalink

Task configuration

In the task configuration, you define one or more tasks to control the flow of programs (POU objects with Program type) and the POUs called from them on your device. A Task Configuration object is required for each application. This is where you define the chronological sequence for calling up the program.

A task is the chronological flow unit for your IEC program. The task defines the call chain of your POUs (call hierarchy).

Each task requires a unique name. In the task configuration editor, specify a list of programs to be called. The programs can be application-specific, in which case the program is located in the Devices view. Or a program can be valid throughout the entire project, in which case the program is located in the POUs view. These POUs are instantiated in the entire project.

  • It is possible to prioritize a task. Prioritization works in combination with the task type.

  • You configure a task type:

  • Cyclic; for a time-controlled flow using a cycle interval. The program calls are run through within the cycle interval (task cycle time).

  • Freewheeling; for a task without its own task cycle time

  • Event-triggered (internal or external) by means of a condition for the event start (edge-triggered).

  • Examples of an event include the rising edge of a global project variable or an interrupt.

  • Status-triggered via condition

  • It is possible to couple Start, Stop, and Reset directly with the execution of the project POU.

  • You can also activate a watchdog.

The call stack is created and executed based on these settings in the task configuration.

Based on the various possible call stacks, it is determined which of these is the longest with the highest memory requirement (maximum call stack). For detailed information about this, see the Stack Usage tab.

Process order

Rules for the processing order of the defined tasks

  • If the task condition is fulfilled, then CODESYS processes the task.

  • If multiple tasks fulfill the condition for processing at the same time, then CODESYS processes the tasks with the highest priority first.

  • If multiple tasks with the same priority level fulfill the condition for processing at the same time, then CODESYS processes the task first which has been in the queue the longest.

  • The program calls are processed in the order they appear in the configuration dialog of the task.

  • If a called program has the same name in the device tree of the application and in a library or project-global in the POU view, then the application program is used.

Important Notes

All tasks share one process image. The reason is that having an individual process image per task would compromise performance. However, the process image can be consistent only with one task. When you create a project, you must ensure that the application copies the input and output data to a safe location in case of conflicts. Modules, such as the library ‎SysSem‎, provide the capability of solving consistency and synchronization problems.

Consistency problems can also occur when accessing other global objects, such as global variables or blocks. Consistency problems always occur if several tasks read and write to one variable. Modules, such as the library ‎SysSem‎, are available as a solution.

Helpful Hintsdl-permalink__symbolPermalink

All tasks share one process image.

The reason for this is that a separate process image for each task would compromise performance.

Moreover, a process image can be consistent only for one task. This avoids inconsistencies if all tasks share a process image.

When you develop a project, you need to make sure that the input data (VAR_INPUT) is copied to a safe location in the event of a conflict. This also applies to output data (VAR_OUTPUT).

POUs, such as the SysSem library, provide the capability of solving consistency and synchronization problems. Consistency problems can also occur when accessing other global objects (global variables or POUs). Consistency problems always occur when multiple read and write to one variable. The POUs of the SysSem library can also help to resolve these kinds of conflicts.

  • Configuring a Task
  • Freewheeling IEC Task
  • Definitions of Jitter and Latency
  • Calculation of the Stack Usage
  • Multicore