Hi,

is there something wrong if instead of several tasks I use only one, with a call to one MAIN program in it, which program calls all the rest? Like the code below?
Say I want to execute several PRG's each 10ms, some each 100ms, some each 200ms - normally I should define 3 cyclic tasks.
Instead, I define only one freewheeling task, which calls high priority PRG's on every cycle, less important PRG's every 10-th cycle, and least important every 20-th. Will this squeeze some more performance from the PLC? I mean, switching between tasks probably takes time and affects performance (have no idea to what extent), so having only one task should be better. If it's freewheeling, it executes again right after it has finished, so at the max. possible rate.
So far, all looks OK. Now, what I missed ? What are the disadvantages of this concept?

Thanks

Zitat:
PROGRAM MAIN
VAR
i: BYTE;
END_VAR

high_priority_prog1();
high_priority_prog2();
high_priority_progN();
i := i + 1;
CASE i OF
10:
lower_priority_prog1(); (execute this each 10-th cycle)
20:
lower_priority_prog1();
lowest_priority_prog(); (execute this each 20-th cycle)
i := 0;
END_CASE;

I don't know about the performance.
The only thing I come to think of is that you don't have the ability to set individual watchdogs.

Hi,
it should work that way. On the other hand - nowadays microprocessors are pretty fast. So I would not expect a significant loss of performance, when splitting the program into separate tasks.
Rolf

thanks for the replies.
Now I have two cyclic tasks (no watchdogs), a main fast one for automatic mode and a slow one that mainly deals with the touch panel and with rarely performed operations like configuration.
When building the project, I have 20 or so warnings 1851 that a variable used in task SLOW is updated in another task, and when I do a project check - lots of errors 4622 about concurrent access to I/O & variables from both tasks. Can any of these be a real problem? These are variables for which this is not a problem.
But a couple of days ago I read something that concerned me. I can't find it now and don't remember it exactly, but the meaning was that all the tasks share the same process image and under given circumstances concurrent access may corrupt it.
And, something strange happened to me lately- an SFC program from the SLOW task hanged at a step, although the transition below it was TRUE
Transition was a physical input, an N.O. button that was ON physically (I measured 24 VDC) and displayed as TRUE by Codesys - and still, the SFC program didn't pass through it. This SFC PRG didn't have declared SFC flags so it wasn't paused/init/reset, absolutely no reason for such behavior. My conclusion was there was either some memory corruption, or the SLOW task became unresponsive.

I prefer to manage priorities myself from a single task, because it is not absolutely clear for me how they are managed by Codesys. I.e, if I have a high prio cyclic task which execution takes longer than the specified cycle time, what happens? Can this make a lower prio cyclic task unresponsive, or put the PLC into some messy undefined internal state?

Another question - is there any difference between one freewheeling task calling only one program_MAIN, and renaming program_MAIN to PLC_PRG, without defined tasks ?

Hi,
the behaviour of the compiler (warnings / errors) seems to depend on the PLC platform.

Zitat:
a variable used in task SLOW is updated in another task
No reason to worry. There MUST be a way to share information between all tasks. I normally have a number of VAR_GLOBAL for that.
It is important to have ONE information source only, but it does not matter, how often and in what task the information is read.
The systems I am working with, do not grumble, when doing it by VAR_GLOBALs. Don't know, what happens, if the information interchange variables are located in the declaration part of a PROGRAM.

Zitat:
concurrent access to I/O & variables from both tasks
Could be a bad thing for outputs (in single task systems as well). It could happen, that a PROGRAM turns an output on, but another one (in the same or in an other task) switches it off. The result would be a random, except you make sure, only one of the output sources is running at a given moment exclusively.>Zitat:
all the tasks share the same process image and under given circumstances concurrent access may corrupt it
could mean this.
Multiple read of inputs, even in different tasks, is not a problem.

Zitat:
if I have a high prio cyclic task which execution takes longer than the specified cycle time, what happens?
Could cause tasks with lower priority to hang. Normally a task watchdog should alarm (if activated).

Regards

pnn hat geschrieben:
Now, what I missed ? What are the disadvantages of this concept?

I see few disadvantages in using only one task:

1) I assume that high priority PRGs have hard realtime requirements and low priority ones do not. During the cycles when low priority PRGs are called the overall duration of one freewheeling task might take considerably longer than expected. I.e. the original high priority task was run with 10ms intervals, but this might be affected if duration of all PRGs is higher. I usually put disk operations etc to low priority tasks, which from the processors point of view is as slow as waiting for sun to cool off.

2) Do you have ramp functions etc which assume that every cycle are equally long? Freewheeling causes differiation between cycle durations, especially during those cycles when low priority PRGs are called.

PS. How about calling lower_priority_prog1() with cycles 5 and 15? And lowest_priority_prog() during cycle count 20.

Thanks for the reply Jay.

What do you mean by 'ramp functions etc which assume that every cycle are equally long', which functions assume this?
As I understand it, even with a cyclic task cycles are not equally long, only the interval between subsequent calls is.

And when talking about this, what happens in the following case: cyclic task, no watchdog, task interval set to 10ms, task execution takes more than 10ms - will the PLC stop with an error, or enter into some undefined internal state, or somehow auto-adjust and simply execute the task less frequently?

OK, let's ask this in a different way.
I have a project with about 40 programs, about 30 of them used in automatic mode (and so should execute fast) and about 10 used for configuration or manual/step-by-step-mode (for these I don't care about speed at all).
Most of the programs are SFC, and have a start flag (the first transition below the Init step). Programs for auto-mode and other programs do not work in parallel, if the PLC is auto-mode then configuration/step-by-step is not possible.

Having the above in mind, how to configure tasks to achieve max. performance in auto-mode?
Variant 1: have a single freewheeling task that calls all the programs. If in auto-mode, the PLC has to evaluate each cycle about 10 BOOL vars (start flags for non-auto mode programs), see they are FALSE, and don't do anything further with them.
Variant2: have 2 tasks, one fast task for programs used in auto mode, and another slow task for the rest. When the fast task is executed, it should not waste time to evaluate the start flags for non-auto programs. But the PLC has to switch between 2 tasks.
Which is better?

Why do you start low priority tasks in the first place, do this when you ask for it or the display for example.
disadvantage of your way is this image. When you change anything and ask it inside a program you see correct results b ut you do not see the image running but the real input and the image can be different.
Event driven programs (with interupts) are the fastest possible.
as they only do the tasks asked for.
You are doing a sort of polling but when something asks for more time you will get into problems.
example when you have a loop in a program the sequence will be stopped. as the control is not given back to the main until the SFC is cleared.

No there is no difference in using PLC_PRG or a selfnamed program the code is same, but this is done for compatibilty with other programs.
multiple reads is no problem but multiple writes to outputs is a problem same for Markers and timers etc.