Logix 5000

I've been reading a textbook on ControlLogix (CLX) trying to figure out how this thing works so I can potentially leverage the ideas into one or more projects.

I have been using CLX for about 8 years now, but primarily 'like' an SLC as this is what I'm familiar with.

So I'll start with a basic concept and I'm curious what, if any, benefits any of you have had.

The first basic concept is tasks: there are three types in CLX--continuous, timed, and interrupts.

Up to one continuous task is allowed, and it will only execute when other tasks aren't running. So really, it's a 'run when nothin else is running' task and not continuous.

The local AB rep that's a CLX expert says that you don't really need more tasks, just more programs...which to me sounds exactly like SLC type stuff.
But he also said that IF timed tasks are used, that the continuous task should be deleted.

So, what I'm wondering is, has anyone used a CLX with more than on task? How should tasks be architected into the project?

I have spare CLX processors that I have been experimenting with tasks on, and I still frankly don't know what any rules of thumb might be for tasks.

I have read a bunch of the online guides on HOW to make the tasks, but not WHY to make the tasks.

I use separate programs often with larger pieces of equipment. Good example is when I have multiple stations along a conveyor or a transfer line. Each station is completely independent of its neighbor so I like to set up multiple programs with their own set of tags.

Tasks, not so often. If I need a burst of fast analog activity I'll set up a separate task triggered by an event. Or if I have something that needs I/O updated at a very very slow rate, a water heater PID or level or something like that but thats almost never.

For me, its machine size dependent and how many different things I'm trying to do.

this is a good guide
http://literature.rockwellautomation.com/idc/groups/literature/documents/rm/1756-rm094_-en-p.pdf

describes pretty much everything regarding tasks and programs, including priorities and how the controllers allocated run persmissions to programs.

as a side note I run alot of programs in periodic tasks, especially PID, think about slow loops you don't need them running every 10ms, so why waste resources.

for example I have a real slow level loop where I am now that the PID block only really needs to run every 2 seconds, any faster and I see no performance gains as the process response times are slow.

Also with periodic and event you can set priority levels.

I think perhaps there is some miscommunication between you and your local rep. Because I don't think a rep anyone would call an "expert" would say a few of those things.

This is just an overview.....

There are three types of Tasks.

The Continuous task is similar to what you had in the SLC 500. It is self-triggered and automatically repeats. It will scan through your code and when it completes it will retrigger. For most applications, the continuous task will contain most of your logic. This logic will run all the time unless it is interrupted by higher priority tasks.

The Periodic Task will contain logic that you need to run on a timed basis. This is similar to what is called a Selectable Timed Interrupt (STI) in the SLC 500. When the defined time period expires it will interrupt lower priority tasks like the Continuous and run the code in the Periodic Task one time only and then resume the previous logic. For example, timers generally have some inaccurracies and accumulated error due to scan time. I often will say if close is good enough, timers are great. If you cannot have "good enough" such as with motion or process functions like PID, then you want a Periodic Task. Some programmers in certain applications such as motion heavy applications might remove the Continuous task and run their code exclusively in the periodic tasks. This is not required though.

The Event Task is similar to something called the Discrete Input Interrupt (DII) in the SLC but can be used many more ways. It relies on a trigger to tell it when to execute. When the trigger occurs it will interrupt lower priority tasks like the Continuous. It will scan the logic within the Event task one time only and then resume the previous logic. An event task could be used to react much faster to a high speed input than the normal Continuous task.

You can have 32 tasks total. Only one of which can be Continuous.

Within each task, you can create "programs". This is really the part that you didn't have in the SLC 500 system. Programs are used as a way of organizing or grouping routines and tags. I like to think of them sort of as folders. I can take routines for a specific piece of equipment and organize them into a program(folder). This could make it easier to troubleshoot and perhaps make it easier for me to reuse that code.

Again, this is just an overview.

OG

I understand tasks, what I don't know is how to architect them into a solution; I do like the idea of compartmentalizing functionality into separate programs, and was thinking that each time that I am deciding on program, should I instead be thinking Task and Program, not just program?

I have done mult-threaded programs in the past (on a PC) and found troubleshooting and debugging to be very difficult; like the CLX processor, a CPU in a PC can only process one thing at a time; the multiple tasks feels like multi-threaded programs.

In modern programming languages there are a lot of useful ways to deal with multi-threaded programs; CLX doesn't seem to have the same tools.

TRieglerJr said:

1) The local AB rep that's a CLX expert says that you don't really need more tasks, just more programs...which to me sounds exactly like SLC type stuff.
But he also said that IF timed tasks are used, that the continuous task SHOULD BE DELETED.

Click to expand...

Your local AB rep is a salesman, not an expert, what he has told you is wrong! He ought to be dismissed if that is what he has told you ! Definately a NO NO NO !!

I can show you, but don't need to, examples of how all three task types can take their place in a working control system. You only need to think about what their uses could be to negate what this guy has told you.

It would be very easy to say "Don't listen to bad advice" - good thing you came here to check it out and get 2nd, 3rd, 4th.......opinions.

Having read your posts, here are some thoughts....

1. The logix5000 controller is NOT multi-threaded. Tasks execute by priority, the continuous task has the lowest (fixed), and the others, Periodic and Event, you choose priority level.

2. You don't HAVE TO have a continuous task, but can honestly say i've never seen a control system without one.

3. Use Periodic tasks whenever you need something to happen at a precise time interval, rather than rely on the very variable scan time of the controller.

4. Use Event tasks when you want super-fast response to something external happening.

5. Put everything else in the continuous task.

My 2c

