|On this page…|
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 0 in the Sample time field of the block dialog.
If the sample time of a block is set to [0, 1], 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 major steps.
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 0 (continuous). 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 –1, 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.)
All inherited blocks are subject to the process of sample time propagation, as discussed in How Propagation Affects Inherited Sample Times
Specifying a constant (Inf) sample time is a request for an optimization for which the block executes only once during model initialization. Simulink honors such requests if all of the following conditions hold:
The Inline parameters check box is selected on the Configuration Parameters dialog box Optimization > Signal and Parameters pane (see the Optimization Pane: Signals and Parameters).
The block has no continuous or discrete states.
The block allows for a constant sample time.
The block does not drive an output port of a conditionally executed subsystem (see Create an Enabled Subsystem).
The block has no tunable parameters.
One exception is an empty subsystem. A subsystem that has no blocks—not even an input or output block—always has a constant sample time regardless of the status of the conditions listed above.
This optimization process speeds up the simulation by eliminating the need to recompute the block output at each step. Instead, during each model update, Simulink first establishes the constant sample time of the block and then computes the initial values of its output ports. Simulink then uses these values, without performing any additional computations, whenever it needs the outputs of the block.
Note: The Simulink block library includes several blocks, such as the MATLAB S-Function block, the Level-2 MATLAB S-Function block, and the Model block, whose ports can produce outputs at different sample rates. It is possible for some of the ports of such blocks to have a constant sample time. These ports produce outputs only once—at the beginning of a simulation. Any other ports produce output at their respective sample times.
If Simulink cannot honor the request to use the optimization, then Simulink treats the block as if it had specified an inherited sample time (–1 ).
One specific case for which Simulink rejects the request is when parameters are tunable. By definition, you can change the parameter values of a block having tunable parameters; therefore, the block outputs are variable rather than constant. For such cases, Simulink performs sample time propagation (see How Propagation Affects Inherited Sample Times) to determine the block sample time.
An example of a Constant block with tunable parameters is shown below (ex_inline_parameters_offex_inline_parameters_off). Since the Inline parameters option is disabled, the Constant value parameter is tunable and the sample time cannot be constant, even if it is set to Inf. To ensure accurate simulation results, Simulink treats the sample time of the Constant block as inherited and uses sample time propagation to calculate the sample time. The Discrete-Time Integrator block is the first block, downstream of the Constant block, which does not inherit its sample time. The Constant block, therefore, inherits the sample time of 1 from the Integrator block via backpropagation.
Blocks that use a variable sample time have an implicit SampleTime parameter that the block specifies; the block tells Simulink when to run it. The compiled sample time is [–2, Tvo] where Tvo is a unique variable offset.
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 have either a triggered or a constant 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 Handle 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.