Softball for PLC gurus

Hello folks,
When viewing the Controller Organizer of a project in RSLogix 5000 I see multiple LL programs with a little "1" on a sheet of paper under the Main Task. Does that mean that each of these LL files runs at the same time and share the processor power of the L35E?
I see other files that are there without the little "1" and found JSR routines to call them and run them. That makes sense...
Thank you!

Hi

The 1 means that that file is the main routine with in that program. This means that when the program is called during the scan it is the first routine called but NO this does not mean they are called at the same time as each other.

Donnchadh

OK, digging around a bit further I see that under "Main Task" and the Program/Phase Schedule that all the other sub-tasks are listed. So they are executed sequentially according to the order listed. Right?

Hi

Correct, but as always.
The routines( or you called them sub-tasks) within the programs are called based on the JSR. Also the tasks may not always be called as they look in the project tree as some are time based and some event based etc.

Donnchadh

jgrassel said:

OK, digging around a bit further I see that under "Main Task" and the Program/Phase Schedule that all the other sub-tasks are listed. So they are executed sequentially according to the order listed. Right?

Click to expand...

Donnchadh said:

Hi

Correct, but as always.
The routines( or you called them sub-tasks) within the programs are called based on the JSR. Also the tasks may not always be called as they look in the project tree as some are time based and some event based etc.

Donnchadh

Click to expand...

I think the answer you got was confusing, with apologies to Donnchadh. I will try to define everything as clearly as I can.

In Logix5000 there are 3 "levels".....

Tasks
--Programs
----Routines

You can have multiple Tasks the number depends on the platform (32 in a ControlLogix, 8 in a CompactLogix)

Tasks can be one of the following...

Continuous (or Cyclic) - you can only have one of these...
Periodic - triggered by time schedule
Event - triggered by something happening

Task execution.

The Continuous (Cyclic) task trundles away all day executing the Programs within it, when it has finished, it starts again, automatically.

If Periodic Tasks are configured, they will always "interrupt" the Continuous Task, and the programs within the periodic task will be executed, until the task is completed. A periodic task runs once only, until it is triggered again (by time).

If Event Tasks are configured, they will always "interrupt" the Continuous Task, and the programs within the event task will be executed, until the task is completed. An event task runs once only, until it is triggered again (by event).

Task priority settings determine which task will run, interrupting whichever task is currently executing. A task with higher priority will interrupt execution of a lower priority task. Tasks with the same priority are "time-sliced" - this is the only occasion where the controller can be envisaged to be running multiple tasks simultaneously, but in actual fact it is simply switching between the tasks rapidly.

Program execution.

Within each and every task, is a collection of one or more Programs.

Programs are executed in the order determined by the Program/Phase schedule, in the Task Properties. This is configurable, and the programs are shown in the Controller Organiser list in the order they are scheduled to execute. All programs are executed.

Routine execution.

Within each and every program, is a collection of one or more Routines.

The controller only executes the routine that is specified as the "Main Routine" in the Program configuration, and that routine is shown at the head of the list of routines in the organiser, with it's "Page 1" adornment.

The other routines are simply listed alphanumerically below the main routine, because there is no implied "order of execution". The controller does not execute these routines, they are executed by instruction code in the main routine, e.g JSR and FOR will execute these other routines as programmed in code. These other routines are therefore sub-routines, and it is up to the programmer to decide when they should be executed.

Hope this helps your understanding.

daba said:

Task execution.

The Continuous (Cyclic) task trundles away all day executing the Programs within it, when it has finished, it starts again, automatically.

If Periodic Tasks are configured, they will always "interrupt" the Continuous Task, and the programs within the periodic task will be executed, until the task is completed. A periodic task runs once only, until it is triggered again (by time).

If Event Tasks are configured, they will always "interrupt" the Continuous Task, and the programs within the event task will be executed, until the task is completed. An event task runs once only, until it is triggered again (by event).

