Logix5000 Continuous vs. Periodic Tasks

daba said:

I too would like to see any links to the mentioned RA "recommendations"

Click to expand...

Having heard the same "don't use the continuous task" directive, I spent some time looking for a written Rockwell reference. Based on a review of the links below, as well as numerous message-board posts, the closest I could find is in the 2007 version of the Logix5000 Controllers Design Considerations Reference Manual (Publication 1756-RM094C-EN-P - June 2007), under the "Configure a Period Task" heading:

"If your application has a lot of communication (such as message instructions or RSLinx communication), use a periodic task rather than a continuous task. This avoids the overhead associated with task switching, which can improve performance."

Click to expand...

This statement has been removed from the 2019 version (Rockwell Automation Publication 1756-RM094J-EN-P - September 2019), nor does it appear in other, newer publications.

I will just say that my opinion on this is that not using the continuous task, as a matter of policy, leaves significant system-provided functionality unused. For reasons mentioned earlier (e.g., interprocess communication), I limit my use of periodic and event tasks to instances where their benefits are necessary and/or justified.

Refs:

Logix 5000 Controllers Tasks, Programs, and Routines

ControlLogix System

Logix 5000 Controllers Design Considerations

Using Event Tasks with Logix5000ô Controllers

Technotes (access Everyone unless noted):

RSLogix 5000: Differences Between Continuous, Periodic, and Event Tasks

Periodic Tasking with ControlLogix (Tech Connect)

RSLogix 5000 Tasks, Programs & Routines

Logix Platform : Task Priority Levels within Logix Processors

Configuring the System Overhead Time Slice

RSLogix 5000: How to avoid Task Overlaps (Tech Connect)

When a timed task is enabled my ControlLogix processors program scan time increases to an unacceptable level (Tech Connect)

If you have capacity left over, and the processor isn't doing anything...why is that a worry?
.
I'll tell you this, I wish you NeverPeriodics much luck, if you EVER have a communication problem. The processor will appear to slow down, and, you will have no luck at all going on line using the USB or ethernet ports, because the processor will be so overwhealmed by communications that it will have nothing left for program access. This actually happened to me...an external actor was requesting too much information, too often, and the poor processor was doing its best. Once I switched "MAIN" to a Periodic Task, I could use the Task Monitor Tool to find out what was taking all the time/energy/processing power.
So, keep on using your ContTasks, go ahead, and you can stand on your "Rockwell doesn't say I cant" horse, until you fall off.
Geez, I'll never understand why people are so fixed in the past, and rush to support and defend something that is so old fashioned. And, BTW, I've been at this since the early 80's, FYI.

jdbrandt said:

Geez, I'll never understand why people are so fixed in the past, and rush to support and defend something that is so old fashioned.

Click to expand...

Well said...

I'm open to whatever the CURRENT best practice is. Rockwell sure doesn't communicate that very well at all one way or the the other and after reading this thread I'm no closer to reaching a conclusion.

jdbrandt said:

This actually happened to me...an external actor was requesting too much information, too often, and the poor processor was doing its best. Once I switched "MAIN" to a Periodic Task, I could use the Task Monitor Tool to find out what was taking all the time/energy/processing power.
So, keep on using your ContTasks, go ahead, and you can stand on your "Rockwell doesn't say I cant" horse, until you fall off.

Click to expand...

But think about it- if by switching to perodic was able to free up system time for comms by scanning the task less often, couldn't the same thing could have been accomplished by increasing the system overhead time slice? Anyways, the latest generation of processors has a dedicated core for comms, so program scan has no effect on comms. They even removed the SOTS out of the menu for since it has no function. That may be why Rockwell removed the note about switching to perodic tasks as Mispeld found.

I don't think anyone is arguing for continuous task just because it came around first. Also, most of us are trying to have a constructive discussion- not sure why some of you are getting so emotional about this.

harryting said:

I'm open to whatever the CURRENT best practice is. Rockwell sure doesn't communicate that very well at all one way or the the other and after reading this thread I'm no closer to reaching a conclusion.

Click to expand...

Looking back on the older generation of PLC (SLC, PLC5, Micro etc), you had no flexibility, everything was one scan.

The Logix Platform gives you the flexibility to control your scans.

There is nothing wrong with continuous, I think Rockwell has said in the past, don't throw everything and the kitchen sink into one main continuous program.

rupej said:

But think about it- if by switching to perodic was able to free up system time for comms by scanning the task less often, couldn't the same thing could have been accomplished by increasing the system overhead time slice? Anyways, the latest generation of processors has a dedicated core for comms, so program scan has no effect on comms. They even removed the SOTS out of the menu for since it has no function. That may be why Rockwell removed the note about switching to perodic tasks as Mispeld found.

