Type

Type “Cyclic”

Processing of the task is done cyclically.

Input field “Interval”

Required

Time span after which the task is restarted (task cycle time)

As a time definition in the format ‎TIME‎

Example: ‎t#200ms‎
As a number

Example: ‎200‎

Hint: the number is displayed automatically in the format ‎TIME‎ when the input field is in focus again.

Note: Deviations of the task from this desired task cycle time are displayed at runtime as periodic jitter on the “Watchdog” tab.

Time unit of the interval

If only a number and not a time definition is specified in the “Interval” input field, then the unit selected here determines the time dimensions.

Example: “ms”

Note: A task cycle time in µs is always displayed as a number.

Type “Event”

Processing of the task starts event-controlled on the rising edge of the event variable.

Input field “Event”

Global variable (Boolean type)

The task starts as soon as the variable value switches from 0 to 1.

Type “External”

Processing of the task starts event-controlled on the rising edge of the event variable.

List box “Event”

List with target system-dependent events (Boolean type)

Note: The target system determines which events are supported and offered in the list box.

Hint: Not to be confused with system events

“Interval”

Time definition in TIME format or as a number with a time unit

Note: Only available when the event requires a time definition

“Freewheeling”

Processing of the task restarts automatically in a continuous loop at program start and after the end of a run after a certain waiting time

Important: After completing a run, a certain amount of time is waited before the task is executed again. The duration is a percentage of the last cycle duration.

Note: You do not define a cycle time.

“Status”

Processing of the task starts state-triggered by the event variables

Input field “Event”

Global variable (Boolean type)

When the variable has the state ‎TRUE‎, the task starts freewheeling. The task runs until the variable gets the value ‎FALSE‎.

Note: The variable is typically reset in the task itself. In contrast to the event task, no event can be missed in this way. When an event occurs, the scheduler must save an old value, and this can change more often than it is checked. So if an event variable changes to ‎TRUE‎ only for a short time, the scheduler might not detect this change. This can be avoided with a status task. The status variable is set to ‎TRUE‎ by some other task and reset by the status task. This makes sure that the task is executed once each time it switches to ‎TRUE‎.

NOTICE

For fieldbuses, a fixed cycle matrix is necessary to assure a determined behavior. Therefore, you should not use “Type” “Freewheeling” for a bus cycle task.

NOTICE

Note the following difference between the processing types “Status ” and “Event”. If the given event yields ‎TRUE‎, then the start condition of a task of type “Status” is fulfilled. In contrast, the start of a task of type “Event” requires a switch of the event from ‎FALSE‎ to ‎TRUE‎. If the sampling rate of the task scheduler is too low, then the rising edge of the event can remain unnoticed.

NOTICE

When setting the task cycle time, you have to identify which bus system is currently being used. For example, the task cycle time in a CAN bus system must match the currently set baud rate and the number of frames used in the bus. In addition, the times set for heartbeat, node guarding, and sync should always be a multiple of the task cycle time. If not, then CAN frames can be lost.

For more information, see: ⮫ “Tab: Monitoring ”

Table 623: Watchdog
Defines the time monitoring for a task. If the target system supports an advanced watchdog configuration, then the following settings may be predefined in the device description. Upper and lower limit Default watchdog time Time specified as percentage The default watchdog settings depend on the device.
“Enable”	The watchdog is active. If the task exceeds the currently set time of the watchdog, then the task is halted with an error status (exception). The application in whose task the error occurred and its child applications are also halted. In this way, all tasks of the affected applications are also halted. Then the currently defined Sensitivity is also taken into account. If you activate the option Update I/Os in the PLC Settings of the PLC, then CODESYS resets the outputs to the defined default values. Possible cases: Multiple consecutive timeouts: Sensitivity: 0, 1 – exception in cycle 1 Sensitivity: 2 – exception in cycle 2 Sensitivity: n – exception in cycle n Single timeout: Exception if the cycle time of the current cycle is longer than (time * sensitivity). Example: Time=t#10ms, Sensitivity=5 (i.e., exception as soon as the one-time task runs longer than 50 ms).
“Time (e.g. t#200ms)”	Watchdog time Defines (together with “Sensitivity”) the watchdog for a task; description as for “Enable”. Depending on the target system, the monitoring time span is given as a percentage of the task interval if possible. In this case, the list box for the unit is disabled and displays “%”.
“Sensitivity”	Number Defines (together with the watchdog) the watchdog for a task; description as for “Enable”.

Using the functions from the library ‎CmpIecTask.library‎, you can deactivate a watchdog for specific PLC cycles. This is useful for cycles that demand more time due to initialization.

Example

Deactivating/reactivating the watchdog:

VAR
hIecTask : RTS_IEC_HANDLE;
END_VAR

hIecTask := IecTaskGetCurrent(0);
IecTaskDisableWatchdog(hIecTask); //Watchdog disabled
...
IecTaskEnableWatchdog(hIecTask); //Watchdog enabled

The watchdog is deactivated before initialization with ‎IecTaskDisableWatchDog‎ for the rest of the cycle and is automatically reactivated at the next cycle.

The watchdog can be reactivated after initialization with ‎IecTaskEnableWatchDog‎. The watchdog is then already reactivated for the rest of the cycle (the watchdog time window starts again from the beginning).

Initializations of function blocks which happen within the ‎FB_Init‎ method are not affected by this. But there was the limit of < 30 seconds because of the communication timeout. This time limit no longer exists since V3.5 SP18 because the online services are executed asynchronously.

The normal watchdog of an IEC task is triggered when the execution time of the IEC task exceeds the watchdog time.

The "Omitted Cycle" watchdog is triggered when the task does not start at all. This is the case when the task does not execute any cycle at all within the maximum of <Time * Sensitivity> or <2 * Interval>. The cause could be crowding by other tasks or a failure in the scheduler, which no longer enables the task.