Logix5000 Continuous vs. Periodic Tasks

daba I'm really glad you are bringing up the pros of continuous task and evidence that it does work properly. When you set the SOTS to a "really high value" how high is that? 80%?



In the Plant Pax manual Rockwell says in development CPU load should be kept less than 50% and in production, presumably with more communications to HMIs etc, more than 70% CPU used by periodic tasks is "not OK". It seems like the minimum value for SOTS would therefore be 30% even though it comes set at 20% by default.


rupej even though the new controllers don't have the SOTS I am working on a project that won't be commissioned for a year using the 5573 controller. Rockwell is a consultant on the project and have recommended the 5573 and firmware version 31. The controllers that have SOTS will be in service for the next 20-30 years so our discussion will be helping out some poor sod in 2049.

V0N_hydro said:

3) pretty much only daba reporting using the continuous task without problems, everyone else has stepped on a land mine or been warned by rockwell support to stay away. There must be some inherent easy to encounter pitfall. Good thing they've done away with the system overhead time slice completely in the new controllers

Click to expand...

I advocate for using a Continuous Task (CT) in the pre -L8 platform because that task is the only one that runs at a lower priority (i.e., is interruptable) by the Communications Processing task. Therefore, when not using a CT, it is up to the system architect to assign appropriate priorities and schedules for all of the user task such that sufficient time is available to meet external communication requirements.

There are tools available for this, and may be a straightforward exercise on a simple program structure. But it is a point-in-time analysis that must be re-evaluated whenever there is a program change that could significantly affect task execution time. Otherwise non-I/O communications, such as historian data collection, HMI refresh, logix/studio access, and explicit messages will likely degrade depending on how much of the inter-task idle time remains available after the change.

I would rather put non-time-critical logic in the continuous task, reserving periodic tasks for response-critical and "lightweight" logic that needs to run at a fixed time period. That allows for external communication consistency and resiliency to future change via the system overhead time slice setting.

This approach will not apply to all environments, particularly where system response requirements approach the limits of the hardware capability. I would agree that hand tuning the task scheduling is necessary in those circumstances.

Right now we made a commissioning of one big system using L82 fw.31. About 15 PLCs are running in the plant.
We put almost everything in continuous tasks, except regulation, but not for all regulators. Mostly this is done because my company has long legacy with Siemens PLCs, like S7-400 which is much slower PLC. Not much experience with AB PLCs, especially these new ones.
Right now I discovered RA suggests NOT using continuous tasks at all. Meaning possibly our entire PLC system design is incorrect.
We have experienced communication problems, but I thought it was mostly because some smart guy decided to have 8 stand-alone HMIs, with each one being server and getting data from PLC from Ethernet card which supports up to 256 CIP connections.(in the end we just reduced CIP connections for each HMI).

So far it seems to be running good, no some abnormal behaviors. But I'm wondering if some communication issues we have are related to this? PLC-PLC, PLC-HMI, PLC-production computers communications seem to be slower than usual I see with Siemens PLCs.

Rockwell manuals indicate that they expect that most logic will reside in the continuous task however for extremely large programs, such as those made with Rockwell's Plant PAx conventions, the program would be too slow to meet the requirements for some of the IO, so they recommend to use periodic tasks with the programmer determining the slowest possible rate for each IO point and then grouping in to periodic tasks. The newer CPUs have a dedicated core for communications so communications and logic will not affect each other.


The downside of the continuous task is that increased communications load affects the scan time of the program, so instead of having communications issues when firing up a bunch of HMIs your process can start performing poorly if it depended on the scan time being less than some amount.



If your application is working then it is probably fine. congratulations on finishing your project.