Task priority settings determine which task will run, interrupting whichever task is currently executing. A task with higher priority will interrupt execution of a lower priority task. Tasks with the same priority are "time-sliced" - this is the only occasion where the controller can be envisaged to be running multiple tasks simultaneously, but in actual fact it is simply switching between the tasks rapidly

Click to expand...

Daba excellent post but I think you might be incorrect about Event tasks always interrupting periodic tasks. Isn't this actually based on priority? I.e. If i have a periodic task set for every 2ms with priority 1 and an event task set for priority 2 wont the plc finish the periodic task and then start the event task?

Its been a while since I messed with event tasks so I am not 100% sure. I also dont have logix here to verify

Regards
Ian

@usireland if you read daba's post he mentioned "If Event Tasks are configured, they will always "interrupt" the Continuous Task" he mentioned Continuos not periodic, although i would like to know who has priority between a event or periodic task

dbh6 said:

@usireland if you read daba's post he mentioned "If Event Tasks are configured, they will always "interrupt" the Continuous Task" he mentioned Continuos not periodic, although i would like to know who has priority between a event or periodic task

Click to expand...

Just re-read, you right he did say continuous, but my brain read periodic.

As for event vs periodic I think priority wins.

Actually he did say all. Next paragraph after:

If Event Tasks are configured, they will always "interrupt" the Continuous Task, and the programs within the event task will be executed, until the task is completed. An event task runs once only, until it is triggered again (by event).

Click to expand...

clearly says:

Task priority settings determine which task will run, interrupting whichever task is currently executing. A task with higher priority will interrupt execution of a lower priority task. Tasks with the same priority are "time-sliced" - this is the only occasion where the controller can be envisaged to be running multiple tasks simultaneously, but in actual fact it is simply switching between the tasks rapidly.

Click to expand...

That above is for event and timed interrupts

while we're on the subject ...

and in case you're interested in the fine print, the "interruptions" that are being discussed here can occur even PART WAY through the operation of a math instruction ... read the nine posts starting with the one linked below if you're interested in the details ...

http://www.plctalk.net/qanda/showpost.php?p=376167&postcount=61

