Continuous vs Periodic Tasks in PLC

[Dayvieboy]

Curios on the thoughts of using Continuous vs Periodic tasks.
. The old SLC-500's mostly only had Continuous tasks.
. The Compact & Control Logic have both.
.
The argument against continuous task seems to be that the scan time
. is a bit inconsistent because of other interrupts.
. But if you put it in a Periodic task,
. you are slowing the task down by default.

The SLC-500's usually run 100 % CPU @ all times.
. & they seemed to do a pretty good job

On a Compact Logix you can control the CPU usage
. but if you use a continuous task it goes also to 100% CPU usage

If you want the fastest possible action
. & a bit of jitter in execution time is acceptable
. then a continuous task could be a good solution

Jitter should be easily calculated
. based on any interrupts that you have & how they are set up

If you leave any available CPU scan time
. you have slowed down the process

Of the 9 pretty high level programmers on the project.
. One is adamantly against continuous tasks.
. The rest think it should be used.
. The local Rockwell rep says it should not be used
. I get various opinions when calling tech help

The new processors do run faster than the RPI time of I/O.
. & could trigger some asynchronous event.
. But this is taken care of with de-bounce.
. to eliminate asynchronous I/O triggers may arise

The continuous task is an option in the for a reason
. Or is it just a legacy

I could go on, but will stop here.


Always like the feedback here.

Thanks,

Dave

 

[JeremyM]

Nothing wrong with using the continuous task for process code.

The physical hardware is designed for 100% usage, 24/7.

Timed message handling can be (and is!) trickier when you have their calling code dispersed throughout periodic tasks with different periods and priorities.

Why settle for some fixed 10ms, 50ms, or any other response to IO than the fastest possible?

There are many times when you’d want code firing on a fixed interval: real-time clocks, utility code, and so on.

I’d say it depends on the application, so the words “always” and “never” aren’t really suitable in any of them.

 

[Corsair]

I do everything in continuous tasks unless there is a compelling reason not to. Calculations and value bounding that can be solved at a slower interval can be in timed tasks to save on CPU cycles but control logic probably shouldn't be there.

Mixing task execution intervals makes it much more important that you watch your one-shot bits. A bit that is on for a single scan cannot be guaranteed to be seen in another task. It seems that best practice is to use one-shots in the routine where they are generated in and nowhere else.

- - - - - -

If you need a timed pulse with the best possible long-term accuracy in the timing us non-Rockwell IEC types use a SAMPLETM function. It generates pulses while allowing for the timing skew from varying scan times. It's what you want to use when you need long-term accuracy for things like integrating an analog value. Much more accurate than using a TON where the output of the TON resets it on the next scan.

The PLC class outline at CorsairHMI.com talks about the old classic PLC programmer trick to get more accurate pulses. You used a TON timer where you did subtractions from the accumulate value rather than using a reset scan. It was a way to attempt a crude time of day clock before PLCs had time of day clocks. I'm glad we're over having to do things like that. The modern SAMPLETM function does a nice neat job of doing the same thing. I recommend studying doing things the old hard way so that you better understand the modern methods. Under the hood nothing has changed.

Remember with the Rockwell guys - those that can, do. Those that can't go into sales and sometimes tech support. I realize that I'm painting with a broad brush and there are some very notable exceptions - apologies to them.

 

[Jlandwerlen]

I think it depends on the size of the program. For small applications, let it rip, do it all in continuous. But for larger applications I typically do everything in periodic and have no continuous task. I've been able to get better scans that way.

I will say this question will garner a bunch of opinions.

 

[Ken Moore]

I think it depends on the size of the program. For small applications, let it rip, do it all in continuous. But for larger applications I typically do everything in periodic and have no continuous task. I've been able to get better scans that way.

I will say this question will garner a bunch of opinions.

What he said.

 

[Paullys50]

Remember with the Rockwell guys - those that can, do. Those that can't go into sales and sometimes tech support.

Wow, what a dumb comment.

If you need a timed pulse with the best possible long-term accuracy...

