System Overhead Time Slice (SOTS)

I thought I would do a piece on the System Overhead Time Slice setting you will find in pre- L8 (5580) Allen Bradely ControlLogix and CompactLogix platform of controllers. As the complexity and connectivity of modern automation systems get more complex requiring high-performance communications, I/O, and motion control , careful consideration must be taken to ensure that both user-defined and back-end system tasks are optimized to mitigate the likelihood of CPU starvation.

I recently had a service call to a customer who had just launched a new program that required two integrated robotic cells to build out their product line. While both cells were symptomatic of the same CPU utilization type problems, I focused first on the larger of the two cells. A broad overview of the Ethernet/IP controls network is as follows:

1 x CompactLogix 5370 Safety Controller
12 x Allen Bradley 5700 Servo Drive units
1 x 1734 Point Guard I/O rack
5 x ABB IRC5 Robot Controllers
1 x NTRON 16 port unmanaged switch
1 x Proface HMI
1 x RFID reader
1 x Bar Code Scanner

The Problem

Now that we have a general understanding of the complexity of the Ethernet/IP network in place let’s focus in on the problem that was presenting itself and then see how the System Overhead Time Slice setting corrected the problem.

The customer indicated that they were having intermittent servo motor issues stopping arbitrarily mid-cycle. Upon further investigation into the axis fault logs I saw several “Module Connection Faults” followed immediately by a “Control Sync Fault”. Both faults were appearing on all axes so immediately I suspected a network management problem due to the volume of Ethernet/IP network traffic and the deployment of an Unmanaged Ethernet Switch.

The Solution

My first thought was the Unmanaged Ethernet Switch was going to have to be switched out for a Managed Ethernet Switch so that the network traffic could be efficiently optimized through the use of VLAN’s and VLAN routing. Of course, the time needed to procure the managed switch was not an immediate option and the complexity that is inherent when moving from an unmanaged to a managed switch was not something the internal engineering personnel nor machine builder was comfortable with. That said, a Skorpian IP Router was used to segregate the cell network from the rest of the plant network so I could be certain that the only network traffic in the cell was localized at the cell level.

My next thought was to look at the System Overhead Time Slice (SOTS) setting. My thought here was to see how much of the overall CPU time was allocated to service some of the back-end system tasks such as communications. This setting can be found under Controller Properties –> Advanced tab as depicted below.

By increasing this time slice you can effectively increase the amount of time the CPU is allocated to services back-end system tasks such as communications.

Ultimately, by incrementing this setting to 35% I was able to eliminate the Module Connection and and Control Sync faults, however, there is a trade-off in that your Continuous Task scan will increase, which could in itself create a whole host of other problems.

Fortunately, this wasn’t the case in my circumstance, however, if increased scan were to create user program issues, my next step would have been to look closely at Continuous Task structure, i.e., removing non-critical pieces of code or programs that really don’t need to be in there (meaning they don’t need to be constantly scanned) and broken out into event-driven or periodic type tasks to reduce scan time.

Okay, so this turned out to be a network/CPU optimization type problem, however, I don’t think we’ve painted a detailed enough picture of what the SOTS actually is and does.

System Overhead Time Slice (SOTS) – A Closer Look

As previously mentioned the System Overhead Time Slice (SOTS) is a setting that allows you to control the amount of processor CPU time allocated to background tasks, such as communications, Trends, MSG instruction traffic, serial port communications, Connection Manager operations, upload/download and online edits. Changing the time slice can have some complex effects on your system, depending on the overall makeup of the tasks in your processor. It’s hard to describe the effects the System Overhead Time Slice will have on a given application, so some scenarios below illustrate the principles by example.

We will consider three kinds of tasks: continuous, periodic and motion. Event based tasks (available in RSLogix 5000 v12 and higher – see our Mastering ControlLogix video series here) are beyond the scope of this article. If you are using event based tasks, they will change the operation by interrupting the current task in a manner that depends on the relative priority of the current and event based task.

Please note, that most of the information contained here pertaining to the System Overhead Time Slice has been taken either directly or in part from Rockwell Automation’s Logix5000 Controllers Design Consideration user manual. The time slice is the ratio of the amount of time spent running the continuous task versus the amount of time running the background task. The time slice is based on a 1 ms tick of time for the background task. The formula used for calculating the time slice is,, which means that, ,where TS% is the time slice in percent, and CT is the amount of time spent running the continuous task. Note this is not the Continuous task individual scan time. Many scans of the continuous task may occur during this time, or only a partial scan of the task may occur. It is simply the amount of time spent executing the continuous task. Since the time allocated to running the background task is fixed at 1 ms, the processor adjusts the continuous task’s time to meet the time slice constraint.

