Guidelines to identify and manage tasks
The
Logix Designer
application allows multiple tasks to schedule and prioritize the programs that make up your application. Organizing these tasks well allows the controller to function in a way that makes the most effective use of the available CPU time, and allows the application to run as efficiently as possible. Follow these guidelines to help in designing applications.Identify individual tasks
One of the first steps in designing your application is determining the number of tasks you need to perform the necessary operations. To determine if a specific operation requires a separate task, start by looking for some of the following issues:
If you see this: | Then use this type of task: | With this trigger: |
an operation that must occur at a constant rate (for example, every 100 msec) | periodic | Period (that is, the specified frequency of execution) |
an operation that must occur multiple times within the scan of your other logic | periodic | Period |
input that appears as a very short pulse | event | Module Input Data State Change |
input that requires a high-speed response | event | Module Input Data State Change |
an operation that you must do immediately after each execution of the motion planner | event | Motion Group Execution |
an operation that occurs at a watch point | event | Axis Watch |
an operation that occurs at a registration point | event | Axis Registration 1 or 2 |
data that you transfer via a produced or consumed tag, and you want to guarantee integrity of the data | event | consumed tag |
actions that you must synchronize between several controllers | event | consumed tag |
a condition that can occur in multiple programs, but requires the same response (for example, shutting down the process) | event | EVENT instruction |
Manage multiple tasks
When managing multiple tasks within one application, consider:
Prioritize the tasks
When assigning priority levels to each periodic and event task, keep in mind:
- Higher priority tasks interrupt all lower priority tasks.
- Higher priority tasks can interrupt lower priority tasks multiple times.
- Tasks at the same priority level execute on a time-slice basis, in 1 msec intervals.
- The continuous task runs at the lowest priority level; all other tasks interrupt this task.
Create multiple tasks
Use caution when determining the number to create. Remember that each task potentially takes time away from the other tasks in your application. When there are too many tasks:
- Other tasks may experience overlaps; if a task is interrupted too frequently, or for too long a time interval, the task may not complete its execution before it is triggered again.
- The continuous task may take too long to complete.
Avoid overlaps
An overlap is a condition where a periodic or event task is triggered while the task is still executing from the previous instance of the trigger. If an overlap occurs, the controller disregards the trigger that caused the overlap. In other words, may miss an important execution of the task.
Each task requires a certain amount of time to finish before it is triggered again. Make sure that the scan time of the task is significantly less than the rate at which the trigger for the task occurs. If an overlap occurs, reduce the frequency at which you trigger the task. If the task is periodic, increase its rate. If the task is an event task, adjust the configuration of the system so that it triggers the task less frequently.
In the case of a Safety task, if an overlap is detected, a controller fault occurs.
Account for unscheduled communications
Unscheduled communication occurs only when no periodic or event tasks are running. If using multiple tasks, make sure that their combined scan times and execution intervals leave enough time remaining for unscheduled communication.If using multiple tasks, make sure that:
- The execution time of the highest priority task is significantly less than its update rate.
- The total execution time of all your tasks is significantly less than the update rate of the lowest priority tasks.
Adjust the update rates of your tasks as needed to allow for the best balance between executing your logic and allowing for unscheduled communication.
Confirm controller support for event tasks
Each Logix controller platform supports different types of event tasks that can be used as triggers. Use the following table to determine which event tasks are appropriate for your specific controller.
Controller Platform | Module Input Data State Change | Consumed Tag | Axis Registration 1 or 2 | Axis Watch | Motion Group Execution | EVENT Instruction | Windows Event |
CompactLogix | X | ||||||
ControlLogix | X | X | X | X | X | X |
Each event is made up of a trigger and the defined tag that sets the trigger. The allowable tags vary, depending on the type of tag under which they fall.
Trigger | Tag |
EVENT Instruction only | None required |
Axis Home Axis Watch Axis Registration 1 Axis Registration 2 | AXIS_SERVO, AXIS_SERVO_DRIVE, AXIS_CONSUMED |
Motion Group Execution | MOTION GROUP |
Module Input Data State Change | Only mapped modules with an input connection. |
Consumed Data State Change | Any valid data type that may be consumed. (No mapped modules) |
For more detailed information on planning specific types of event tasks, refer to your
Logix Controllers Common Procedures Manual
, publication 1756-PM001.Provide Feedback