Use a periodic task.

A bit that is on for a single scan cannot be guaranteed to be seen in another task. It seems that best practice is to use one-shots in the routine where they are generated in and nowhere else.

Why would you even consider introducing this type of dependency across tasks?

OP -
SLCs, PLC5s, Micrologix all have the option to set a routine for STI, precursor to periodic tasks. Concept isn't anything new.

Using a continuous task requires you to manage the system overhead time slice for communication activities. Using a continuous tasks makes it harder to use the task monitor tool to identify logic that is chewing up CPU cycles because the CPU is always 100%. A continuous task is pointless if the logic is executing much faster than the RPI of the IO. There is only 1 available continuous task, if you want to break out any other tasks you will nee to use a periodic or event task.

PID loops and totalizers should always reside in a periodic task.

Heavy compute logic should reside in a periodic task.

You can probably guess that I don't use a continuous task.

 

[cardosocea]

The argument against continuous task seems to be that the scan time
. is a bit inconsistent because of other interrupts.
. But if you put it in a Periodic task,
. you are slowing the task down by default.

It's not so much slowing the scan time, but making better use of it.

Say the same PLC is controlling a kiln temperature at 800degC and a packing line. With a continuous task, you'll be calling the temperature control logic 10 or more times faster than actually required by the process. And at the same time, because the packing machine runs so fast and you have no way to give priority to a bit of code you'll likely end up calling the packing machine sub routine 2 or more times to artificially bump up the priority and frequency at which the code is run.

The SLC-500's usually run 100 % CPU @ all times.
. & they seemed to do a pretty good job

There's a fallacy in this... the program is designed to do a certain bit of work taking into account its capabilities. the SLC's didn't have periodic tasks so you can't quite say this is the best way forward.

If you want the fastest possible action
. & a bit of jitter in execution time is acceptable
. then a continuous task could be a good solution

This is wrong, the fastest you can get is really on properly set periodic task.

Jitter should be easily calculated
. based on any interrupts that you have & how they are set up

Jitter wouldn't really be down to interrupts, but the "logic tree" in the program. I see this in old S88 style programs in PLC5/SLC's where certain equipment modules (subroutines with plenty of rungs) are only called when needed and not all the time. In these situations your jitter isn't easy to calculate.

If you leave any available CPU scan time
. you have slowed down the process

Does heat transfer or product flow depend on CPU scan time? This is a wrong assumption. You can't just dump things in periodic tasks and be done with it. There's some thought behind whether something will change that quickly or not.

Of the 9 pretty high level programmers on the project.
. One is adamantly against continuous tasks.
. The rest think it should be used.
. The local Rockwell rep says it should not be used
. I get various opinions when calling tech help

