Understanding and Working with Tasks in RSLogix/Studio 5000

Introduction

When writing code for fast automation processes, such as in the FMCG (Fast Moving Consumer Goods) sector, the processing speed of PLC logic can sometimes have significant implications. 

Given the advancements of PLCs these days with multicore processors, we can improve our scan times and, therefore, process information much more quickly. 

An example of this might be accurately timing a process such as an indexing table with a dwell flag but no stop flag. For example, a traditional setup might include both flags as inputs to the PLC. As the indexing table rotates, it moves off of the dwell flag. At a certain point, fixed to the spindle of the indexer sits a stop flag. When the table rotates to this flag, it will command the PLC to stop and decelerate the table allowing it to come to rest on the dwell flag again.

So imagine there is no stop flag. Another way to achieve the same result is to start indexing the table. At the falling edge of the dwell flag, a timer could be started, and once the timer has expired, a virtual stop command can be sent to the PLC to stop and decelerate the table, allowing it to come to rest on the dwell flag.

Imagine using the main PLC task with various processes and calculations. For example, one scan to the next could be longer or shorter than the last. This would mean that our indexing table might stop short or overshoot our dwell flag. This could be detrimental to our machine.

One way to overcome this issue is using a different task type. Which type of task would be best suited to our indexing table example? That’s what we’re going to look at in this tutorial.

Understanding Continuous Tasks in RSLogix 5000

In RSLogix 5000, logic is executed based on tasks and events. A project will, by default, contain a continuous task running in the background. Therefore, any CPU time not allocated to other operations, such as motion or communication, will be used to process the programs within the continuous task. In the continuous task, all logic within a PLC is executed in order, rung by rung. As soon as it completes executing all the code in the PLC, it restarts immediately from the beginning. Although a continuous task is not required to process program logic, there can only be one configured.

Understanding Periodic Task in RSLogix 5000

A periodic task is a little different. While logic is still executed in order, the periodic task logic is executed at a specific time interval and will interrupt any lower-priority tasks and execute once. When the periodic task has completed its scan, the previous task will continue from where it left off. A periodic task time period can be between 0.1 milliseconds and 2000 seconds, with the default value being 10 milliseconds.

Understanding Event Tasks in RSLogix 5000

An event task will perform a function when a specific event or trigger occurs, meaning it is not continuously operating. As soon as a trigger is received, the event task will be executed immediately, interrupting any lower-priority tasks. Once again, like the periodic task, it will be executed only once, at which point the previous task will continue from where it left off.

Before trying to use specific triggers, it's best to check whether they are supported by the controller you will be using, as some Logix 5000 controllers do not support all triggers.

An event-driven task can be triggered by many things, for example;

• An Axis Watch or Axis Registration
• Motion or a motion Group Execution
• An EVENT instruction
• A digital input
• A Consumed tag

A Produced tag is a tag that a controller makes available for use by other controllers. Multiple controllers can simultaneously consume (receive) the data. A produced tag sends its data to one or more consumed tags (consumers) without using logic.

A Consumed tag is a tag that receives the data of a produced tag. The data type of the consumed tag must match the data type (including any array dimensions) of the produced tag. The RPI of the consumed tag determines the period at which the data updates.

Creating Tasks and Setting Times in RSLogix 5000

Regardless of which task type is best for your application, the most important thing to remember is to ensure that the selected time period does not exceed the sum of all the execution times of ALL programs assigned to a particular task. If you’re working with multiple periodic tasks, ensuring sufficient time for the CPU to handle the task interruption is essential. If the controller detects a periodic task trigger for a task already operating, a minor PLC fault occurs.

In ControlLogix and CompactLogix PLCs, up to 32 tasks can be created, of which one can be a continuous task if desired. There are 15 configurable priority levels for periodic and event tasks ranging from priority 1 (the highest priority) to 15 (the lowest priority).

When creating a new project, the MainTask is already defined as a continuous task. When creating a Safety controller project, the Logix Designer programming application creates the SafetyTask, with a Safety program and a main Safety routine. The SafetyTask is created as a periodic task, and this cannot be changed.

