Execution and Synchronization Manager (ESM)

PLCnext Technology also features task handling. The ESM performs task handling, monitoring and chronological sequencing of programs from different programming languages. Each processor core of a controller is managed by one ESM. One ESM is therefore assigned to one processor core. If a controller has more than one processor core, then there are also several ESMs. For example, AXC F 2152 has 2 processor cores and 2 ESMs.

Note: There's a visual explanation to the ESM and its companion, the Global Data Space (GDS), available in a tutorial video.

The ESM offers the following advantages:

  • Configuration and monitoring of cyclic tasks and idle tasks.
  • The execution times of the tasks are available as system variables and can be used for diagnostics.
  • System balancing.
  • Multi-core systems are supported.

Note: When planning a project that depends on task-synchronous real-time data logging (e.g. by means of the DataLogger), it is highly recommended to select the hardware according to a maximum CPU load of 70 to 80 percent, visible in the PLCnext Engineer cockpit (show where to see the CPU loadshow where to see the CPU load) or in the WBM cockpit (available from firmware version 2023.0 LTS). 

The ESM can also be used to execute programs and program parts in real time that were created in different programming environments. These can include high-level languages such as C++, IEC 61131‑3 code, and model-based tools such as MATLAB®/Simulink®. Program parts that were created using different programming languages can also be combined and processed within a task. The ESM controls the processes and also executes the high-level language programs deterministically in the defined order. To ensure data consistency between the tasks at all times, all data is synchronized with the GDS whenever a task is called up (see also in GDS).

Example: Inter-task communication via ESM and GDS

ESM tasks

The ESM instructs and monitors the underlying operating system (Linux with PREEMPT-RT patch) how to schedule the ESM tasks. Each task is executed according to its priority. The priority of an ESM task is between 0 (highest) and 15 (lowest) and the ESM maps these to priorities of the underlying real-time operating system. It is recommended to use each priority only once within each ESM. Configuring two tasks with the same priority within the same ESM leads to an unpredictable execution order of these tasks. Preemptive scheduling is effective:
A task with a higher priority is executed completely before a task with lower priority can be executed. A task of lower priority can be interrupted as long as tasks of higher priority need to be executed.
Each task is identified by its name, which must be unique within the controller.
Within each task one or more program instances are executed in the configured order. Additionally, all necessary GDS connectors are executed.

There are different types of ESM tasks:

  • CyclicTask
    Tasks executed at equidistant intervals
  • IdleTask
    Task with the lowest priority (lower than any other ESM task). After each execution the next activation will be scheduled after a wait duration. This wait duration is proportional to the time needed for execution. In addition, a minimum wait duration is effective. This limits the CPU load caused by the idle task. Per each ESM only one task of type Idletask is allowed.
  • PreDefinedEventTask
    System event task which is executed once when the selected event occurs (e.g. cold restart, warm restart, hot restart, stop, exception)
  • UserDefinedEventTask
    Event task which is executed once when a user-defined event occurs. The user-defined event is identified by its name. Its occurrence can be triggered by the C++ class RtEvent.

The ESM configuration and the needed execution times of the tasks are available as system variables and can be used for diagnostics (see System variables - ESM tasks ).
Per each ESM task a task watchdog can be configured. When the task execution (including interruptions by tasks with higher priority) needs more time, a Task Watchdog exception is thrown (see section Exceptions in an ESM task below), the corresponding PreDefinedEventTask Arp.Plc.Esm.OnStop (if configured) is executed and the PLC Manager changes to PlcState::Stop. In addition, a notification is emitted to the notification log.

Note: Due to performance considerations, a task watchdog is not immediately detected. The PLCnext firmware implements two mechanisms to detect a task watchdog.
By the first mechanism the ESM task itself checks the needed time when the task has been executed completely. Because this mechanisms cannot detect endless loops in an ESM task, the firmware creates another task which is executed cyclically with a priority higher than any ESM task. The interval time of this task is calculated using the greatest common divisor of the interval times of all cyclic tasks. The task checks the execution time of all active ESM tasks. Therefore, a task watchdog is not detected immediately but still in a timely manner.

