Logix5000 Continuous vs. Periodic Tasks

One question :
I use continuous Task in most of my projects and some periodic task in others, Is a good start using 7 as priority to my tasks due to the fact that I/O tasks on Compactlogix has 6 as priority and to interrupt I/O with a higer priority ( lower than 6) is a bad idea ?
Most of my projects are based on Compactlogix.
 
I've been moving lines over to the L8x processors; when I do that, I get rid of the continuous task entirely, and use only periodic tasks.
Those processors are so stupid fast that I don't see any real point in scanning a program faster then my IO can update.
 
I've been moving lines over to the L8x processors; when I do that, I get rid of the continuous task entirely, and use only periodic tasks.
Those processors are so stupid fast that I don't see any real point in scanning a program faster then my IO can update.


So basically you have moved useful processing time to the garbage bin.

Periodic Tasks : Code you want to execute at specific time intervals.

Event Tasks : Code you want to execute when something changes.

Continuous Task : everything else


Does it really matter ?
 
I ran a few tests this morning and was rather surprised by the results. Using L81 v32:

Test 1 - No continuous task, 4 tasks, 10ms Pri 4, 25ms Pri 10, 50ms Pri 10, 100ms Pri 10. Using webpage average scan time for all tasks (added together) 5.6ms - CPU 11%
Test 2 - moved all programs from last test into a continuous task. Using webpage again, average scan was 3.3ms, CPU 100% (which is normal since it's continuous).

Wasn't the results I would have guessed. Perhaps my test(s) were flawed, but definitely interesting nonetheless.
 
Interesting, but you can't really add them together though. They aren't all running sequentially in one "scan".

Also, at the end of each periodic task, the I/O is being serviced. Whereas with the continuous, it is only being serviced at the end of that one task. So all that extra overhead goes away.

Add in the continuous task without any logic and view it's max scan time. That should give a better idea of the overall max scan time for Test 1.

OG
 
Interesting thread, thank you for all of the information.

I've only been working with Rockwell for about 1 year and I had to look up half of the acronyms used in this thread.

I've never used anything except a continuous task. I assume that is the default "main task." I'm not even certain what category the safety task falls under.

Anyhow, I find the "time" measuring contest to be helpful even though it makes me afraid to post for fear of facing the wrath of someone oh so much more experienced and knowledgable than myself. Lookin' at you Phrog.

On the other hand, I do understand the enjoyment of a good trolling expedition.
 
Oh, and for the record, from my perspective, I believe the side of the debate advocating the use of continuous tasks to maximize CPU usage was the winner.

But again, I didn't even know what SOTS stood for.
 
Phrog: it doesn't make sense to have more than one periodic task with the same priority. If their execution overlaps the scheduler will run one for 1 ms and then bounce to the other one, run it for 1ms, and then switch back, incurring up to a 0.25 ms overhead for each context switch.

If asked I would recommend avoiding use of continuous task and system overhead time slice due to:

1) increased communication load slowing down the execution of the logic. If somebody starts reading a bunch data from the PLC for a report, or adds a bunch of stuff to the HMI, or goes to a particularly data intensive HMI page, then there is less unused system overhead time slice for executing the logic and the logic isn't run as frequently. It probably doesn't matter in most cases but I would prefer the PLC focus on controlling the outputs based on the inputs first, and sending out packets to whatever external non-IO clients on ethernet second.

2) Rockwell's plant pax manual is really insistent about not using the continuous task. Probably because a PLC program that uses their PAx system is going to have a long scan time since there is so much frickin logic in those blocks, so it is mandatory for the programmer to take over prioritizing IO and logic with a series of periodic tasks.


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

4) The use of the continuous task and system overhead time slice limits the flexibility of the controller to apply resources to handle abnormal conditions in communication (PlantPAx Distributed Control System System Release 4.5 Reference Manual, 2018, p. 40). Sounds to me like the system overhead time slice doesn't leave enough contiguous time to service the communications with the increasing communications demands over time
 
Last edited:
V0N, I don't think most of that is relevant in the latest controllers. They have a dedicated core for comms, so unexpected comms conditions can't affect logic processing, and likewise the logic won't affect comms.

The 1756-L8x processors have been out for about 4 years now if I'm not mistaken (5069 came a bit later). If someone is writing a new program, there's very little reason to go with the older series that use the SOTS. So I think the discussion needn't be focused on the older hardware, since I doubt that anyone is going to change an existing running program from one method to the other.
 
Last edited:
.....

Also, at the end of each periodic task, the I/O is being serviced. Whereas with the continuous, it is only being serviced at the end of that one task. So all that extra overhead goes away.

OG


That is incorrect. I/O is "serviced" during the SOTS, which is a percentage of the overall CPU task execution schedule.

Many of my past projects use a SOTS set at a very high value, while making sure the check-box is checked to return to my logic processing when I/O and comms servicing is done (unused SOTS).

Things may have changed with the dedicated core in more up to date processors, but the principles remain surely.

Pushing everything into periodic tasks must mean that you are always going to be nervous about task overlap, unless you set your periods low, and that means you will be under-utilising the controllers CPU capabilities.
 
V0N, I don't think most of that is relevant in the latest controllers. They have a dedicated core for comms, so unexpected comms conditions can't affect logic processing, and likewise the logic won't affect comms.

The 1756-L8x processors have been out for about 4 years now if I'm not mistaken (5069 came a bit later). If someone is writing a new program, there's very little reason to go with the older series that use the SOTS. So I think the discussion needn't be focused on the older hardware, since I doubt that anyone is going to change an existing running program from one method to the other.


Even with a dedicated "core" for comms, I still want my controller to be working at 100% CPU utilisation, so will be continuing to use the continuous task.

Periodic and Event tasks when needed.
 

Similar Topics

I have a RSLogix5000 project that I need to test for various program sizes, in order to validate its robustness. I want to introduce delay in my...
Replies
14
Views
4,499
I'm a Siemens person, and this is one of my first AB programs. The customer wants everything programmed in Ladder. I have a lot of data (3...
Replies
14
Views
159
Good day everyone. if you have a logic for 3 pumps (lead/lag/off), would you please email it to me? I really appreciate it!
Replies
7
Views
157
Maybe this is just not possible, or maybe I am doing something wrong. Background; I have a data array of over 1500 products. For sorting I...
Replies
6
Views
727
Hello everyone, I'm currently using RS Logix5000 software for machine programming with this Rockwell PLC using the Structured Text method. The...
Replies
19
Views
1,951
Back
Top Bottom