Contrologix Tasks

[DEVO 0]

Typically I program everything in Contrologix using the continuous task. I have been looking at some of the other options but I don't see too much info on why you might choose one type of task (event, periodic, motion) over another. The motion task seemed the most straight forward, but then I have seen where it was suggested to use an event driven task and run it off of the motion update. The periodic task can be used for PID execution but I have never had a use for it otherwise. I was just wondering what others use the different tasks for and why. As usual Rockwell is pretty vague on the subject. Thanks!

[paulengr 44]

First off, part of what we have here is a paradigm shift. PLC programmers typically think in terms of updating all I/O on every scan, whether it needs to be updated (there is a change-of-state) or not. In fact if you put conditions in front of a JSR, it frequently confuses some PLC programmers (and electricians) because the paradigm is that ladder logic is a simulation of "real world" relay ladder logic, even when it is blatantly obvious that ladder logic code is nothing like the real world. In the PC world, we've had interrupt tasks almost since the first microprocessors became available. They are a convenient way to increase the speed of servicing I/O. Similarly, multitasking first became available in the 1960's to 1970's and it is very useful to dissect a large system into multiple independent programs. This becomes even more useful if we need to service some programs much more often than others (say those involving user interaction, or video, or audio). A lot of this was done (and is still done) for performance reasons. Typical PLC programming would be termed "busy-waiting" because it is polling or updating over and over and over without any actual changes occurring at all. Polling is very simple to write but extremely inefficient if you are competing for computational resources. So with PC programming we'd typically use interrupts, or interrupts in combination with DMA transfers (where the I/O handles loading the new data into memory without CPU interaction) for I/O, which needs servicing very quickly when needed, but leaves resources available for computation (running programs) whenever there is no I/O update required. With PLC's since they are typically extremely I/O intensive and there is rarely a "computational task", we tend to forgo these PC concepts and instead go for the much simpler busy-waiting type of I/O implementation. Simple, but computationally wasteful. So, for most PLC programs, a single continuous task or a continuous task with some relatively small periodic ones (for PID timing reasons) are all that you'll ever see. The much more complicated structure of a PC operating system with it's multiple types of task priorities which is driven by performance decisions is rarely needed or used on a PLC. With other AB processors (SLC, PLC-5), you typically had one interrupt of each type and that was all you had to work with. The ControlLogix processor simply exposed a much more rich task model more on par with PC's. This allows some previously impossible things (motion control) as well as making some more esoteric things (STI's and PII's) much easier to write and visualize. The event task is useful for instance if you require sub-millisecond responses to an external event in a high speed assembly system. In this case, you program the I/O to operate on COS (change-of-state) and then run your code based on that event. Another purpose for using this is if for instance you need some sort of user-defined "fault" or alarm sequence, or even to get any reaction whatsoever out of a PLC which causes "out-of-order" execution. It might not even be actually necessary but it is a useful programming paradigm. If you come from the PC world, an event task is an interrupt task. If your continuous task has a scan time in the 50+ millisecond range, you may need to do at least some of your I/O this way (stop buttons for instance) just because of reaction speed requirements. Another use is any time that you would need to for instance do a relatively "one-time" operation and rather than worrying about catching it in the continuous task (say with a JSR), you can load it into an event task. The periodic task has a lot of uses. First off, if you don't have a continuous task (only periodic or event driven ones), scan time is actually FASTER than with a continuous task on certain revs and CLX versions. This points to the idea of not using a continuous task at all even for "normal" routines. A second use as you pointed out is if you need very regular timing. Rather than dealing with the vagaries of timers themselves, a periodic task eliminates the issue altogether. Periodic tasks are also very useful if you have a relatively long scan time but you've also got some relatively "fast" operations that need more frequent servicing. Think for a minute about say a big, hairy, slow analog system with lots of very complicated control loops (akin to the modern equivalent of an old DCS system) but also with motor control present on the same system. In this case the continuous task may be churning out set points while the periodic tasks are running motors and actually issuing valve control functions. Finally, and this gets pretty close to what I just described, you get into the world of "mission critical" or "real time" tasks that need absolute, defined timing. This is the kind of thing that you see nuclear and aerospace engineers fret over...they want gaurantees on servicing their tasks, not just whenever the continuous task gets around to it. The motion task is very similar to the requirements of periodic tasks. To get tight bandwidth control with motion systems, typically in the past PLC's were seen as far too slow. Motion controllers need millisecond or even submillisecond loop updates because loop update speed actually becomes a significant machine bandwidth constraint. So yes, a "motion task" looks a lot like a periodic task. You can harness it as a periodic task but it also brings along the overhead of updating motion axes, so if you are not doing motion, a periodic task is the better choice.

[patb63 0]

Well said, paulengr. In our company, we use the periodic task frequently. We are tracking cartons on relatively high speed conveyors and use the periodic task (with a frequency less than our encoder pulsing) to update positions of the cartons so we know precisely when to fire diverts to reroute them.

[Armadillo852 25]

We use the periodic tasks as well. We use it on a turn table that we need to turn 90 degrees. It doesn't need to be scanned every cycle as it is only a periodic cycle. Paul, You are a very knowledgeable individual. I don't know about anybody else, but I sure enjoy reading your explanations. Very detailed and great information. You should be teaching at a college somewhere. Keep up the good work.

[TConnolly 13]

Rockwell instructors often do an eye opening demonstration at Automation Fair, CATM, and trade shows and product promo events where they are demonstrating products when they demonstrate the task monitor. They go online with a ControlLogix processor that has a continuous task program in it that is taking around 10mSec to scan. They show the task and how much processor resources its consuming in the task monitor. Then they change the continuous task to a periodic task and give the task a 5 mSec period. Then they re-run it and show the change in the task monitor. The task that was taking 10 mSec in the continuous task now executes in under 2 mSec and processor use goes down since its not doing much most of the time. The CLX is doing the exact same thing but now its doing it twice as fast. It might seem counter intuitive at first but the continuous task is the runt pup nearest the hind leg - it get pushed off by by everything else including all the system tasks. All that task interruption and swapping has overhead and the continuous task is the one that pays the penalty - everything else has priority. High priority periodic tasks get to run through without interruption. Some time when you get the chance try it out. Go online with the task monitor tool and note the continuous task performance. Change your continuous task to periodic and use a period that is a little lower than the continuous scan time. Then watch it on the task monitor tool. It will give you an idea of how much more you can speed up the periodic task. I keep the continuous task for low priority stuff but I've seen some programs where the programmer just deletes the continuous task in favor of the more efficient periodic tasks.