Related to the task watchdog there is an execution time threshold counter. The execution time threshold can be configured per each ESM task. On each execution of that task the needed execution time is compared to the configured threshold time. If more time than configured was needed, the execution time threshold counter is incremented. This counter can be checked as EXEC_TIME_THRESHOLD_CNT in the TASK_INFO structure which exists per each task in the ESM_DATA system variable.

Exceptions in an ESM task

The code executed by an ESM task may throw an exception. Such exceptions can be caused by the code itself (e.g. accessing invalid memory or division by zero) as well as by the occurrence of a task watchdog. If such an exception is thrown and not handled by the code itself, it will be caught by the ESM task. In this situation the ESM will stop to schedule any further ESM task for all CPU cores. The other tasks that are already running continue their current execution. When these tasks have finished their execution, the notification about the exception is emitted. Next, the predefined event task Arp.Plc.Esm.OnException (if configured) is executed. As last step the PLC is set to PlcState::Stop and depending on the exception type the additional state information may be set PlcState::Error or PlcState::FatalError. In case of FatalError the application is in an inconsistent state and only a reboot is allowed as a valid next transition to establish a consistent state (see also Available PLC states ).

Note: Since the system variable ESM_DATA is updated by the GLOBALS task, the corresponding IEC 61131‑3 system variables were usually not updated when the event task is executed. To retrieve information which exception was thrown in case of IEC 61131‑3 programming, use the function block GET_EXCEPTION_INFOS. For details, see also System variables - ESM tasks.

Task configuration using PLCnext Engineer

You can use the PLCnext Engineer software to easily create and configure tasks. Here, you can proceed as in a conventional IEC 61131‑3 program. The IEC 61131‑3 program, or the program created in a different programming environment and then imported into PLCnext Engineer, can be instantiated in a task. It does not matter whether the programs were created with C++, IEC 61131‑3 or MATLAB®/Simulink®.

In the PLCnext Engineer  Tasks and Events editor, you can instantiate a task and assign it to the desired program instances. See an example of tasks and program instances in PLCnext Engineer here:

Programminstanzen_des_Main_Tasks.png

A description of this procedure and further information on task handling with PLCnext Engineer is available in its Online Help.

Tip: Starting with release 2022.0 LTS, the PLCnext Engineer embedded help is also online available.

Task configuration via configuration files

When a project is downloaded from PLCnext Engineer to the controller, the previous configuration files are overwritten with the new configuration files. Manual configuration describes how you can safely store your manually modified configuration in the controller file system, thus preventing the loss of data.

You can also modify the task configuration, the instantiation of programs and the assignment to a processor core (one ESM per processor core) via configuration files in XML format without using PLCnext Engineer. All of the important settings can be configured directly in the configuration file on the controller. To modify the configuration manually, the XML file can be edited using any editor. The ESM can load one or several configuration files and create a joint configuration.

The ESM configuration documents consist of the following XML sequences:

Tasks

The ESM tasks are configured with their name and properties.

EsmTaskRelation

Configures which task is assigned to which ESM (CPU core).

Programs

Configures all program instances. Please note that IEC 61131-3 programs can be instantiated by PLCnext Engineer only, because these instances have to match to code and data downloaded to the eCLR runtime, too.

TaskProgramRelation

Configures which program instance is executed by which ESM-Task and in which order of that task.

TaskEvents

Configures events that are triggered by the ESM task. Each event can be triggered at the beginning or at the end of each task execution. Currently only the Axioline fieldbus provides such events (see below).

Example of a configuration file:

<?xml version="1.0" encoding="utf-8"?>
<EsmConfigurationDocument xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" schemaVersion="1.0" 
xmlns="http://www.phoenixcontact.com/schema/esmconfig">
   <Tasks>
      <PreDefinedEventTask name="Cold"  eventName="Arp.Plc.Esm.OnColdStart" confirmed="false" priority="0" 
       watchdogTime="100000000" executionTimeThreshold="0" />
      <PreDefinedEventTask name="Warm"  eventName="Arp.Plc.Esm.OnWarmStart" confirmed="false" priority="0" 
       watchdogTime="100000000" executionTimeThreshold="0" />
      <PreDefinedEventTask name="Except"  eventName="Arp.Plc.Esm.OnException" confirmed="false" priority="0" 
       watchdogTime="100000000" executionTimeThreshold="0" />
      <IdleTask name="Idle"  watchdogTime="100000000" executionTimeThreshold="0" />
      <PreDefinedEventTask name="interbus"  eventName="Arp.Io.Interbus.OnCycleEnd" confirmed="true" priority="0" 
       watchdogTime="100000000" executionTimeThreshold="0" />
   </Tasks>
   <EsmTaskRelations>
      <EsmTaskRelation esmName="ESM1" taskName="Cold" />
      <EsmTaskRelation esmName="ESM1" taskName="Warm" />
      <EsmTaskRelation esmName="ESM1" taskName="Except" />
      <EsmTaskRelation esmName="ESM1" taskName="Idle" />
      <EsmTaskRelation esmName="ESM1" taskName="interbus" />
   </EsmTaskRelations>
   <Programs>
      <Program name="Main1" programType="Main" componentName="Arp.Plc.Eclr" />
      <Program name="Main2" programType="Main" componentName="Arp.Plc.Eclr" />
      <Program name="Main3" programType="Main" componentName="Arp.Plc.Eclr" />
      <Program name="Main4" programType="Main" componentName="Arp.Plc.Eclr" />
      <Program name="Main5" programType="Main" componentName="Arp.Plc.Eclr" />
   </Programs>
   <TaskProgramRelations>
      <TaskProgramRelation taskName="Cold" programName="Arp.Plc.Eclr/Main1" order="0" />
      <TaskProgramRelation taskName="Warm" programName="Arp.Plc.Eclr/Main2" order="0" />
      <TaskProgramRelation taskName="Except" programName="Arp.Plc.Eclr/Main3" order="0" />
      <TaskProgramRelation taskName="Idle" programName="Arp.Plc.Eclr/Main4" order="0" />
      <TaskProgramRelation taskName="interbus" programName="Arp.Plc.Eclr/Main5" order="0" />
   </TaskProgramRelations>
   <TaskEvents />
</EsmConfigurationDocument>

 

Be aware of the XML entities when editing XML configuration files: 
There are symbols in the XML code that cannot be represented as attribute values because they have a syntactical function.

For example, the characters < and > are used for opening and closing XML tags. To be able to use these characters as attribute values in their genuine meaning "less than" or "greater than", entities are required.

The following entities are predefined in the XML specification. Make sure to use these entities in attribute values to avoid XML parsing errors.

