Output input from previous time step
The Memory block holds and delays its input by one integration time step. This block accepts continuous and discrete signals. The block accepts one input and generates one output. Each signal can be scalar or vector. If the input is a vector, the block holds and delays all elements of the vector by the same time step.
You specify the block output for the first time step using the Initial condition parameter. Careful selection of this parameter can minimize unwanted output behavior. However, you cannot specify the sample time. This block's sample time depends on the type of solver used, or you can specify to inherit it. The Inherit sample time parameter determines whether sample time is inherited or based on the solver.
Tip Avoid using the Memory block when both these conditions are true:
When the Memory block inherits a discrete sample time, the block is analogous to the Unit Delay block. However, the Memory block does not support state logging. If logging the final state is necessary, use a Unit Delay block instead.
The Unit Delay, Memory, and Zero-Order Hold blocks provide similar functionality but have different capabilities. Also, the purpose of each block is different. The sections that follow highlight some of these differences.
|Block||Purpose of the Block||Reference Examples|
|Unit Delay||Implement a delay using a discrete sample time that you specify. Ideally, the block accepts and outputs signals with a discrete sample time.|
|Memory||Implement a delay by one integration time step. Ideally, the block accepts continuous (or fixed in minor time step) signals and outputs a signal that is fixed in minor time step.|
|Zero-Order Hold||Convert an input signal with a continuous sample time to an output signal with a discrete sample time.|
|Unit Delay||Memory||Zero-Order Hold|
|Specification of initial condition||Yes||Yes||No, because the block output at time t = 0 must match the input value.|
|Specification of sample time||Yes||No, because the block can only inherit sample time (from the driving block or the solver used for the entire model).||Yes|
|Support for frame-based signals||Yes||No||Yes|
|Support for state logging||Yes||No||No|
When you specify a discrete sample time in the dialog box for a Unit Delay or Zero-Order Hold block, the block output can differ depending on the solver specification for the model.
The Repeating Sequence Stair block uses a continuous sample time of 0 to provide input signals to the Unit Delay and Zero-Order Hold blocks.
If the model uses a fixed-step solver with a step size of 1, the scope shows the following simulation results:
If the model uses a variable-step solver, the scope shows the following simulation results:
The Zero-Order Hold block takes the input value of the Repeating Sequence Stair block at t = 0, 1, 2, ... , 9 and holds each input value for a sample period (1 second). The Unit Delay block applies the same 1-second hold to each input value of the Repeating Sequence Stair block, but also delays each value by a sample period. The Initial conditions parameter specifies the output for the Unit Delay block during the first sample period. For more information about sample time, see What Is Sample Time? and Specify Sample Time.
Solver specification for a model also affects the behavior of the Memory block. For details, see Examples of Memory Block Usage.
The Memory block accepts real or complex signals of any data type that Simulink® supports, including fixed-point and enumerated data types.
For more information, see Data Types Supported by Simulink in the Simulink documentation.
The Main pane of the Memory block dialog box appears as follows:
Specify the output at the initial integration step. This value must be 0 when you do not use a built-in input data type. Simulink does not allow the initial output of this block to be inf or NaN.
Select to inherit the sample time from the driving block:
If the driving block has a discrete sample time, the block inherits the sample time.
If the driving block has a continuous sample time, selecting this checkbox has no effect. The sample time depends on the type of solver used for simulating the model.
When this check box is cleared, the block sample time depends on the type of solver used for simulating the model:
If the solver is a variable-step solver, the block sample time is continuous but fixed in minor time step: [0, 1].
If the solver is a fixed-step solver, the [0, 1] sample time converts to the solver step size after sample-time propagation.
Select to output the input during linearization and trim. This selection sets the block mode to direct feedthrough.
First compile the model using the following command, where model is the name of the Simulink model.
[sizes, x0, x_str] = model(,,,'lincompile');
Next, terminate the compilation with the following command.
The output argument, x_str, which is a cell array of the states in the Simulink model, contains the new state ordering. When passing a vector of states as input to the linmod, dlinmod, or trim functions, the state vector must use this new state ordering.
Select to linearize the Memory block to a unit delay when the Memory block is driven by a signal with a discrete sample time.
The State Attributes pane of the Memory block dialog box appears as follows:
Use this parameter to assign a unique name to the block state. The default is ' '. When this field is blank, no name is assigned. When using this parameter, remember these considerations:
A valid identifier starts with an alphabetic or underscore character, followed by alphanumeric or underscore characters.
The state name applies only to the selected block.
This parameter enables State name must resolve to Simulink signal object when you click Apply.
For more information, see States in the Simulink Coder™ documentation.
Select this check box to require that the state name resolve to a Simulink signal object. This check box is cleared by default.
State name enables this parameter.
Selecting this check box disables Code generation storage class.
Select a package that defines the custom storage class you want to apply. If you have defined any packages of your own, click Refresh. This action adds all user-defined packages on your search path to the package list.
Select custom storage class for state.
Auto is the appropriate storage class for states that you do not need to interface to external code.
model_P initializes the state to its corresponding value in the workspace.
State is stored in a global variable
model_private.h declares the state as an extern variable.
model_private.h declares the state as an extern pointer.
A non-editable placeholder storage class is created.
A struct declaration is created that embeds Boolean data.
Volatile type qualifier is used in state declaration.
Header (.h) file containing global variable declarations is generated with user-specified name.
Predefined header (.h) files containing global variable declarations are included.
A static qualifier is generated in front of the state declaration to make the state visible only to the current file.
A struct declaration is created to encapsulate parameter or signal object data.
Volatile type qualifier is used in struct declaration.
Supports specialized function calls to read and write memory.
State name enables this parameter.
The list of valid storage classes differs based on the Package selection.
Setting this parameter to ExportedGlobal, ImportedExtern, or ImportedExternPointer enables Code generation storage type qualifier.
Specify a Simulink Coder storage type qualifier. The default is ' '. When this field is blank, no qualifier is assigned.
The Simulink Coder product does not check this string for errors. Thus, whatever value you enter appears automatically in the variable declaration.
Setting Code generation storage class to ExportedGlobal, ImportedExtern, or ImportedExternPointer enables this parameter.
During simulation, the block uses the following values:
The initial value of the signal object to which the state name is resolved
Min and Max values of the signal object
See States in the Simulink Coder documentation for more information.
The following modelmodel shows how to display the step size in a simulation. The Sum block subtracts the time at the previous step, which the Memory block generates, from the current time, which the Clock block generates.
Because Inherit sample time is not selected for the Memory block, the block sample time depends on the type of solver for simulating the model. In this case, the model uses a fixed-step solver. Therefore, the sample time of the Memory block is the solver step size, or 1.
If you replace the Memory block with a Unit Delay block, you get the same results. The Unit Delay block inherits a discrete sample time of 1.
The sldemo_bouncesldemo_bounce model shows how a bouncing ball reacts after being tossed into the air. The dx port of the Second-Order Integrator block and the Memory block capture the velocity of the ball just before it hits the ground.
Because Inherit sample time is not selected for the Memory block, the block sample time depends on the type of solver for simulating the model. In this case, the model uses a variable-step (ode23) solver. Therefore, the sample time of the Memory block is continuous but fixed in minor time step: [0, 1]. When you run the model, you get the following results:
If you replace the Memory block with a Unit Delay block, you get the same results. However, a warning also appears due to the discrete Unit Delay block inheriting a continuous sample time.
The sldemo_clutchsldemo_clutch model shows how you can use the Memory block with the Combinatorial Logic block to implement a finite-state machine. This construct appears in the Friction Mode Logic/Lockup FSM subsystem.
Because Inherit sample time is not selected for the Memory block, the block sample time depends on the type of solver for simulating the model. In this case, the model uses a variable-step (ode23) solver. Therefore, the sample time of the Memory block is continuous but fixed in minor time step: [0, 1].
The Memory block is a bus-capable block. The input can be a virtual or nonvirtual bus signal subject to the following restrictions:
Initial condition must be zero, a nonzero scalar, or a finite numeric structure.
If Initial condition is zero or a structure, and you specify a State name, the input cannot be a virtual bus.
If Initial condition is a nonzero scalar, you cannot specify a State name.
For information about specifying an initial condition structure, see Specify Initial Conditions for Bus Signals.
All signals in a nonvirtual bus input to a Memory block must have the same sample time, even if the elements of the associated bus object specify inherited sample times. You can use a Rate Transition block to change the sample time of an individual signal, or of all signals in a bus. See Nonvirtual Bus Sample Times and Bus-Capable Blocks for more information.
You can use an array of buses as an input signal to a Memory block. Only the Initial condition parameter (which may be, but does not have to be, a structure) is scalar-expanded to match the dimensions of the array of buses. For details about defining and using an array of buses, see Combine Buses into an Array of Buses.
|Bus-capable||Yes, with restrictions as noted above|
|Direct Feedthrough||No, except when you select Direct feedthrough of input during linearization|
|Sample Time||Depends on the type of solver used. If you select the Inherit sample time check box, the block inherits sample time from the driving block.|
|Scalar Expansion||Yes, of the Initial condition parameter|