The SafetyTask time period is limited to a maximum of 500 milliseconds and, unlike the MainTask time period, cannot be modified online. Care must be taken to ensure that the SafetyTask has enough time to finish before it is triggered again. If it does not, a Safety Task Watchdog Timeout will occur, which is a non-recoverable safety fault in the GuardLogix controller.

The Safety Task Period and Safety Task Watchdog affect the system reaction time. The GuardLogix Controller Systems Safety Reference Manual, publication 1756-RM093 provides detailed information on calculating system reaction time.

To add a new task to a project, right-click the Tasks folder tree in the Controller Organizer. This will bring up a sub-menu where you can select “New Task…”. Selecting this will bring up the New Task pop-up.

We are able to give the task a name description and select which type of task we want to create. The function and the setting of the Watchdog timer is detailed later in this tutorial.

Monitoring Task Performance in RSLogix 5000

In RSLogix 5000, we can monitor the performance of any given task by selecting the properties of the task by right-clicking on it or highlighting it and pressing Alt+Enter.

A window will pop up where we can select the Monitor tab;

When online with a PLC, we can view the Maximum and Current PLC Scan times and the Maximum and Minimum Interval times, or the time between each trigger. We can also determine whether we have any task overlaps, where the task is triggered to be executed before it has completed its last complete execution cycle.

From the image below, we can see that the 10 millisecond period assigned to the MainTask on this project is too fast as the scan time is 21 milliseconds and the interval between triggers is between 19.4 milliseconds and 30.5 milliseconds. This means that the periodic task is being triggered to run and triggered a further 2-3 times before the first operation has completed executing fully. 

If an overlap occurs, the PLC Controller disregards the trigger that caused the overlap so that you may miss a vital program execution. The Minor Fault bit will be set in the PLC to warn of the overlap, but the controller will still function less efficiently. Therefore it is essential to set your task execution times correctly to avoid overlaps.

Task Watchdog in RSLogix 5000

We can adjust the time of the task trigger, but we can also adjust the Watchdog timer. Each task contains a Watchdog timer to monitor the duration of the task. If the Watchdog timer expires, then a major fault will be triggered. Depending on the controller's fault handling routine, this may result in the controller shutting down and affecting the process the PLC is handling.

The Watchdog time can range from 1 millisecond to 2000 seconds, the default is 500 milliseconds. It begins to run when the task is triggered and stops when all routines have been executed.

The controller fault handler can be used to clear a watchdog fault. If the same watchdog fault occurs a second time during the same logic scan, the controller enters Faulted mode, regardless of whether the controller fault handler clears the watchdog fault.

Conclusion

In this tutorial, we learned that there are different types of tasks in Allen Bradley PLCs that are used to execute the logic. We have the Continuous Task, which is responsible for executing all the logic from top to bottom. They can take time to execute entirely, but once it has processed all the logic, it will immediately restart from the top again.

Then we have Periodic Tasks. These types of tasks are used when time is of the essence. They are triggered periodically and can to set to a time frame of between 0.1 milliseconds and 2000 seconds. This allows for a great deal of flexibility. They can be used in high-accuracy applications and much slower processes, safe in the knowledge that they will be executed consistently.

The final type of task we have looked at is the Event Task. It is triggered by an external source, possibly from some I/O or a sequence. They are useful in applications that were constantly scanning the logic would cause a slowdown of other processes. Triggering it only when it is required can save valuable PLC performance.

After delving into the different types of tasks, we looked at additional considerations such as setting an appropriate time frame for the task to run as well as monitoring the performance of a task. Finally, we looked at what happens if we don’t set the time frames correctly. Minor Faults can occur when the task time is set too short, and the PLC reports an overlap. This is when the task is retriggered before the current trigger has been completed. A Major Fault can occur when the Task Watchdog timer Watchdog fault occurs twice during the same logic scan.

Cast your mind back to the beginning of this tutorial, where we asked a question as to which type of task would be best suited to an indexing table with a dwell flag but no stop flag. The answer ultimately depends on the hardware you’re working with, the required speed of operation, and the accuracy required, but for an application such as this, using a periodic task would give an accurate time provided that the task duration is set so that it does not have overlapping triggers. 

That is all for this tutorial; remember, timing is everything!