Sometimes a real-time application running on the target computer does not have enough time to complete processing before the next time step. This condition is called a CPU overload. An overload is registered every time an execution step cannot be executed because a previous step is running.
For example, assume that your model sample time is
but running a particular model step takes
This model step causes the kernel to skip three steps and causes three
Real-Time™ kernel halts model execution when it encounters a CPU overload.
However, some real-time applications can tolerate several CPU overloads without
significant loss of data, for example during start up. For such applications, you can
allow a specified number and configuration of CPU overloads. You do this using the
Allowing the target computer CPU to overload can cause incorrect results, especially for multirate models. Use these TLC command-line options only for diagnosis. When your diagnosis is complete, turn off these options.
If your real-time application causes a CPU overload, it finishes
the current execution step and ignores timer interrupts. At the end
of the execution step, the kernel compares the CPU overload count
to the limits defined by
If the count does not exceed the limits, the application executes
at the next step. Otherwise it stops.
The limits are:
xPCMaxOverloads — Number
of acceptable overloads during a real-time application execution.
xPCMaxOverloads is set to a value, the Simulink
Real-Time software stops execution with a CPU overload at the next overload within the same application execution. For example, if
xPCMaxOverloads is set to
3, the software stops with a CPU overload at the fourth overload in the same application execution.
The default value of
0 means that overloads are registered on the first overload.
xPCMaxOverloadLen — Number
of acceptable overloads, in units of sample time, within the same
xPCMaxOverloadLen is set to a value, the software stops execution with a CPU overload at the next overload within the same execution step. For example, if
xPCMaxOverloadLen is set to
2, the software stops execution with a CPU overload at the third overload within the same execution step.
The default value of
0 means that overloads are registered on the first overload within the same execution step.
Specify a value that is less than or equal to the value for
xPCMaxOverload is set to a value, for example
xPCMaxOverloadLen is not defined, the real-time application stops if one of following occurs:
The cumulative overloads since execution start is greater than
One execution step has two overloads.
xPCStartupFlag — Number
of executions of the model at start up.
xPCStartupFlag temporarily disables CPU overload checking during the first few model execution steps. After the model finishes the first
xPCStartupFlag steps, the software reenables CPU overload checking, which takes effect for the next execution of the model.
The default value of
1 means that overloads are ignored on the first step. If
xPCMaxOverloadLen are not set, their default setting determines the software response to overloads.
count overloads, but over different time spans.
the CPU overloads that were seen so far in the real-time application
xPCMaxOverloadLen counts the overloads
that were seen within one execution step.
The three options interact. When the
Real-Time kernel runs
the model, it compares the number of CPU overloads to the values of
When the number of CPU overloads reaches the lower of these two values,
the kernel stops executing the model.
Suppose that you enter the following
TLCOptions settings for model
set_param('xpcosc','TLCOptions','-axPCMaxOverloads=30 -axPCOverLoadLen=2 -axPCStartupFlag=5')
With these settings, the software ignores CPU overloads for
the first five iterations through the model. After the first five
iterations, the software allows up to
30 CPU overloads,
allowing at most two CPU overloads per model step.
You can use the blocks Set Overload Counter and Get Overload Counter to set and track CPU overload numbers. You can use the Time Stamp Counter block to profile your model
The software tolerates the first three overloads and stops executing
at the fourth. The number of overloads exceeds the maximum number
allowed for real-time execution.
The software tolerates the first two overloads and stops executing
at the third. The second step execution is longer than the maximum
allowed overload length of one sample time.
The kernel ignores CPU overloads for the first three time steps and
stops executing on the first overload in the next time step.