Logix5000 Continuous vs. Periodic Tasks

Hello,

Monitoring my system with the Studio5000 Task Monitor I see a yellow banner "Continuous Task is present, resulting in 100% CPU utilisation"

I have one Main Task - continuous, and a Safety Task - Periodic (20ms).

Looking at the attached (snaps from "Logix 5000 Controllers Tasks, Programs, and Routines"), my task fits the examples of the continuous tasks, but given the PC analogy running CPU@100% isn't best.

Would you recommend converting the Main Task to Periodic @10ms (max scan rate in Continuous is 9.5ms)?

Thanks.

I'm not the expert here, but the continuous task will always take up the whole CPU. Most PLC's are used in this way and you can set how much the Operating System takes from the 100% you see for tasks like communication and such.

You can put all your program in Periodic tasks and that is usually the strategy to increase the capacity of a PLC in Distributed Control Systems (which for Rockwell is PlantPAX). They actually state in the PlantPAX instructions to delete the continuous task.

The handful of Logix5000 programs I have written from scratch have been done without using a continuous task. I am not sure I would try to set the period so short that you run the risk of overlap. In other words, I wouldn't set it to 10ms just because it has been taking 9.5ms. If you system can really perform better with the PAC running as fast as it can, just leave it as continuous.

Rockwell will tell you to avoid Continuous Task, (not "Good Practice").

For most situations, Periodic or Event is recommended.

celichi said:

Rockwell will tell you to avoid Continuous Task, (not "Good Practice").

Click to expand...

Can you point me to where RA states this? I have heard the same, but haven't seen this written anywhere.

Phrog30 said:

Can you point me to where RA states this? I have heard the same, but haven't seen this written anywhere.

Click to expand...

I have not seen this written anywhere, only been told on Tech Support Calls, and RS Tech Ed and Automation fair discussions.

I think their official stance would be this is programmers choice, but be mindful of overhead requirements, as well as skipping other tasks if the processor scan runs long.

I have had OEM support reps tell me the same thing, avoid continuous if you can, schedule everything.

celichi said:

I have not seen this written anywhere, only been told on Tech Support Calls, and RS Tech Ed and Automation fair discussions.

I think their official stance would be this is programmers choice, but be mindful of overhead requirements, as well as skipping other tasks if the processor scan runs long.

I have had OEM support reps tell me the same thing, avoid continuous if you can, schedule everything.

Click to expand...

Thanks, was hoping for a white paper or something. We don't use continuous either.

Scheduling is deterministic. So, if you have code that "works" in a scheduled task, you can be pretty sure it will work in the future. With a continuous task, the code might "work" and then maybe you add some code to it, and the task takes just a little longer to complete.. or you might have conditional logic, and when you tested it in commissioning you only tested one bit of code at a time, so not all of the conditions were acting at once. Now the task cycle time has doubled because all 6 plant areas are working at once, and your missing proximity sensors or something.
Or you have code that works fine at the 10ish ms of the continuous task in an L32E. You then port the application to an CPLX5480, and it runs 100times faster... Maybe this won't work nicely.

Sure, if you overload your cyclic task it will not be happy too, but at least it will give a watchdog (hopefully watchdog warning too) so you can say "ah, I can't run as fast as I need to."

That said, if it "works" in a continuous task already, go fix something that doesn't.

Phrog30 said:

Thanks, was hoping for a white paper or something. We don't use continuous either.

Click to expand...

In the same boat here. In my previous life I've heard that continuous aren't recommended by the TechConnect, but now looking for a KB to support that.

The problem that I have with Timed tasks is when something that you want to have as a one-shot (say, to reset all states at the end of an action) needs to affect something in another task.

Sometimes the scanning/interrupts align, and the receiving task sees the bit being high; other times they do not. So you wind up having to treat task-to-task communication as if they're in different PLCs, with handshaking between every signal where timing could conceivably be an issue.

With single Continuous task, you have classic PLC scanning, and don't have to have that overhead.

alexbeatle said:

Hello,

Monitoring my system with the Studio5000 Task Monitor I see a yellow banner "Continuous Task is present, resulting in 100% CPU utilisation"

I have one Main Task - continuous, and a Safety Task - Periodic (20ms).

Looking at the attached (snaps from "Logix 5000 Controllers Tasks, Programs, and Routines"), my task fits the examples of the continuous tasks, but given the PC analogy running CPU@100% isn't best.

Would you recommend converting the Main Task to Periodic @10ms (max scan rate in Continuous is 9.5ms)?

Thanks.

Click to expand...

I have been advised to convert to periodic and event as well.

I have no reason to think that anything will run poorly as periodic. But I will have to monitor the CPU usage instead of the scan time. Just another place to look

As for timing, I have restrictions on IO update based on old Controlnet. So in an example PLC program, my IO updates at 100 ms and 750 ms (no typo, we update that slowly on our motor amps). So I think I would schedule the former main task at 80 ms to ensure that I caught every I/O change. The scan time is presently 45 ms with peaks into about 71 ms with alarming. IMHO it's just a different way of thinking. How fast do I NEED it to run, not how fast WILL it run. I agree with others that time-dependent code that runs in the lab at an 80 ms schedule will still work in the field at 80 ms.

For your example, if your IO is DC and there are no fast pulses that you need to track, my opinion is that you can schedule 20 ms for your former continuous task, or perhaps slower. It depends on the fastest input you need to execute code on, or whatever other timing dependencies you may have.

I still use continuous task for the meat of the program. My theory is that I want the program to run as fast as it can. Sure, everything would work well at enough at 100ms or so, but if I want to shut down a process because of an E-stop, why should I wait 100ms before doing anything about it?

Yes, my 1ms scan continuous scan could drift to 1.2ms after a few years of added code, but it will still work better than if I arbitrarily slow it to 10ms or so.

rupej said:

but if I want to shut down a process because of an E-stop, why should I wait 100ms before doing anything about it?

Click to expand...

There's a few bits in this sentence that are somewhat off...

First the e-stop's job is to bypass the PLC... a process stop, not necessarily, although it's always best to have them separate from most of the control logic too.

With the periodic task you can guarantee that the input for said e-stop will be read every 10ms or something like that. You can't guarantee that on a continuous task.

I have only seen Rockwell officially instructing to delete the continuous task in their PlantPAX documentation.

Other brands, like Siemens PCS7, tell you to do everything in periodic tasks and if you have some diagnostic functions that are just to pull information leave them in the continuous task and it will be done as time becomes available (continuous task should be the lowest priority).

cardosocea said:

First the e-stop's job is to bypass the PLC... a process stop, not necessarily, although it's always best to have them separate from most of the control logic too.

Click to expand...

Not necessarilly if the PLC in question is a safety controller. But an E-stop was just an example, the same concept holds true for position switches, alarms, etc.

rupej said:

Not necessarilly if the PLC in question is a safety controller. But an E-stop was just an example, the same concept holds true for position switches, alarms, etc.

Click to expand...

Well if something is critical you wouldn't put the code in a 100ms periodic. You have to have a little common sense on this. Maybe for you then continuous is the way to go.