Logix5000 Continuous vs. Periodic Tasks

Phrog30 said:

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.

Click to expand...

Woosh

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...

My explanation holds true for that as well... Mainly because faults impact cycle time and you probably wouldn't want to depend on the continuous cycle for some things to be checked.

cardosocea said:

My explanation holds true for that as well... Mainly because faults impact cycle time and you probably wouldn't want to depend on the continuous cycle for some things to be checked.

Click to expand...

I think we can agree that for a particular section of code, the continuous task will always scan more often than a periodic task. That has to be true, unless you are OK with getting overlaps in the periodic task.

I suppose the exception to this (and maybe this is what you're referring to) is that if you already have periodic tasks, then your continuous task is being interrupted and the scan time is therefore longer and inconsistent. Taken to the extreme with periodic tasks that were called exactly as often as their scan time, the continuous task wouldn't run at all.

https://rockwellautomation.custhelp.com/ci/fattach/get/162759/

Gives some good information. It does state that the continuous task will get interrupted by the background tasks depending on the time slice rate, and will result in a partial scan.

I have given great consideration to my input on this thread.

My first thought about the postings I have read is that if RA are advocating not using the continuous task, why do they provide one?

My second thought is that if everything was periodic or event-driven, what is the processor doing for the rest of the time ?

My feelings are that everything should be in a continuous task, UNLESS it is required to be periodic (e.g PID execution), or event driven. Surely this gives the optimum CPU utilisation.

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

daba said:

My second thought is that if everything was periodic or event-driven, what is the processor doing for the rest of the time ?

Click to expand...

The answer is in the file Maxkling posted, look at the end... it just hangs out playing video games.

I used to be in the same boat, everything continuous. But, then I tried periodic and it has worked out better for large programs. My opinion, there is not really a right or wrong. I also don't think everyone will agree with either side.

Phrog30 said:

The answer is in the file Maxkling posted, look at the end... it just hangs out playing video games.

I used to be in the same boat, everything continuous. But, then I tried periodic and it has worked out better for large programs. My opinion, there is not really a right or wrong. I also don't think everyone will agree with either side.

Click to expand...

That document only explains how the SOTS impacts on the running tasks, it does NOT advocate not using a continuous task at all.

Why would you spend thousands of dollars on a processor to have it sitting idle for a percentage of the time ?

For me, use the continuous task for non-critical processing, use periodic tasks for code that has to be run at a certain "rate" or "period", and use event tasks to trap "events". An english expression - "horses for courses".

Still waiting for advocative links to documentation from the RA stable to not have a continuous task .....

Thanks daba, you proved my point!! You aren't going to change my mind or opinion, probably as mine won't change yours...

My main reason to respond to your post was to answer your question on what is the processor doing for the rest of the time? As I said, it's at the bottom. What else would it being doing??

NOTE:
If there is no continuous task, the time slice setting has no effect. All processor time not used for other tasks will be used for background operations.

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 read it, in the 5000 processor manual.
Likely mentioned on knowledgebase, as well.

The key thing you give up when you do not use Periodic (i.e. keep Cont. active) is the task monitor tool.

I found out, by experimentation, that if you have a MAIN routine, and you make it run in a Periodic Task, vs. a Cont. Task, it will actually run a wee bit faster. I had a program that went from 62mS down to 58mS.

Phrog30 said:

Thanks daba, you proved my point!! You aren't going to change my mind or opinion, probably as mine won't change yours...

My main reason to respond to your post was to answer your question on what is the processor doing for the rest of the time? As I said, it's at the bottom. What else would it being doing??

NOTE:
If there is no continuous task, the time slice setting has no effect. All processor time not used for other tasks will be used for background operations.

Click to expand...

I make the argument the other way...having a Periodic and Event based design just shows that the designer was actually thinking ahead, and can put things where they actually need to be. OTOH, it surely is o.k. to 'think like a PLC-2', and have one big old task.
The programs of today, and the I/O are just getting too big.
And, think of an AC-Input module, local or remote...why in the world would anyone ever, under any circumstances, sweep that module any faster than 16mS? If your program executes in 5 milliseconds, you just gather stale information that was never going to update anyway.

daba said:

That document only explains how the SOTS impacts on the running tasks, it does NOT advocate not using a continuous task at all.

Click to expand...

Correct, just suppling good information on the differences between the two. Obviously, as stated multiple times, their default task wouldn’t be continuous if it did have merit. I have a couple huge programs that must run under a periodic task, I might bench test it and switch to a continuous task and see the outcome.

I think planning is everything, choose what you need and what works the best. But there can definitely be some “gotchas” that will bite you in the *** if you don’t understand the inner workings.

jdbrandt said:

And, think of an AC-Input module, local or remote...why in the world would anyone ever, under any circumstances, sweep that module any faster than 16mS? If your program executes in 5 milliseconds, you just gather stale information that was never going to update anyway.

Click to expand...

But the longer the scan time, the longer it takes to respond to the input. If your program's scan time was 16ms, and it scanned 0.1ms before the input went true, it wouldn't see the input until it had been on for 15.9ms. If the scan time was 5ms, it would only have been on for 4.9ms before it noticed.

In my mind, faster scan time is almost always preferred.

jdbrandt said:

I found out, by experimentation, that if you have a MAIN routine, and you make it run in a Periodic Task, vs. a Cont. Task, it will actually run a wee bit faster. I had a program that went from 62mS down to 58mS.

Click to expand...

That is interesting. Was this on a pre-L8x or 5059-series processor? One reason for a faster scan time on a periodic task could be that it was no longer being interrupted by the system overhead time slice. That could be disadvantageous, depending on the situation.

rupej said:

I think we can agree that for a particular section of code, the continuous task will always scan more often than a periodic task. That has to be true, unless you are OK with getting overlaps in the periodic task.

Click to expand...

Let's imagine this scenario, you have a continuous task that scans at a 40ms rate. Should, let's say an IO module or a communication function hang, the cycle time will increase and potentially be outside what you deemed acceptable.
If you have the code running at a 20ms cycle, it will run at that speed regardless and you'll monitor the section of the code you want always.

daba said:

Why would you spend thousands of dollars on a processor to have it sitting idle for a percentage of the time ?

Click to expand...

This is literally what happens with 90% or more of all processors built today and quite likely in the last decade. Your computer, phone, TV, Alexa, Ring Camera, whatever will at one point be idle.

Using periodic tasks will allow you to get more out of your processor by understanding what needs to run fast and what doesn't. Do you really need your temperature control loops to be running at 20ms? I reckon for most of them, 100 or even 300 ms would be acceptable. That would free up the processor to do more stuff.

So there is an inflexion point where using the periodic tasks does indeed let you achieve more out of your processor by rationalizing what needs to run fast and what can run slow.
This is already something that people in CS have figured out and is used extensively in many systems (even 8 bit micros can run RTOS's for example).

Honestly, it would not surprise me to see concurrent processing of PLC programs in my lifetime (I'm roughly 20 years from retirement) and making use of this way of controlling things will likely become norm should that happen.

cardosocea said:

Let's imagine this scenario, you have a continuous task that scans at a 40ms rate. Should, let's say an IO module or a communication function hang, the cycle time will increase and potentially be outside what you deemed acceptable

Click to expand...

But that's not how Logix5000 processors work. The previous generations carved out the SOTS, which dedicates a certain amount of time to comms (including I/O I believe). If something hangs, too bad for the comms, after the time slice is expired, the processor goes right back to the continuous task. The latest series has a dedicated core for comms so the continuous task is free to run uninterrupted, except by periodic and event tasks.