Character Entity
Ampersand (& &amp;
Single quote (') &apos;
Double quote (") &quot;
Less than (<) &lt;
Greater than (>) &gt;

Defining a task

To configure tasks for execution in the ESM (Execution and Synchronization Manager), use the *.esm.config configuration file. A task is defined between the tags <Tasks> and </Tasks>

Example of a task definition:

<Tasks>
  <CyclicTask name="SquareWave_Cycle" priority="0" cycleTime="100000000" watchdogTime="100000000" executionTimeThreshold="0" />
  <CyclicTask name="CPP_Cycle"  priority="1" cycleTime="100000000" watchdogTime="100000000" executionTimeThreshold="0" />
  <CyclicTask name="PCWE_Cycle"  priority="2" cycleTime="100000000" watchdogTime="100000000" executionTimeThreshold="0" />
  <PreDefinedEventTask name="Cold"  eventName="Arp.Plc.Esm.OnColdStart" confirmed="false" priority="0" 
   watchdogTime="100000000" executionTimeThreshold="0" />
</Tasks>

Definition of the task starts with the task type.

Here, enter the type (see task types):

  • CyclicTask
  • IdleTask
  • PreDefinedEventTask - System event task (cold restart, warm restart, hot restart, stop, exception)
  • UserDefinedEventTask

Define the tasks using the attributes from the following table:

Attribute Description

name

The name attribute defines the task name.

Enter a unique  task name. It can only be used once per controller.

priority

The priority attribute defines the task priority.

Enter a value to specify the task priority.

0: Highest priority

15: Lowest priority

For the idle task no priority can be specified. Its priority is automatically lower than the lowest priority.

Note: Within one ESM, each task must be assigned a different priority. Configuring two tasks with the same priority within the same ESM leads to an unpredictable execution order of these tasks.

cycleTime

The cycleTime attribute defines the duration of the task (for cyclic tasks only).

Enter the value in nanoseconds.

The minimum value value depends on the controller and is listed in the related user manual of your controller. For example, the AXC F 2152 controller provides 1 ms (1,000,000 ns). Select a multiple of the minimum value. Depending on the application, the jitter time for a task may increase as the system load increases.

watchdogTime

The watchdog monitors whether the task was executed within the specified time.

Enter the value in nanoseconds. Value 0 means that there is no monitoring.

Note: The watchdogTime for the three event task types Arp.Plc.Esm.OnStopArp.Plc.Esm.OnStop2 and Arp.Plc.Esm.OnPowerDown is limited to a maximum of 500 ms (for controllers with or without an integrated UPS)

EventName

The following values are valid for PreDefinedEventTask:

For stopping and powering down on controllers without integrated UPS:

  • Arp.Plc.Esm.OnStop (displayed as Stop in PLCnext Engineer)

For stopping and powering down on controller with integrated UPS with firmware 2023.6 or newer:

  • Arp.Plc.Esm.OnStop (displayed as StopAndPowerDown in PLCnext Engineer)
  • Arp.Plc.Esm.OnStop2 (displayed as Stop in PLCnext Engineer)
  • Arp.Plc.Esm.OnPowerDown (displayed as PowerDown in PLCnext Engineer)

Note: The watchdogTime for the three event task types Arp.Plc.Esm.OnStopArp.Plc.Esm.OnStop2 and Arp.Plc.Esm.OnPowerDown is limited to a maximum of 500 ms (for controllers with or without an integrated UPS)

The following applies forUserDefinedEventTasks:

This event task is executed once when a user-defined event occurs. The user-defined event is identified by its name. Its occurrence can be triggered by the C++ class RtEvent

  • The name must not start with Arp
  • The name must be the same as the name specified in the C++ code when using the RtEvent class. 

Stopping and powering down on UPS-backed controllers

Available on AXC F 3152RFC 4072SRFC 4072R, or BPC 9102S from firmware 2023.6 or newer, and a current PLCnext Engineer release

While powering down a regular controller obviously stops all tasks, that can be different when using a controller with an integrated uninterruptible power supply (UPS). There, the power-down sequence provides two additional, separate tasks: 

The Arp.Plc.Esm.OnStop2 is executed once just when stopping the controller by means of PLCnext Engineer or a button in the Cockpit view of the Web-based Management.

The Arp.Plc.Esm.OnPowerDown is executed once when the power supply of a UPS-backed controller goes down.

This way you can handle these events differently in programming if you want.

The Arp.Plc.Esm.OnStop task for both stopping and powering down is still available with these devices. If a Stop event is configured, neither an OnStop2 nor an OnPowerDown event can be used.

The ESM supervises all three events by a task watchdog that does not need to be configured explicitly.

Fieldbus-specific task definition

For some fieldbusses, specific event tasks can be configured. In addition, specific fieldbus behavior can be triggered by an ESM task.

Also, the update of IEC 61131-3 global variables that are connected to fieldbus I/O and the update of fieldbus related system variables can be bound to a certain ESM task (instead of using the GLOBALS task). This is configured using the <ComponentTaskRelations> element in the GDS configuration.

Axioline

The Axioline fieldbus exchanges its process data with the I/O modules in a dedicated task. Without any configuration, the Axioline fieldbus creates a cyclic task with an interval time calculated from the largest common divisor of the interval times of all configured cyclic ESM tasks.

In case that no cyclic ESM task is configured, the interval time is set to the smallest possible interval (depending on the PLC). If this is not desired, the I/O update of the Axioline fieldbus can be triggered by a configured ESM task. In order to trigger the I/O update with an ESM task myTask, add the following section to the task configuration file: 

<TaskEvents>
  <TaskEvent name="Arp.Io.AxlC.OnExecuting" taskName="myTask" event="Executing" />
  <TaskEvent name="Arp.Io.AxlC.OnExecuted" taskName="myTask" event="Executed" />
</TaskEvents>
Note: The Axioline fieldbus monitors the execution of its I/O update. Each time after one update has been performed, a timeout is started. If the next Axioline I/O update is not triggered within 25 ms, then the Axioline fieldbus by itself triggers an I/O update. Triggering after 25 ms only occurs if the task configured for triggering is of type IdleTask or EventTask (not for type CyclicTask).

INTERBUS 

The following information relates to an AXC F X152 controller in combination with an AXC F XT IB extension module only.

The INTERBUS fieldbus exchanges its process data with the I/O modules in a dedicated cyclic task. The interval time of this task can be configured in the INTERBUS configuration. If program execution needs to be performed synchronous to the INTERBUS I/O update, then the event task type Arp.Io.Interbus.OnCycleEnd can be used to configure an ESM task which is triggered by this cyclic INTERBUS I/O update task. When Arp.Io.Interbus.OnCycleEnd is configured, the related attribute confirmed has to be set to true (in all other cases this attribute can be omitted or has to be set to false).  

Assigning a task

Once the task has been defined, it has to be assigned to the desired ESM. Assignment is defined between the tags <EsmTaskRelations> and </EsmTaskRelations>.

Example: Assigning a task to an ESM

<EsmTaskRelations>
  <EsmTaskRelation esmName="ESM1" taskName="SquareWave_Cycle" />
  <EsmTaskRelation esmName="ESM1" taskName="CPP_Cycle" />
  <EsmTaskRelation esmName="ESM1" taskName="PCWE_Cycle" />
</EsmTaskRelations>

Assign the task using the attributes from the following table:

Attribute Description

esmName

The esmName attribute defines the name of the ESM the respective task is to be assigned to.

Enter the ESM name.

Example: ESM1 or ESM2 for a controller with dual core processor.

taskname

The taskname attribute defines the task to be assigned.

Enter the name of the task to be assigned.

Instantiating programs

Once the task is defined and assigned to an ESM, programs can be instantiated. Programs are defined between the tags <Programs> and </Programs>. The definition of a program instance is introduced with tag <Program>. Programs that have been programmed in IEC 61131-3 can only be sent and configured using PLCnext Engineer. The code example originates from a config file generated using PLCnext Engineer .

Example for instantiating programs:

<Programs>
   <Program name="SquareWave" programType="PCWE_SquareWave_P" componentName="Arp.Plc.Eclr" />
   <Program name="CPP_Counter" programType="CPP_Counter_P"  componentName="CPP_Counter.CPP_Counter_C-1" />
   <Program name="CPP_Counter_P1" programType="CPP_Counter_P" componentName="CPP_Counter.CPP_Counter_C-1" />
   <Program name="PCWE_Counter" programType="PCWE_Counter_P" componentName="Arp.Plc.Eclr" />
</Programs>

Instantiate programs using these attributes:

Attribute Description

name

The name attribute defines the name of the program instance.

Enter the name of the program instance.

The name must be unique within the controller.

programType

The programType attribute defines the program type.

Enter the program type.

componentName

The componentName attribute defines the name of the component instance that contains the program.

Enter the name of the component as it is defined in the *.acf.config or *.plm.config configuration file. The Arp.Plc.Eclr component is reserved for IEC 61131‑3 programs that were instantiated using PLCnext Engineer (see Working with Eclipse®)

Assigning program instances to a task

The program instances have to be assigned to a task. Assignment is made between tags <TaskProgramRelations> and </TaskProgramRelations>.

Assigning program instances to a task:

<TaskProgramRelations>
   <TaskProgramRelation taskName="SquareWave_Cycle" programName="Arp.Plc.Eclr/SquareWave" order="0" />
   <TaskProgramRelation taskName="CPP_Cycle" programName="CPP_Counter.CPP_Counter_C-1/CPP_Counter" order="0" />
   <TaskProgramRelation taskName="CPP_Cycle" programName="CPP_Counter.CPP_Counter_C-1/CPP_Counter_P1" order="1" />
   <TaskProgramRelation taskName="PCWE_Cycle" programName="Arp.Plc.Eclr/PCWE_Counter" order="0" >
</TaskProgramRelations>

Assign the program instance to a task using the attributes from the following table.

Attribute Explanation

taskname

The taskname attribute specifies the name of the task the program instance is to be assigned to.

Enter the name of the desired task the program instance is to be assigned to.

programName

The programName attribute defines the name of the program instance with the prefixed library and component names. The name is used to select the program instance to be processed in the task.

Enter the full name in the program instance to be processed.

order

The order attribute determines the order in which program instances are processed within a task, starting with 0.

Enter a number to determine the processing sequence.

The program instance with the digit 0 is processed first. Each number can only be used once for each task.

 


• Published/reviewed: 2024-09-24   ☀  Revision 073 •