The System Overhead Time Slice

The System Overhead Time Slice (time slice) is a setting that allows you to control the amount of
processor CPU time allocated to background tasks, such as HMI 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. Its hard to describe the effects just in words, so some
scenarios below illustrate the principles by example.
We will consider three kinds of tasks in this document: continuous, periodic and motion. Event based
tasks (available in RSLogix 5000 v12 and higher) are beyond the scope of this document. 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.
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

1
100 , which means that
CT
1

task. The formula used for calculating the time slice is TS %

100
1 , where TS% is the time slice in per cent, and CT is the amount of time spent running
TS %

CT

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 tasks 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%.
Continuous
Task

CT

CT

Background
Task

BT

BT

10

11

12

13

14

15

16

17

18

19

20

Time (ms)

Figure 1

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%.
Continuous
Task

CT

CT

Background
Task

CT

BT

CT

BT

BT

10

11

12

13

14

BT

15

16

17

18

19

20

Time (ms)

Figure 2

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, lets 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%.
Continuous
Task

Background
Task

BT

Periodic
Task

PT

PT

PT

PT

PT

10

PT

11

12

PT

13

14

PT

15

16

PT

17

18

19

20

Time (ms)

Figure 3

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 doesnt 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
2

governed by the coarse update rate (CUR). As a rule of thumb, assume about ms per axis for the
actual calculations. Lets 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).
CT

Background
Task

Periodic
Task

MT

MT

10

11

PT

PT

PT

MT

MT

CT

PT

PT

PT

Motion
Task

CT

CT

Continuous
Task

12 13

14

15

16

17

18

19

20

Time (ms)

Figure 4
1

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:
Dont 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.
3

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 message traffic,
uploads/downloads and serial port communications.
NOTE:
If there is no continuous task, the time slice setting has no effect. All processor time not used for
other tasks will be used for background operations.