The key question here is what is the project? For a lot (I'm going on a limb and say the majority) of projects it won't matter much.

The new processors do run faster than the RPI time of I/O.
. & could trigger some asynchronous event.
. But this is taken care of with de-bounce.
. to eliminate asynchronous I/O triggers may arise

Interesting you mention de-bounce... in micro controllers an easy way to minimise the effects of debounce is precisely to read inputs on a periodic "task".

 

[JesperMP]

My take:
Place the (few) program functions that really require a fast and/or a very specific period in one or more fast periodic task(s).
All the rest in a continuous task.

. The local Rockwell rep says it should not be used
. I get various opinions when calling tech help

That is like asking a saw manufacturer how to best build a house.

 

[chelton]

My take:
Place the (few) program functions that really require a fast and/or a very specific period in one or more fast periodic task(s).
All the rest in a continuous task.

+1

Continuous tasks are there for a reason. If you need deterministic place the required code in a periodic task. Continuous tasks would have the lowest priority of any task.

 

[Aardwizz]

One of the things I dislike about using multiple Periodic tasks is in the interplay between the logic in the tasks.

If you have some sequence logic (phases) in one task, and your device control logic in another, and you want to do so simple housekeeping where you would one-shot a bit to tell the devices to do something, that may work sometimes but not others, depending on just when the period scan interrupts hit.

This means that you have to create handshaking logic between task, as if they were in separate PLCs. Or use a lot of latch bits (phase sets, device resets; similar to interacting with an HMI). In complex programs, this can make things hard to troubleshoot.

In other CLX processors, lot of HMI communications could seriously bog down scan time, so switching to all-periodic helped. There was also a limit of 100 programs (phases) per task, so having multiple tasks (periodic) was necessary. The newer models (L80's) have a separate coprocessor dedicate to comms, so that is no longer an issue. Plus, the limit is now 1000 programs per task, allowing everything to fit in one Continuous Task again.

A hybrid (Continuous with Periodic) is best.

Certainly put things that need metronomic consistent scan times (PIDs, totalizers) in Periodic tasks. Keep the Periodic task small, so that its scan time is also consistent. You kinda defeat the purpose of having a periodic task if there's a lot of conditional logic in it that adds tens of milliseconds to the scan before your PID gets updated.

My £ 0.0149

 

[Toine]

I think there is no single best answer. In my book it mostly depends on the process at hand. For some processes you would want the fastest possible response time. Other processes are typically slow and have no use for lightning speed reaction times. To have that code run in a periodic task with relatively large cycle time is perfectly fine. If you mix and match tasks with different cycle times (and fixed time vs freewheeling) then you should have good reason to do so and thus are also responsible for consistent behavior, particularly when there is interdepencies between these tasks. Something to keep in mind in the design phase. If bugs pop up at a later time because your slower task are missing some events from faster tasks then you may find yourself scratching your head for a while. Perhaps even pull out some hair, if you have any left by then

 

[WebHandler]

Because of some teaching in my background, I grade PLC programs to determine levels of expertise. A program using continuous task is automatically deducted a full grade point. I feel this is the starting point for PLC programmers in "Introduction to PLC Programming 101." And, because it is so basic, it is the frame work used to implement all "NEW" CLX programs.

The continuous task is present in CLX processors to provide compatibility and simplify code conversion for older generation PLCs.

In older generation CLX processors, communications was allocated a percentage of processor time. It was up to the user to recognize when this percentage of time was insufficient. Like many issues in a PLC, the onset of scan, communication or processor usage issues are very subtle and difficult to isolate.

I typically develop all my programs starting with a single task set at 10ms or 20ms. HMI support is handled in a task operating at 100ms to 200ms. High speed (critical) I/O is handled in dedicated task with appropriate update rates. Scan time will be refined as the program is developed. I try to minimize the number of task because of the need for hand shacking, latch/unlatch and or semaphore/mutex type code to handle communications between task.

In the early days of microprocessors, I was told not to worry about optimizing the speed of code as it is developed but to develop the code and go back and optimize the code after you know where it speeds most of its time. I use this same philosophy when writing PLC code.

 

[Steve Bailey]

Because of some teaching in my background, I grade PLC programs to determine levels of expertise. A program using continuous task is automatically deducted a full grade point.

Statements like that are one reason the teaching profession has lost respect.

 

[JeremyM]

Statements like that are one reason the teaching profession has lost respect.

Yup. Nothing like a punitive measure against what is otherwise a meaningless difference, at the academic level. If, instead of that, the student were challenged to learn the difference and what its trade-offs are, we might stem the seemingly endless tide of cavalier, degreed engineers in the field treating meaningful differences as “only academic.”

 

[Peter Nachtwey]

This has been entertaining. Personally, I know both periodic and continuous task have their place.
Periodic tasks are for determinism. Continuous tasks are for back ground things.
I think a more important question has fallen through the cracks. When is the I/O done?
A periodic task should have all the inputs it needs updated at the beginning of the task and its outputs done at the end. When are continuous task I/O updated? Sometimes there isn't much point in using input data that is 20 milliseconds old.

Also, back ground tasks are good for long computations that may take several scans to complete. A common example is sorting. A bit can be set or cleared to indicate when the sorting is done and the data is now sorted.