Moscow, Azovskaya 14
+7 (495) 310-97-15
Mo-Fr: 9.00 - 18.00 (Moscow time)
Order a call
Your name *
Enter phone *
Your Email *
Call me back
Codesys Multitasking

Task Manager Codesys 3.5

This article is devoted to explaining the operation of a cyclic program call in the Codesys 2.3 and Codesys 3.5 programming environments. Let's pay attention to the difference in the implementation of program management on these platforms, consider the principle of the task manager, determine the types of tasks implemented in these programs, and dwell on the "watchdog" function.
In any version of Codesys, there may be situations when one task may coincide with another in terms of execution time. In this case, it is necessary to set the priority, which of the tasks is more important. One can give such an example. You have planned tasks for the year ahead. One of these tasks is to go to a friend's birthday party. And you also have a daily task - every day to go to the store. If you give priority to the store, you may not get to the birthday, although you have been waiting for this event for a whole year.

Мы забыли про важный момент 

Single-core processors use a task manager, which is a tool for solving multitasking issues by dividing tasks in progress by time and priority. Usually, we process inputs/outputs more often, and application tasks and visualization less often. Thus, we build a run cycle for different tasks. So, for example, there is a program for reading inputs, which is processed with a resolution of 10 milliseconds, there is a program with a control algorithm. These programs are processed sequentially. If the input processing time has expired, then we proceed to the processing of the application program. If the time has not yet expired, then, bypassing the processing of the application program, we turn to the block for writing to the outputs. And so in a circle. It seems that everything is quite simple and understandable, but this is as long as there are only two such tasks. When there are more such tasks, when they are busy with serious calculations, then the role of the task manager in executing programs at different intervals increases significantly. We are faced with the need to divide the process of processing programs according to priorities.

Блок схема задачи 

Periodic distinctions are necessary for a more correct use of the processing power of the CPU (central processing unit of the controller). It makes no sense to make the same program calls that can be made less often. And you need to be well aware that a program using a video processor takes more time than, for example, processing some formulas or logic. The drawing process itself is quite a resource-intensive process and it is not necessary to update the picture more often than it is necessary to implement the main functions.
Let's define the main differences between programming environments.
Priorities in Codesys 2.3 are specified in dimensions from 0 to 15, in Codesys 3.5 they are already in the range from 0 to 31. All these priorities are related to the distribution of processor time. The lower the priority number, the higher the priority and the more CPU time will be allocated for the execution of the associated program..
The type of multitasking in Codesys 2.3 is called "substituting" when one task replaces another. The task manager in this version implements the specified priority logic. The highest priority will be executed.
In Codesys 3.5, the principle of multitasking is "preemptive". If there are two tasks that must be executed at the same time, the program will implement sequential execution, one task after the other. The higher priority task will get the right to be executed first, but the lower priority task will also be executed next. If tasks with the same priority are called, the one that waits longer will be executed so that there is no such situation that one task is not executed at all.
Let's consider this difference in the following example. Let's create two simple programs on Codesys 2.3 and Codesys 3.5 within one project. We will make one program with an execution cycle of 10 milliseconds, and we will make another program specifically with an error - with an infinite loop. Let's add two tasks in the task manager, dividing them by priorities, we make the second task (with an infinite loop) with a lower priority. In each program section, add a counter.
What happens when their execution times match? What will happen to our controller and how will it behave? After starting Codesys 2.3, if the “watchdog” function was not enabled, we will see the controller stop, as it stopped on one of the tasks and could not exit it. It got busy processing a single process and stopped responding. This is due to the code execution architecture in the Codesys 2.3 environment.
Так будет в Codesys 2.3


At the same time, in Codesys 3.5, the counter values will continue to change, the program will not stop. Despite the fact that the program does not have its end, it is still updated and has time to be processed.

Так будет в Codesys 3.5 

Thus, the essential difference between Codesys 2.3 and Codesys 3.5 is the difference in prioritization. If priorities in Codesys 2.3 are determined by precedence and the priority “highest over lowest” is clearly observed, then in Codesys 3.5 the resource of processor time is redistributed. Allocating it to a particular priority is a feature of preemptive multitasking.
It should be noted that in the case of "preemptive" multitasking, we are always talking about a processor with one core. Where there are many cores, the processes are somewhat more complicated, and we will not talk about this in this article.