I don't think anyone is arguing for continuous task just because it came around first. Also, most of us are trying to have a constructive discussion- not sure why some of you are getting so emotional about this.

Click to expand...

Agreed. I am equally confused - my only theory is that "our world" is generally pretty predictable (really - it is), and this Cont/Periodic thing is something that is certainly debatable. And, depending on your evaluation criteria, you can make either side of the argument.
One thing I hear all the time is "..once its all running, nobody can see it, so why does it matter...", which, at some level, also has merit. But, the "half-empty" types will say: "Sure, same with wiring design. BUT what about when you have to modify the system, or what about when something DOES go wrong...wouldn't you like it if the original designers took the extra time to organize, document, implement everything according to the recommendations of the people who actually built it all?"

jdbrandt said:

wouldn't you like it if the original designers took the extra time to organize, document, implement everything according to the recommendations of the people who actually built it all?"

Click to expand...

Yes, if only those people (Rockwell) would make a clear recommendation.

harryting said:

I'm open to whatever the CURRENT best practice is. Rockwell sure doesn't communicate that very well at all one way or the the other and after reading this thread I'm no closer to reaching a conclusion.

Click to expand...

I went through the thread real quick so excuse me if someone already said this. I never use continuous tasks because when I go to upgrade a PLC I don't have to worry about something being programmed to the continuous time.

So, if you used an old school high speed counter and figured out a volume/flow whatever. You go to a new PLC that is way faster and now your volume/flow math might be wrong. Or if you are communicating over RS232 now you need to retime it.

Why create more work for when the PLC will need to be upgraded.

VAN said:

So, if you used an old school high speed counter and figured out a volume/flow whatever. You go to a new PLC that is way faster and now your volume/flow math might be wrong. Or if you are communicating over RS232 now you need to retime it.

Why create more work for when the PLC will need to be upgraded.

Click to expand...

Should someone have this problem in a Siemens CPU, they were kind enough to add a busy-wait loop function you can call.



Had to use it when swapping a 317 by the 319 and the cycle time went from something like 25ms to 3ms.

The biggest concern with using multiple periodic tasks, with perhaps no continuous tasks, is the priority of those tasks.

Sure, you will give the highest priority to the tasks you really want to be "deterministic", such as PID execution and motion control, and you will always have these tasks as periodic.

But that will always leave you with a task that has the lowest priority, so having it as a continuous task means you are getting the best "bang for the buck".

Any time the processor is "waiting" for an execution "slot" of a task is just "wasted" processor time. CPU utilisation should be always 100%, and your continuous task is making use of time that other more important tasks are not executing.

Do I really care that my Input to Output delay is 40mS or more for my control I/O ? No I don't, in the same way that I don't care if the contactors I am driving have a similar "delay" before the contactors have moved. What I am always concerned about is the instructions that are "time-based", e.g PID, are actually executed implicitly so that the math they use is relevant.

rupej said:

But think about it- if by switching to perodic was able to free up system time for comms by scanning the task less often, couldn't the same thing could have been accomplished by increasing the system overhead time slice? Anyways, the latest generation of processors has a dedicated core for comms, so program scan has no effect on comms. They even removed the SOTS out of the menu for since it has no function. That may be why Rockwell removed the note about switching to perodic tasks as Mispeld found.

I don't think anyone is arguing for continuous task just because it came around first. Also, most of us are trying to have a constructive discussion- not sure why some of you are getting so emotional about this.

Click to expand...

Ok, so my "legacy" L6x series processors may be old hat, but I still think the discussion about what your controller is processing is relevant. I don't believe that RA have removed the need for the Continuous Task, just because they've reserved a core for comms.

daba said:

The biggest concern with using multiple periodic tasks, with perhaps no continuous tasks, is the priority of those tasks.

Click to expand...

Have you ever completed a project with no continuous task? From your past comments, it sounds like no. Perhaps you should hold your comments until you have more experience.

Phrog30 said:

Have you ever completed a project with no continuous task? From your past comments, it sounds like no. Perhaps you should hold your comments until you have more experience.

Click to expand...

I'm not sure that "experience" has anything to do with it, but for your information have been working with Logix5000 for over 20 years, configuring systems and even training for RA for a couple of years.

Having a continuous task means I do not have to consider another level of task priority. I do not have to consider "importance". I do not have to consider what happens if my tasks "overlap". I simply make the controller work as hard as possible.

When you put "glue logic" into a periodic task, what makes it important to execute at a specific task period, answer = nothing.

daba said:

... have been working with Logix5000 for over 20 years...

Click to expand...

Well, then you should be good at it and know what you are talking about. It doesn't sound like you do. Your comment on why spend thousands on a processor to sit idle is top ten dumbest things I have ever heard!!