CompactLogix Tasks - Is Continous Bad?

[FactoryTalktotheHand]

Had an interesting phone call today with a fellow controls engineer who claimed that Continuous tasks are bad for the processor and cause it to "overload." What had happened was they were having issues getting online and their program consists of 5 tasks, all of which are Periodic, with update times ranging from 2ms to 1000ms. I added a Continuous Task with five rungs, do to some simple Counting. They're claiming it's my addition that is causing the trouble going online.

I was a bit taken aback by this for several reasons. I've never heard such a thing for one. Also, if Continuous tasks were universally bad for processors, why would Rockwell even allow you to program it that way? Third, isn't it the case that ALL A-B processors up until the Logix era ran EXCLUSIVELY as Continuous Tasks? Why would the Logix platform--a more powerful processor family--not be able to handle it when "lesser" processors could? Additionally, I've programmed quite a few Logix-family processors and have used almost exclusively Continuous Tasks. I've never had an issue with scan times or timing. Finally, how would this prevent one from going online with the processor? I've been online with this particular processor many times without issue. As a side note, their program was at least in part a conversion from a SLC program (they left all their tag names as N[7] and B[3] type tags), so I know for a fact that their program at one time DID run exclusively as a continuous task, on less powerful hardware with less memory.

Am I missing something here? Could my five rungs really have caused such a huge problem? I doubt it, and personally I think they were grasping at straws due to not being able to figure out the problem, but I'm willing to be enlightened.

 

[Jeev]

A continuous task would only become an issue like that if something is wrong in the program, configuration, comms, or allocated overhead. Almost all the programming we do is with Continuous Tasks, with the exception of Event Driven or Periodic for certain functions. We do not have faults or communications issues with our processors.

It might be prudent to find out what the real problem is here.

 

[OkiePC]

The communications timeslice value (If i remember my terms correctly) will affect whether or not having a continuous task could have lead to the problem. There is nothing inherently wrong with using a continuous task, but I tend to use all periodic tasks, I guess mainly because I like predictability and control.

 

[jdbrandt]

Had an interesting phone call today with a fellow controls engineer who claimed that Continuous tasks are bad for the processor and cause it to "overload." What had happened was they were having issues getting online and their program consists of 5 tasks, all of which are Periodic, with update times ranging from 2ms to 1000ms. I added a Continuous Task with five rungs, do to some simple Counting. They're claiming it's my addition that is causing the trouble going online.

I was a bit taken aback by this for several reasons. I've never heard such a thing for one. Also, if Continuous tasks were universally bad for processors, why would Rockwell even allow you to program it that way? Third, isn't it the case that ALL A-B processors up until the Logix era ran EXCLUSIVELY as Continuous Tasks? Why would the Logix platform--a more powerful processor family--not be able to handle it when "lesser" processors could? Additionally, I've programmed quite a few Logix-family processors and have used almost exclusively Continuous Tasks. I've never had an issue with scan times or timing. Finally, how would this prevent one from going online with the processor? I've been online with this particular processor many times without issue. As a side note, their program was at least in part a conversion from a SLC program (they left all their tag names as N[7] and B[3] type tags), so I know for a fact that their program at one time DID run exclusively as a continuous task, on less powerful hardware with less memory.

Am I missing something here? Could my five rungs really have caused such a huge problem? I doubt it, and personally I think they were grasping at straws due to not being able to figure out the problem, but I'm willing to be enlightened.