PS. Whenever you use Periodic and Event Tasks, you will delay (slow down) any tasks that have a lower priority. Tasks with equal priority will be "time-sliced" until their individual execution is finished. Does that help to make it clearer ?

There is nothing wrong with deleting continuous task.
In fact it gives all available time to comms and ignores STOS.

Also keep in mind that task switching controller actually running slowly. And two tasks with the same priority will interrupt each other at 1ms interval.
So if you need performance, then all above is very important.

Contr_Conn said:

There is nothing wrong with deleting continuous task.

Click to expand...

Nothing wrong indeed, but not usual.

As far as comms is concerned, there are two things you can do to affect comms processing.

Firstly, there is a setting that lets you devote processor time for "housekeeping". It's called the System Overhead Time Slice. That includes servicing comms. Find it on the advanced tab for the processor status.

From V16, you can also elect to let the unused "System Time-Slice" be used for normal processing. I can't think of a reason not to.....

Secondly, there are instructions that you can put in your code to allow you to switch Off (UID), and On (UIE) interrupts. Switching them off (UID) overrides any task priority, system time-slice etc. IMHO it will only be necessary to UID for the most demanding of applications. Use it at your own risk !!

Nothing wrong indeed, but not usual.

Click to expand...

Daba, I think you are trying to mislead the OP.
It is more common than you think.

Most of high end, high performance applications I've seen in the recent past, have no Continious task and as far as I know this is in all RA design guides now.
Take a look at the PlanPAx guide for example.

Continious task is the least efficient way of program organization, it comes from SLC/PLC5 time.

While your description of SOTS is correct, with continous task comms will be shared at specified % and as result time will be wasted while switching tasks (cont - comms).
With no continious task 100% time will be allocated for comms. It is more efficient than "Do comms selection" in v16+.
Without continious task you user does not need to worry about STOS at all, is simply does not exist.

While I don't agree with OPs original statement that "you don't need more tasks", having too many of them will hurt performance.
With only few periodic tasks, you can excute all logix at predictable rate leaving other time for comms and housekeeping.
Also time based task are mandatory for most of Function block instructions.

I've recently be pushed to eliminate the use of the continuous task by our Rockwell Vendor (not the sales guy, the tech guy). We already use 4 - 8+ tasks in a program, no point in using the continuous task for only one of those. Most of the reasoning comes from the fact that you can use the "Task Monitor Tool" to see the performance of all the tasks in your controller. From there you can increase/decrease the task times to better optimize the controller resources. Very handy tool. If you are using the continuous task, your controller will always be at 100% usage (which makes sense), where as with periodic you can get a better feel for how much the controller is being taxed because you can better manage actual task times. He had other reasoning as well, but I wasn't had a level where I truly understood it all, I need to read up on it more.

Tasks do have a limitation, and that is the number of programs they can contain, = 100. So, if you need more than 100 programs you'll need another task. For our control systems, we'll exceed that mark easily because we use the equipment phase routines (large batch systems). Add in tasks for slow/fast PID loops, totalizers, IO mapping, general processes, misc, and you can see why I have multiple tasks in use.

The SLC doesn't give you multiple programs, you get 1 program, and multiple subroutines.

I create tasks based on timing needs, I create programs within those tasks based on grouping similar functionality together, then routines based on what processes I need to control.

I feel like deleting the continuous task is the right thing to do, but it's foreign to me so I hesitate.

The systems we build have vehicle positioning control loops that are the most intense thing; otherwise, it's basic tank servicing (fill, heat, cool) and feeders connected to scales, and also controlling rectifiers...all of which are very simple low bandwidth loops.

The basic idea I have is to create a high priority task and place the positioning loops in one program per vehicle we control.

Place all of the other stuff in other, lower priority, lower interval tasks.

The current way of using a single continuous task I feel doesn't leverage the power of tasks, plus on larger systems the scan time of the processor varies a bunch and the precision of the timers is bad.

I plan on creating a new thread to discuss programs and variables.

Contr_Conn said:

Daba, I think you are trying to mislead the OP.

Click to expand...

No, not deliberately.

Contr_Conn said:

Most of high end, high performance applications I've seen in the recent past, have no Continious task and as far as I know this is in all RA design guides now.
Take a look at the PlanPAx guide for example.

Click to expand...

I don't know about the guidelines, and I might have to make a case disagreeing with them, but in my opinion if the processor is doing NOTHING at times, then it is inefficient, and the code that it could have executed at the lowest priority will spoil the tasks that need fast response/high speed. Having a continuous task means that the processor is always doing SOMETHING useful.

Contr_Conn said:

Continious task is the least efficient way of program organization, it comes from SLC/PLC5 time.

Click to expand...

It doesn't matter about efficiency, that is precisely why Periodic and Event tasks were provided. You create program "efficiency" by devoting the smallest amount of program code that runs only when needed.

Contr_Conn said:

While your description of SOTS is correct, with continous task comms will be shared at specified % and as result time will be wasted while switching tasks (cont - comms).
With no continious task 100% time will be allocated for comms. It is more efficient than "Do comms selection" in v16+.
Without continious task you user does not need to worry about STOS at all, is simply does not exist.

Click to expand...

It does not harm the system to put SOTS as high as it will go, giving Comms the biggest slice of the cake, all it means is the continuous task, where I would put non-critical code will trudge along being delayed by comms, and interrupted by event and periodic tasks - at least the processor will be doing stuff.

Contr_Conn said:

With only few periodic tasks, you can excute all logix at predictable rate leaving other time for comms and housekeeping.

Click to expand...

IMHO there will always be code that doesn't need to run "at predictable rate"... We can use the processors lowest priority task for this code.