Given a block with a discrete sample time, Simulink® executes the block output or update method at times
where the sample time period is always greater than zero and less than the simulation time, . The number of periods () is an integer that must satisfy:
As simulation progresses, Simulink computes block outputs only once at each of these fixed time intervals of . These simulation times, at which Simulink executes the output method of a block for a given sample time, are referred to as sample time hits. Discrete sample times are the only type for which sample time hits are known a priori.
If you need to delay the initial sample hit time, you can define an offset, .
The Unit Delay block is an example of a block with a discrete sample time.
Unlike the discrete sample time, continuous sample hit times are divided into major time steps and minor time steps, where the minor steps represent subdivisions of the major steps (see Minor Time Steps). The ODE solver you choose integrates all continuous states from the simulation start time to a given major or minor time step. The solver determines the times of the minor steps and uses the results at the minor time steps to improve the accuracy of the results at the major time steps. However, you see the block output only at the major time steps.
To specify that a block, such as the Derivative block,
is continuous, enter
[0, 0] or
the Sample time field of the block dialog.
If the sample time of a block is set to [
the block becomes fixed-in-minor-step. For this
setting, Simulink does not execute the block at the minor time
steps; updates occur only at the major time steps. This process eliminates
unnecessary computations of blocks whose output cannot change between
While you can explicitly set a block to be fixed-in-minor-step,
more typically Simulink sets this condition as either an inherited
sample time or as an alteration to a user specification of
This setting is equivalent to, and therefore converted to, the fastest
discrete rate when you use a fixed-step solver.
If a block sample time is set to
[–1, 0] or
the sample time is inherited and Simulink determines
the best sample time for the block based on the block context within
the model. Simulink performs this task during the compilation
stage; the original inherited setting never appears in a compiled
model. Therefore, you never see inherited ([–1, 0]) in the
Sample Time Legend. (See View Sample Time Information.)
There are some blocks in which the sample time is inherited (-1) by default. For these blocks, the parameter is not visible on the block dialog box unless it is set to a noninherited value. Examples of these blocks include the Gain and Rounding Function blocks. As a good modeling practice, do not change the Sample time parameter for these blocks. For more information, see Blocks for Which Sample Time Is Not Recommended.
All inherited blocks are subject to the process of sample time propagation, as discussed in How Propagation Affects Inherited Sample Times
In Simulink, a constant is a symbolic name or expression whose value you can change only outside the algorithm or through supervisory control. Blocks, like the constant block, whose outputs do not change during normal execution of the model, are always considered to be constant.
Simulink assigns constant sample time to these blocks. They run their block output method:
At the start of a simulation.
In response to runtime changes in the environment, such as tuning a parameter.
For constant sample time, the block sample time assignment
For a block to allow constant sample time, these conditions hold:
The block has no continuous or discrete states.
The block does not drive an output port of a conditionally executed subsystem (see Create an Enabled Subsystem).
The Simulink block library includes several blocks, such as the MATLAB S-Function block, the Level-2 MATLAB S-Function block, and the C S-Function block, whose ports can produce outputs at different sample rates. It is possible for some of the ports of these blocks to have a constant sample time.
Blocks that use a variable sample time have an implicit
that the block specifies; the block tells Simulink when to run
it. The compiled sample time is [–2,
is a unique variable
The Pulse Generator block is an example of a block that has a variable sample time. Since Simulink supports variable sample times for variable-step solvers only, the Pulse Generator block specifies a discrete sample time if you use a fixed-step solver.
To learn how to write your own block that uses a variable sample time, see C MEX S-Function Examples.
If a block is inside of a triggered-type (e.g., function-call, enabled and triggered, or iterator) subsystem, the block may be constant or have a triggered sample time. You cannot specify the triggered sample time type explicitly. However, to achieve a triggered type during compilation, you must set the block sample time to inherited (–1). Simulink then determines the specific times at which the block computes its output during simulation. One exception is if the subsystem is an asynchronous function call, as discussed in the following section.
An asynchronous sample time is similar to a triggered sample time. In both cases, it is necessary to specify an inherited sample time because the Simulink engine does not regularly execute the block. Instead, a run-time condition determines when the block executes. For the case of an asynchronous sample time, an S-function makes an asynchronous function call.
The differences between these sample time types are:
Only a function-call subsystem can have an asynchronous sample time. (See Create a Function-Call Subsystem.)
The source of the function-call signal is an S-function having the option SS_OPTION_ASYNCHRONOUS.
The asynchronous sample time can also occur when a virtual block is connected to an asynchronous S-function or an asynchronous function-call subsystem.
The asynchronous sample time is important to certain code-generation applications. (See Asynchronous Events.)
The sample time is .
For an explanation of how to use blocks to model and generate code for asynchronous event handling, see Rate Transitions and Asynchronous Blocks.