Well, I can tell you from recent personal experience that making the MAIN part of your program into a Periodic Task can increase performance, from a total time standpoint.
The Cont. Task is the lowest priority, and, as such, always get interrupted by everything else.
I had a system that was ~62mS in 'time between cycles' of the Cont Task. There was a small periodic task at a short interval.
I changed the Main task to Periodic at 46mS, and left the little periodic task alone.
The result was that, sure enough, the now-periodic task executes as ordered, at 46mS.
The value of 46 was based on using the task monitor tool, and manipulating the value until the processor was 90% loaded, or less. (Oh, the execution time of the Main task was ~42mS when it was a Cont. Task.
.
So, I'd recommend trying this approach (not on a live system, of course) and seeing what your results are.
Note: If you use the task monitor on the Cont. Task approach, it will say the processor is 100% committed, which, of course, it IS.
Good Luck.
Have Fun.
Be safe.

 

[jdbrandt]

The communications timeslice value (If i remember my terms correctly) will affect whether or not having a continuous task could have lead to the problem. There is nothing inherently wrong with using a continuous task, but I tend to use all periodic tasks, I guess mainly because I like predictability and control.

Timeslice, in PLC-5 days (S:77) was the amount of time that the processor would add between Output Update and Input Scan.
It has no really useful use (fun to play with on an offline system), and came into play when the PLC 5/40 was introduced. There was a firmware issue when you had a small local rack, and a small program. The fix (then) was to put a value in S:77 to actually increase the effective scan time.
.
In reference to a CLS5k, if you have a continuous task, there is, essentially (as I read it) no timeslice,, except as the processor needs in order to do other things, which, as well all know, are those features and things that only the manufacturer knows about.

 

[OkiePC]

Thanks for the correction. I am getting rusty with my PLC-5 stuff and CRS is setting in fast. I could have sworn there was something very similar with "timeslice" in the name for Controllogix. I seem to recall making adjustments to it before when I was testing the maximum performance of a project with Compactlogix many years ago. It must have been called something else.

 

[scameron81]

Thanks for the correction. I am getting rusty with my PLC-5 stuff and CRS is setting in fast. I could have sworn there was something very similar with "timeslice" in the name for Controllogix. I seem to recall making adjustments to it before when I was testing the maximum performance of a project with Compactlogix many years ago. It must have been called something else.

You're probably thinking of the "overhead time slice". I think it's in the main processor settings. That or the continuous task settings. You can tell the processor how much time to dedicate to overhead(communication etc) before it starts the continuous task again. I've only messed with on one project where I was trying to make the processor scan the task as fast and often as possible.

 

[Paullys50]

Continuous task is not recommended, but shouldn't cause a noticeable issue. There are other issues going on here.

The task monitor tool is a must if you have multiple tasks. It will identify which is taking up all the processing power. However if you do use a continuous task the CPU will always be pegged at 100%, the system overhead time slice as mentioned allows for communication time and such. If you don't use the continuous task then when you run the task monitor tool you get a better idea of how much is actually going on in your processor.

My guess is that some of those periodic task are going to fast and eating up lot of processing power. OR, depending on the CompactLogix you could low in available CIP connections which will cause issues as well.

Its not the continuous task that is the root of the problem, probably doesn't help but something else is going on.

 

[Ron Beaufort]

it probably has nothing to do with whatever "complications" you're having with your COMPACT-Logix system - but you might want to take a look through this thread ...

http://forums.mrplc.com/index.php?showtopic=26162&p=125399

if nothing else, be sure to listen to the "cricket" wave file in the first post ...

note that the "loss of signal" effect being demonstrated is caused by the COMPACT-Logix platform's dedicated "I/O Task" which has a priority of 7 ... the CONTROL-Logix platform doesn't share this same operating method ...

as I said, this probably has nothing to do with your current "going online" problem, but since you're dealing with "weirdness" in a COMPACT-Logix system, I thought that I'd mention it for completeness ...

so what priorities are they using for their periodic tasks? ...

I added a Continuous Task with five rungs, do to some simple Counting.

are there any "recursive/looping" actions going on in the code that you added? ... if so, then there COULD be some impact on being able to "go online" as you mentioned ...

if the new code isn't absolutely essential, how about conducting a simple experiment by just temporarily inhibiting the continuous task and seeing if the problem goes away? ...

 

[FactoryTalktotheHand]

it probably has nothing to do with whatever "complications" you're having with your COMPACT-Logix system - but you might want to take a look through this thread ...

http://forums.mrplc.com/index.php?showtopic=26162&p=125399

if nothing else, be sure to listen to the "cricket" wave file in the first post ...

note that the "loss of signal" effect being demonstrated is caused by the COMPACT-Logix platform's dedicated "I/O Task" which has a priority of 7 ... the CONTROL-Logix platform doesn't share this same operating method ...

as I said, this probably has nothing to do with your current "going online" problem, but since you're dealing with "weirdness" in a COMPACT-Logix system, I thought that I'd mention it for completeness ...

so what priorities are they using for their periodic tasks? ...



are there any "recursive/looping" actions going on in the code that you added? ... if so, then there COULD be some impact on being able to "go online" as you mentioned ...

if the new code isn't absolutely essential, how about conducting a simple experiment by just temporarily inhibiting the continuous task and seeing if the problem goes away? ...

That's what I'm going to suggest if they push the matter further. Simply inhibiting my task will tell them whether or not my code is the problem, I agree.

As far as the code, it's simple and non-critical. What it does is is count the number of machine cycles and compares it to the number of parts that come out of the machine. So I have two counters, one that counts machine cycles and one that is connected to a photoeye that counts parts as they pass by on a conveyor belt. I multiply the machine cycle counter by the number of parts it is supposed to yield each cycle, so the resulting number is the "Expected number of parts" while the photoeye counter is the "Actual number of parts." Their external data collection system (Plex) reads these numbers and uses them to create production reports. I also have some resets to handle counter overflows.

 

[FactoryTalktotheHand]

Well, I can tell you from recent personal experience that making the MAIN part of your program into a Periodic Task can increase performance, from a total time standpoint.
The Cont. Task is the lowest priority, and, as such, always get interrupted by everything else.
I had a system that was ~62mS in 'time between cycles' of the Cont Task. There was a small periodic task at a short interval.
I changed the Main task to Periodic at 46mS, and left the little periodic task alone.
The result was that, sure enough, the now-periodic task executes as ordered, at 46mS.
The value of 46 was based on using the task monitor tool, and manipulating the value until the processor was 90% loaded, or less. (Oh, the execution time of the Main task was ~42mS when it was a Cont. Task.
.
So, I'd recommend trying this approach (not on a live system, of course) and seeing what your results are.
Note: If you use the task monitor on the Cont. Task approach, it will say the processor is 100% committed, which, of course, it IS.
Good Luck.
Have Fun.
Be safe.

I think I understand. So it can cause problems if I add a Continuous Task to a Program that is all Periodic Tasks otherwise, because before there was no continuous tasks to interrupt. And by using Periodic Tasks you are scheduling each program's scan manually.

 

[kellian]

What version of logics?
Are you using a CF card?

 

[kellian]

V17 can have connection problems when being connected to by different computers.
Rockwell have a tech note out explaining the various combinations.

 

[arlenjacobs]

If you run out of CIP connections, that would prevent going online with RSLinx. But that has nothing to do with continuous tasks.

If the real cause was the continuous task, then maybe all those periodic tasks are running too frequently and too long. But you would have to measure and calculate that out, as in the post below. Continuous tasks are fine, but it makes timing calculations difficult when you also use periodic tasks.
http://www.plctalk.net/qanda/showthread.php?t=92523

With CompactLogix, there is an I/O task which is higher priority than the continuous task and system overhead task (RSLinx comms to your PC). You cannot change the priority (7). So you need to account for that as well.

If there is no continuous task, then the system overhead gets all the remaining time after the periodic tasks. As soon as you put a continuous task in there, then the system overhead only gets a fraction of that available time (ex. 20%).


An easy test is to put the controller into Program mode and see if that clears up the issue of going online with the controller (obviously, not on a running system).

 

[FactoryTalktotheHand]

V17 can have connection problems when being connected to by different computers.
Rockwell have a tech note out explaining the various combinations.

This is an L33ER running v20.11 firmware