Let's take a closer look at the types of Codesys tasks.

Типы задач 

• Type of tasks "Cyclic".
When the time comes, the program starts its execution. It is executed for as long as the program itself requires, then the program stops, waits for the next timer to run, and is executed again. When using several cyclic tasks, you should try to set different times for them in order to reduce the number of possible collisions, and set different priorities for everyone.
• Task type "Event"
The task manager keeps track of the associated variable of type "BOOL", and when the variable changes its value from "FALSE" to "TRUE", then the associated program is called once, 1 cycle long. For example, in this way it is possible to fix the short circuit of the sensor, send a diagnostic message about the event to the SCADA system. For this type of tasks, it is desirable to set the highest priority, so that it is guaranteed to be allowed to execute cyclic or free tasks.
• Task type "Free"
From the first cycle of the controller, the associated program is polled, after the end of this program, it is executed the next time without delay, it just starts right away. It has no time limits, it is called according to the frequency of its execution, that is, this frequency may vary depending on the processor load, on the volume of logical calculations of this program. Accordingly, if we perform these types of tasks, then it is better to put them lower in priority than other types of tasks, otherwise the latter simply will not be completed.
• Task type "Status"
The task will be executed, like a Free one, with the minimum possible polling cycle, while the variable of type "BOOL" associated with it will be in the "TRUE" state. You should reduce the priority of this task, since it, and as a free one, operates without delays in execution and can “overwrite” any of the tasks.
The controller has its own separate cycles (cycles), which are not tied either to reading inputs or to executing programs. These are operating system cycles.
A little more about the "Watchdog" function.
The task manager has a feature for tracking freezes - "Watchdog". This function is designed to stop the execution of the program when the execution time is exceeded. So, if any of the programs runs longer than the time allotted to it, then when the Watchdog is triggered, the controller or task will not freeze. It becomes possible to correct programs or reboot the controller.
For the correct operation of the "Watchdog" timer function, there is a "sensitivity" parameter. This parameter determines how many times the time can be exceeded before the Watchdog is triggered. So, for example, if "Watchdog" is triggered in Codesys 2.3, then it will automatically reboot the PLC. This is done so that if an error occurs in the code, to exclude or reduce the impact of a hung PLC on the process, there is a certain chance to return everything to normal, or at least return all controller outputs to a safe state. If one of the tasks in Codesys 3.5 freezes, this will not lead to a process hang or a PLC reboot, respectively, the controller will continue to work, the program will generate diagnostic information about the task being excluded from processing.
In Codesys 3.5 we have diagnostics and can see the current state of the execution of tasks. Task manager diagnostics (monitoring):

 Task manager

"Status" - shows the current execution status, if "Not created" - the task has not been launched since the last update, "Created" - the task is recognized in the execution system, but not in operation, "Valid" - the task is working normally, "Exception" - The task has been taken out of processing. There is also "Active", which means that this task has problems.
"Counter" - has two fields, IEC and general. Associated with block call types. Common is usually more.
"Last. (µs)" - The time of the last measured cycle in microseconds, must constantly change.
"Average cycle time (µs)" - the total average time of all cycles for this task in microseconds.
"Max. cycle time (µs)” – maximum measured cycle time [µs]. This time may be longer than the specified time if the program does not have time to work out.
"Min cycle time (µs)" – minimum measured cycle time [µs].

"Jitter (µs)" is the last measured jitter [µs]. Jitter is the difference between the time a task should start and the time the task actually starts. For example, if a task should run every 1000 µs, but in fact it did not have time and is forced to start after 1100 µs, then the jitter is 100 µs. The task call time can shift with each call. This is the difference between when a task should have started running and when it actually started running. Jitter, in fact, is essentially a numerical quantitative parameter that measures the magnitude of this shift. The smaller it is, the better the PLC tuning is done.

I would be grateful if you correct me in the comments if there is an inaccuracy in the article.

#Codesys, #Codesys2.3, #Codesys3.5, # multitasking, #task manager, #jitter, #cycle, #processing

Be the first to comment

You comment add