Advanced task definition

Patron Neuron Gate Unipi 1.1 Axon

In the Mervis system, it is possible to define the tasks to be run in the controller (RT). A task is a definition of conditions for running a selected/mapped program or several different programs in a specified order.

In the simple mode of the solution, one task is always defined that repeatedly executes the main.program.fbd program and this cannot be changed. If multiple controllers in the project are desired, run multiple different programs, or condition the execution of a program, it is necessary to have the solution in full mode.


This guide describes how and where to define tasks, what categories and types of tasks exist, including how to optimized program execution, error handling, their logging and eventually self-repair.

Double-clicking the controller name in the left panel of the solution will display a list of defined tasks with their properties.

Default list of controller tasks (created in Simple mode):


Tasks have the following properties:

Properties Meaning
ID Task identification number
Category Task category, described in Task categories
Task Custom task name
Priority Priority, with which the task will be executed, zero being the highest priority
Program Mapping Assigning a specific program to a task
Type Type of task run, described in Task types
Parameters Parameters vary depending on the type used

Task categories

There are four categories of tasks, but only two are used:


NormalOperationTask - Normal operation, default option for each task. The task is executed according to the specified type and parameters.

ExecutionError - Triggers in case of a critical NormalOperationTask error (e.g. division by zero). If a job with this category is created, the job ID is automatically changed to the last (highest) ID. There can be only one job with this category.

Mervis IDE allows you to create multiple NormalOperationTask categories, provided that the first one is of the Freewheeling type, or Cyclic and the other tasks in this category will be of type Event only. The task types are described in detail below.

If running the program continuously is a higher priority than running without errors and logging them, it is possible to disable the Stop on Exception option in the controller properties and never run a job of type ExecutionError:

Program mapping

By double-clicking in the box under Program Mapping the window will be displayed:

In this window, the desired program is selected by clicking on it and added by clicking the Add → button.

If the desired program is not displayed in the list, you need to compile the solution.

Task types

Task type defines how the task is executed.

Type Meaning
Freewheeling Normal execution, pause between cycles according to % setting
Cyclic The task is started periodically according to the defined interval in ms
Event The task is executed if the defined condition is met

1. Freewheeling

Setting the Freewheeling type means that the task will be executed over and over again, according to the controller's capabilities.

The Sleep Ratio parameter specifies the sleep time before the next cycle starts. The time is given as a percentage of the duration of the last cycle. Example: if one cycle takes 10 ms and Sleep Ratio will be set to 30%, controller will run the next cycle after 3 ms.


2. Cyclic

If the Cyclic type is set, the job will be executed every fixed period [ms].

For longer periods, it is convenient to use the ST syntax, for example, when setting the period of 2 h and 30 min, write the value t#2h30m (TIME data type) instead of the number 8400000.


3. Event

The Event type setting provides conditional execution of the task that can be executed one or repeatedly in reaction to the selected variable value. There are 4 options in total:

Trigger condition Meaning
Rising Edge Single task execution at the rising edge
Falling Edge Single task execution on the falling edge
High Level Continuous task execution at TRUE value
Low Level Continuous task execution at FALSE value

After expanding the variable parameter, a window with a list of variables appears, the desired variable can be added by selecting it and clicking the Add → button.

To run a task of the event type, it is necessary to select as the trigger variable a variable that is used in the main program. To use a variable in FBD, just connect it to itself:

The same rule applies to commerror and other attributes.

After generating the solution in simple mode, a task with a mapped main program is automatically created for the controller. When the solution is created in full mode, the program and task must be created and mapped manually.

To add a task, simply right click anywhere in the open window and then select Add task from the context menu.

Task creation and any modification must be confirmed by clicking OK in the red bar.

Warning!
All changes to the task must always be confirmed by clicking OK in the red bar.

Setting the safe state of the controlled device

Safe values are those that cannot endanger the life and health of the worker or damage the equipment. If an exception occurs during program execution (e.g. division by zero), NormalOperation will be stopped and the ExecutionError task will be started.

1. Example of a safe condition of the device "Sawmill"

The device operating the saw. When a program error occurs, the NormalOperation task is stopped and the ExecutionError task is started, which stops the saw blade and feeder. This error condition treatment avoids potential injury to workers or saw damage.

2. Example of a safe condition of the equipment "Cement Plant"

A machine operating a filler in a cement plant. When a program error occurs, the NormalOperation task stops and the ExecutionError task starts, which closes the hopper flaps. This error condition treatment avoids unnecessary material loss.

NOTE It is good practice to set the default values of the I/O boards to safe values.

After error condition is taken care of, to restart the NormalOperationTask task it is necessary to put the RESUMENORMALTASK function into the ExecutionError task.


Notification by email/SMS, or optically signalling fault by ULED

It is possible/appropriate to inform the relevant persons about the error condition by email/SMS and to record this condition by triggering an alarm. A detailed description of the notification settings can be found in the separate articles about email-sending and SMS respectively.

For illustration, it is possible to add optical signalling e.g. on the user LED X1, or to switch the DO/RO output with a connected signalling device.

Usage of Event type

1. Starting a single action

On a rising edge of the DI single action will be called - affecting a program parameter, sending a report, or calculating a new value based on the event.

2. Switching between two programs

Depending on the value of a DI, two different programs will be executed (false program1 and true program2). This is useful mainly for FBD, as in ST you can get the same behavior by using IF condition.

3. Executing programs with defined time period

Block BD2 (pulse generator) will generate pulses, which could execute another program. It's convenient to use in cases, in which we need to repeatedly run another program, but undesirable to run every computation cycle (to save up computational performance).