note that there ARE ways to prevent these types of interruptions – the UID and UIE instructions (shown in Post #69) can be used to "rope off" a section of code if necessary ...

party on ...

Apologies if my post had any confusion about priorities, I've re-read it, and I don't see any....

However, what I failed to mention explicitly (although hinted at), is that the Continuous or Cyclic task has, by design, the lowest priority, which cannot be changed.

Therefore another task (periodic or event) which has a higher priority, will interrupt the continuous task. (Note Ron's mention of UID to prevent this, although this is sort of "un-designing the design", and not for the faint-hearted).

There is no distinction between periodic or event task priority, the one that has the highest priority interrupts the processing of the lower priority tasks.

As already stated, tasks that have the same priority setting will be "time-sliced", giving them an equal "pseudo-priority".

It goes without saying that a task that has been "interrupted" and suspended by a higher priority task, will continue where it left off once the higher priority task is completed.

Also, the priority settings are just compared by the processor, and do not have to be sequential numbers. The processor simply makes the "less than", "equal to", and "greater than" comparisons to determine task execution.

EDIT : I forgot to mention that a task that is "triggered" (by time or event), that can't execute because a higher priority task is already executing, will be executed when the higher priority task completes.

Ron Beaufort said:

and in case you're interested in the fine print, the "interruptions" that are being discussed here can occur even PART WAY through the operation of a math instruction ... read the nine posts starting with the one linked below if you're interested in the details ...

http://www.plctalk.net/qanda/showpost.php?p=376167&postcount=61

note that there ARE ways to prevent these types of interruptions – the UID and UIE instructions (shown in Post #69) can be used to "rope off" a section of code if necessary ...

party on ...

Click to expand...

The maths status flags are preserved for an interrupted instruction (they are restored when the interrupting task completes).

Also an interrupt to process a higher priority task can occur PART WAY through ANY (almost) instruction, even COP or FLL instructions. This can cause problems, because a data-set can be "split" in real-time.

CPS overcomes this for the COP, because CPS cannot be interrupted, but there is no equivalent for a FLL. If it is important to you, have a pre-filled source, and use CPS to "fill" the destination

daba said:

Apologies if my post had any confusion about priorities, I've re-read it, and I don't see any....

However, what I failed to mention explicitly (although hinted at), is that the Continuous or Cyclic task has, by design, the lowest priority, which cannot be changed.

Therefore another task (periodic or event) which has a higher priority, will interrupt the continuous task. (Note Ron's mention of UID to prevent this, although this is sort of "un-designing the design", and not for the faint-hearted).

There is no distinction between periodic or event task priority, the one that has the highest priority interrupts the processing of the lower priority tasks.

As already stated, tasks that have the same priority setting will be "time-sliced", giving them an equal "pseudo-priority".

It goes without saying that a task that has been "interrupted" and suspended by a higher priority task, will continue where it left off once the higher priority task is completed.

Also, the priority settings are just compared by the processor, and do not have to be sequential numbers. The processor simply makes the "less than", "equal to", and "greater than" comparisons to determine task execution.

Click to expand...

Great post.

Just to add one more thing, in CompactLogix controllers, there is an IO task which has Priority 6. This updates the IO of the PLC.

Personally I generally give my tasks Priority 7 or lower when using CompactLogix controllers so as not to interfere with the IO updating. This does not apply to ControlLogix but I have found myself using numbers 7 or lower as almost a Standard now (I tend to use more compact than control). It's rare that I need more than 9 levels of priority (cannot think of a case yet when it was needed) so it doesn't interfere much with the actual execuition. As Daba said, you could use Priority 15 in ControlLogix and it would be the same as using Priority 1 if it is the only interupt in the program.

Here is a KB article about Periodic Tasking (Access Level: Everyone)
https://rockwellautomation.custhelp.com/app/answers/detail/a_id/28660

Usireland said:

Great post.

Just to add one more thing, in CompactLogix controllers, there is an IO task which has Priority 6. This updates the IO of the PLC.

Personally I generally give my tasks Priority 7 or lower when using CompactLogix controllers so as not to interfere with the IO updating. This does not apply to ControlLogix but I have found myself using numbers 7 or lower as almost a Standard now (I tend to use more compact than control). It's rare that I need more than 9 levels of priority (cannot think of a case yet when it was needed) so it doesn't interfere much with the actual execuition. As Daba said, you could use Priority 15 in ControlLogix and it would be the same as using Priority 1 if it is the only interupt in the program.

Here is a KB article about Periodic Tasking (Access Level: Everyone)
https://rockwellautomation.custhelp.com/app/answers/detail/a_id/28660

Click to expand...

I've not had much exposure to CompactLogix, certainly not to the level of understanding of the in-built priority level of the I/O update.

I held off mentioning the all-powerful super-interruptor called the System Overhead Task that exists in Logix5000, didn't want to muddy the waters. It seems as though CompactLogix has separated the SO task from IO update task, and you now have a degree of control over IO update versus code execution priority, something that you don't get in ControlLogix.

Now here's a thought.... If your Continuous task just had an EVENT instruction to execute your code in an Event task, then it would be feasible to make the I/O update synchronous to the logic scan, by giving the Event task a higher priority (1-5) than the I/O update task.... hmmm anyone want to try this for me, I don't have the hardware ....

daba said:

I think the answer you got was confusing, with apologies to Donnchadh. I will try to define everything as clearly as I can.

The controller only executes the routine that is specified as the "Main Routine" in the Program configuration, and that routine is shown at the head of the list of routines in the organiser, with it's "Page 1" adornment.

The other routines are simply listed alphanumerically below the main routine, because there is no implied "order of execution". The controller does not execute these routines, they are executed by instruction code in the main routine, e.g JSR and FOR will execute these other routines as programmed in code. These other routines are therefore sub-routines, and it is up to the programmer to decide when they should be executed.

Hope this helps your understanding.

Click to expand...

...IF they are executed at all...