RSLogix5k continuous periodical task deciding

[unsaint32]

I've heard someone saying I should put as many programs/routines in the continuous task. I also heard others saying use as little continuous task as possible because it burdens the CPU.

What guideline do you PLC programmers use when deciding what progrms/routines to be under periodical tasks?

Thanks.

 

[Geoff White]

The continuous task executes at the lowest priority. The more stuff you put in there the slower it will cycle. It is pretty futile trying to take stuff out of the continuous task to speed it up as it will still slow the scan rate down and make the timing erratic. The only time i try to do this sort of thing is for really slow stuff like logging jobs that run once a second. Also the more tasks/etc the more overhead the system will have managing them.

If your cycle time starts getting long put time critical stuff in periodic/triggered tasks.

 

[RET]

If you read some of the recommendations for PID control, it recommends that PID instructions be used in a periodic task, seemingly because the timing is a bit more accurate than using a simple timer (how much more accurate is probably negligible for most uses). So, the only reason I use periodic tasks is for PIDs, but that's probably not even necessary.

The only thing you need to worry about regarding a "burden" on the CPU, is scan time, and memory. The CPU isn't going to wear out of heat up any faster with all your code in the continuous task.

 

[daba]

If you read some of the recommendations for PID control, it recommends that PID instructions be used in a periodic task, seemingly because the timing is a bit more accurate than using a simple timer (how much more accurate is probably negligible for most uses). So, the only reason I use periodic tasks is for PIDs, but that's probably not even necessary.

The only thing you need to worry about regarding a "burden" on the CPU, is scan time, and memory. The CPU isn't going to wear out of heat up any faster with all your code in the continuous task.

Because periodic tasks are triggered by the PLCs operating system, they have less "overhead" than using cyclic timers in the continuous task.

Using periodic task(s) for anything that you want to happen on a time-triggered event, is the way to go. You don't need a timer, saving on memory usage, and you don't need the rung that makes it cycle, saving on memory usage AND execution time.

PIDs in the continuous task will, in general, work adequately, but I see absolutely no harm in putting them where they will get the most benefit in terms of timing accuracy - that is in a periodic task. Once configured in a periodic task, it makes the application "future-proof". You can add tons more code into the continuous task (which would affect the accuracy/repeatability of a timer's .DN bit), without affecting any PID control you spent hours tuning to perfection.

I have seen applications where the continuous task execution time varies considerably, performing things like on-demand FAL instructions, or iterative loops, nested FOR instructions etc. Each of these would delay the timer.DN bit being "seen" to execute a PID, thus throwing the instruction's internal calculations wrong.

IMHO PIDs belong in a periodic task....

 

[RET]

Because periodic tasks are triggered by the PLCs operating system, they have less "overhead" than using cyclic timers in the continuous task.

Using periodic task(s) for anything that you want to happen on a time-triggered event, is the way to go. You don't need a timer, saving on memory usage, and you don't need the rung that makes it cycle, saving on memory usage AND execution time.

PIDs in the continuous task will, in general, work adequately, but I see absolutely no harm in putting them where they will get the most benefit in terms of timing accuracy - that is in a periodic task. Once configured in a periodic task, it makes the application "future-proof". You can add tons more code into the continuous task (which would affect the accuracy/repeatability of a timer's .DN bit), without affecting any PID control you spent hours tuning to perfection.

I have seen applications where the continuous task execution time varies considerably, performing things like on-demand FAL instructions, or iterative loops, nested FOR instructions etc. Each of these would delay the timer.DN bit being "seen" to execute a PID, thus throwing the instruction's internal calculations wrong.

IMHO PIDs belong in a periodic task....

Good to know...thanks.

 

[proof]

If you look at the AB PAC recommended guidelines for programming, its first recommendation is to delete the continuous task and run everything in periodic tasks, with the varying time periods based on the needs of the logic.

 

[daba]

If you look at the AB PAC recommended guidelines for programming, its first recommendation is to delete the continuous task and run everything in periodic tasks, with the varying time periods based on the needs of the logic.

I've seen that recommendation, but don't go along with it ....

It is a huge waste of resource, because inevitably there will be chunks of time that the processor will be doing "nothing" for your application, except waiting for task triggers.

Better to use that wasted time in executing logic that doesn't need scheduling... IMHO

 

[proof]

I've seen that recommendation, but don't go along with it ....

It is a huge waste of resource, because inevitably there will be chunks of time that the processor will be doing "nothing" for your application, except waiting for task triggers.

Better to use that wasted time in executing logic that doesn't need scheduling... IMHO

This is incorrect. Without a continuous task, when a periodic tasks aren't running the processor is doing "nothing", it is servicing communications.

 

[GTUnit]

The only time we put ANYTHING in the periodic task is when the timing is absolutely critical/sensitive.
Reading encoders, PID, Ethernet/ ASI/ Profibus Comms, ect.
We understand Periodic tasks as areas designated for precision.
Everything else that doesn't need precision goes in the general task.

 

[phuz]

I also heard others saying use as little continuous task as possible because it burdens the CPU.

Revoke their programming license.

 

[AustralIan]

If you don't care about timing that much, and just want the PLC to do it as fast as it can, then the continuous task is fine.

If you want something to occur at a specific rate, use a periodic task.

If you need it to occur at a minimum rate, then schedule all of your tasks and note the %cpu usage. Alarm if any tasks overrun.

 

[AustralIan]

I also heard others saying use as little continuous task as possible because it burdens the CPU.
Thanks.

The less useless junk you put in your continuous task, the faster it runs.

Revoke their programming license.

Or they can go on a state funded programmer awareness course.

 

[Paullys50]

If you don't care about timing that much, and just want the PLC to do it as fast as it can, then the continuous task is fine.

That depends...

If your application is small, sure dump it into the continuous task and move along. However larger projects w/complex logic tasks, well you can watch your scan time go through the roof. At the end of the day, you can only have 1 continuous task. Might as well get in the habit of understanding and using periodic tasks in case you ever need to use more.

I've worked on large process systems where continuous scan time was greatly impacted and necessitated moving to periodic tasks. Or we hit limitations (newer firmware this isn't an issue) where you can only have 100 programs in any given task. Hit that limit and you have to add a periodic tasks just to get more programs. So it's a valid discussion and simply stating the continuous task is the way to go, well not always.

 

[daba]

This is incorrect. Without a continuous task, when a periodic tasks aren't running the processor is doing "nothing", it is servicing communications.

If it's not running any of the code I put in, and it is "servicing communications" again when "servicing communications" has just finished.... pointless !!.

Remember that "servicing communications" is a scheduled hidden task that interrupts ALL tasks.

The SOTS handles communications effortlessly, there's no need to compromise application execution by giving it excessive resources...

 

[daba]

I've worked on large process systems where continuous scan time was greatly impacted and necessitated moving to periodic tasks. Or we hit limitations (newer firmware this isn't an issue) where you can only have 100 programs in any given task. Hit that limit and you have to add a periodic tasks just to get more programs. So it's a valid discussion and simply stating the continuous task is the way to go, well not always.

So you identified code that could be run at a lower rate, and moved it to a periodic task, well done, that's how you should think.

You can do this by creating a new EVENT task (another 100 programs), and triggering it with an EVENT instruction. There's no need to lock it to a periodic execution rate that is asynchronous to your other continuous task programs.