Therefore, if the time slice is 10%, then CT is 9 ms. If the time slice is set to 20%, then CT is 4 ms. Note that the numerator in the TS% formula is the background task time (fixed at 1 ms, remember).

Example 1:

The project consists of just one continuous task. There are no periodic tasks or motion. TS is set to the default of 10%.

The continuous task executes for 9 of every 10 ms, and the background task executes every 10 ms.

Example 2:

The project consists of just one continuous task. There are no periodic tasks or motion. TS is set to 20%.

The continuous task executes for 4 of every 5 ms, and the background task executes every 5 ms.

So far, the examples have just one continuous task and no motion, so the breakup of the processor time is simple and straightforward. Now, let’s complicate the situation and see what happens when we add a periodic task.

Example 3:

The project consists of one continuous task and a periodic task with an interval of 2 ms, and a scan time of 1 ms. TS is set to 10%.

The numbers in the continuous task line are the accumulated processor time for the continuous task at the end of the tick.

Both the continuous and background tasks are interrupted by the periodic task. The TS setting still means that the continuous task has to run for a certain number of ms before the background task can run. So, here, the background task doesn’t get run until almost 20 ms have elapsed overall and every 20 ms after that, but that is still after just 9 ms of continuous task execution, given the 10% TS setting. Remember that the TS% is a ratio between the continuous task and background task running times, not between the absolute system time and the background task time. Therefore, as the continuous task gets interrupted by periodic tasks, the time between background task updates will increase.

The final kind of task that we will consider is the motion task. It has the highest priority, so it will interrupt periodic, continuous and background tasks. The period at which the motion task runs is governed by the coarse update rate (CUR). As a rule of thumb, assume about ½ ms per axis for the actual calculations. Let’s see how it affects the previous setup.

Example 4:

The project consists of one continuous task and a periodic task with an interval of 2 ms, and a scan time of 1 ms. TS is set to 10%.

There are 5 axes of motion, with a CUR of 5 ms, and about 2.5 ms of calculation time (½ ms per axis * 5 axes).

The periodic task set to run at 2 ms was delayed by 0.5 ms due to the motion task running.
The periodic task set to run at 6 ms was delayed by 1.5 ms due to the motion task running. This caused the task to overlap with the 8 ms start of the next occurrence. An overlap error will be generated and the 8 ms occurrence will be missed.
The periodic task set to run at 10 ms was delayed by 2.5 ms due to the motion task running. This caused the start of the task to overlap with the 12 ms start of the next occurrence. An overlap error will be generated and the 10 ms occurrence will be missed. The task set to run at 12 ms is delayed by 0.5 ms due to the motion task running.

With motion added, by the end of our sample 20 ms run, the continuous task has only accumulated 4 ms of run time, and the background task has not run at all! Extrapolating, it will take about 45 ms before the background task gets to run.

Another thing to note is that the 2 ms task does not actually run at 2 ms intervals. In some cases it gets delayed, and in other cases it does not run at all due to an overlap condition with the previous interval.

You can see that the makeup of the project affects the rate at which various tasks are executed. From these effects, we can form a couple of helpful rules of thumb regarding project configuration:

Rule 1:

Don’t put high speed discrete I/O and motion in the same processor, unless you carefully consider the effects of motion on the actual scan rate of your logic.

Rule 2:

Be careful to set the time slice, given the makeup of your other tasks and motion, such that the background task can get executed at a rate that your overall application can tolerate. By starving the background task, you can severely slow down activities like implicit and explicit communications, message traffic, uploads/downloads and serial port communications.

Exclusive Offer!

Wondering how you can pass data to-from two different ControlLogix controllers? If so, check out our Producer-Consumer Messaging eLab that will walk you through how to perform both Implicit and Explicit data exchange between two ControlLogix controllers.

Conclusion

I certainly hope you’ve enjoyed this article and I do encourage you to become a member of our growing community of professional engineers, technicians and technologists, Register Here!

Also, check out our YouTube Channel to see some great videos…and don’t forget to like and subscribe to our channel!

If you enjoyed this article be sure to check out some of these good reads too:

Lastly, if you run into any problems in your day-to-day engineering activities please be sure to check out our Live and Interactive PLC Forum!

And if you so desire, assist other community members by replying or offering helpful information to the questions or challenges they may be facing right now!