| Products & Services | Solutions | Academia | Support | User Community | Company |
| Download Product Updates | | | Get Pricing | | | Trial Software |
| Documentation → Simulink |
| Contents | Index |
| Learn more about Simulink |

Specify what diagnostic action Simulink software should take, if any, when it detects a condition that could compromise the integrity of data defined by the model, as well as the Data Validity parameters that pertain to code generation, and are used to debug a model.
Set the parameters displayed.
The options are typically to do nothing or to display a warning or an error message.
A warning does not terminate a simulation, but an error does.
Select how Simulink software resolves signals to Simulink.Signal objects. See Explicit and Implicit Symbol Resolution for more information.
Default: Explicit only
Do not perform implicit signal resolution. Only explicitly specified signal resolution occurs. This is the recommended setting.
Perform implicit signal resolution wherever possible, without posting any warnings about the implicit resolutions.
Perform implicit signal resolution wherever possible, posting a warning of each implicit resolution that occurs.
Use the Signal Properties dialog box (see Signal Properties Dialog Box) to specify explicit resolution for signals.
Use the State Attributes pane on dialog boxes of blocks that have discrete states, e.g., the Discrete-Time Integrator block, to specify explicit resolution for discrete states.
Multiple signals can resolve to the same signal object and have the properties that the object specifies.
The MathWorks discourages using implicit signal resolution except for fast prototyping, because implicit resolution slows performance, complicates model validation, and can have nondeterministic effects.
Simulink software provides the disableimplicitsignalresolution function, which you can use to change settings throughout a model so that it does not use implicit signal resolution.
| Parameter: SignalResolutionControl |
| Type: string |
| Value: 'UseLocalSettings' | 'TryResolveAll' | 'TryResolveAllWithWarning' |
| Default: 'UseLocalSettings' |
| Application | Setting |
|---|---|
| Debugging | No impact |
| Traceability | No impact |
| Efficiency | No impact |
| Safety precaution | Explicit only |
Discrete-Time Integrator block
Select the diagnostic action to take if the Product block detects a singular matrix while inverting one of its inputs in matrix multiplication mode.
Default: none
Simulink software takes no action.
Simulink software displays a warning.
Simulink software terminates the simulation and displays an error message.
| Parameter: CheckMatrixSingularityMsg |
| Type: string |
| Value: 'none' | 'warning' | 'error' |
| Default: 'none' |
| Application | Setting |
|---|---|
| Debugging | No impact |
| Traceability | No impact |
| Efficiency | No impact |
| Safety precaution | error |
Product block
Select the diagnostic action to take if Simulink software could not infer the data type of a signal during data type propagation.
Default: none
Simulink software takes no action.
Simulink software displays a warning.
Simulink software terminates the simulation and displays an error message.
| Parameter: UnderSpecifiedDataTypeMsg |
| Type: string |
| Value: 'none' | 'warning' | 'error' |
| Default: 'none' |
| Application | Setting |
|---|---|
| Debugging | No impact |
| Traceability | No impact |
| Efficiency | No impact |
| Safety precaution | error |
Select the diagnostic action to take when signals exceed specified minimum or maximum values.
Default: none
Simulink software takes no action.
Simulink software displays a warning.
Simulink software terminates the simulation and displays an error message.
Use a block's Output minimum or Minimum parameter to specify the minimum value that the block should output.
Use a block's Output maximum or Maximum parameter to specify the maximum value that the block should output.
Enable this diagnostic to check whether block outputs exceed the minimum or maximum values that you specified.
When Simulation range checking is enabled, Simulink software performs signal range checking at every time step during a simulation. Setting this diagnostic to warning or error can cause a decrease in simulation performance.
| Parameter: SignalRangeChecking |
| Type: string |
| Value: 'none' | 'warning' | 'error' |
| Default: 'none' |
| Application | Setting |
|---|---|
| Debugging | warning or error |
| Traceability | warning or error |
| Efficiency | none |
| Safety precaution | error |
Select the diagnostic action to take if the value of a signal or parameter is too large to be represented by the signal or parameter's data type.
Default: warning
Simulink software takes no action.
Simulink software displays a warning.
Simulink software terminates the simulation and displays an error message.
This diagnostic applies only to overflows for integer and fixed-point data types.
To check for floating-point overflows (e.g., Inf or NaN) for double or single data types, select the Inf or NaN block output diagnostic. (See Inf or NaN block output for more information.)
| Parameter: IntegerOverflowMsg |
| Type: string |
| Value: 'none' | 'warning' | 'error' |
| Default: 'warning' |
| Application | Setting |
|---|---|
| Debugging | No impact |
| Traceability | No impact |
| Efficiency | No impact |
| Safety precaution | error |
Select the diagnostic action to take if the value of a block output is Inf or NaN at the current time step.
Default: none
Simulink software takes no action.
Simulink software displays a warning.
Simulink software terminates the simulation and displays an error message.
This diagnostic applies only to floating-point overflows for double or single data types.
To check for integer and fixed-point overflows, select the Detect overflow diagnostic. (See Detect overflow for more information.)
| Parameter: SignalInfNanChecking |
| Type: string |
| Value: 'none' | 'warning' | 'error' |
| Default: 'none' |
| Application | Setting |
|---|---|
| Debugging | No impact |
| Traceability | No impact |
| Efficiency | No impact |
| Safety precaution | error |
Select the diagnostic action to take during code generation if a Simulink object name (the name of a parameter, block, or signal) begins with rt.
Default: error
Simulink software takes no action.
Simulink software displays a warning.
Simulink software terminates the simulation and displays an error message.
The default setting (error) causes code generation to terminate with an error if it encounters a Simulink object name (parameter, block, or signal), that begins with rt.
This is intended to prevent inadvertent clashes with generated identifiers whose names begins with rt.
| Parameter: RTPrefix |
| Type: string |
| Value: 'none' | 'warning' | 'error' |
| Default: 'error' |
| Application | Setting |
|---|---|
| Debugging | No impact |
| Traceability | No impact |
| Efficiency | No impact |
| Safety precaution | error |
Select the diagnostic action to take when a parameter downcast occurs during simulation.
Default: error
Simulink software takes no action.
Simulink software displays a warning.
Simulink software terminates the simulation and displays an error message.
A parameter downcast occurs if the computation of block output required converting the parameter's specified type to a type having a smaller range of values (for example, from uint32 to uint8).
This diagnostic applies only to named tunable parameters.
| Parameter: ParameterDowncastMsg |
| Type: string |
| Value: 'none' | 'warning' | 'error' |
| Default: 'error' |
| Application | Setting |
|---|---|
| Debugging | No impact |
| Traceability | No impact |
| Efficiency | No impact |
| Safety precaution | error |
Select the diagnostic action to take if a parameter overflow occurs during simulation.
Default: error
Simulink software takes no action.
Simulink software displays a warning.
Simulink software terminates the simulation and displays an error message.
A parameter overflow occurs if Simulink software encounters a parameter whose data type's range is not large enough to accommodate the parameter's ideal value (the ideal value is either too large or too small to be represented by the data type). For example, suppose that the parameter's ideal value is 200 and its data type is int8. Overflow occurs in this case because the maximum value that int8 can represent is 127.
Parameter overflow differs from parameter precision loss, which occurs when the ideal parameter value is within the range of the data type and scaling being used, but cannot be represented exactly.
Both parameter overflow and precision loss are quantization errors, and the distinction between them can be a fine one. The Detect overflow diagnostic reports all quantization errors greater than one bit. For very small parameter quantization errors, precision loss will be reported rather than an overflow when
![]()
where
Max is the maximum value representable by the parameter data type
Min is the minimum value representable by the parameter data type
Slope is the slope of the parameter data type (slope = 1 for integers)
Videal is the ideal value of the parameter
| Parameter: ParameterOverflowMsg |
| Type: string |
| Value: 'none' | 'warning' | 'error' |
| Default: 'error' |
| Application | Setting |
|---|---|
| Debugging | No impact |
| Traceability | No impact |
| Efficiency | No impact |
| Safety precaution | error |
Select the diagnostic action to take when a parameter underflow occurs during simulation.
Default: none
Simulink software takes no action.
Simulink software displays a warning.
Simulink software terminates the simulation and displays an error message.
Parameter underflow occurs when Simulink software encounters a parameter whose data type does not have enough precision to represent the parameter's ideal value because the ideal value is too small.
When parameter underflow occurs, casting the ideal value to the data type causes the parameter's modeled value to become zero, and therefore to differ from its ideal value.
| Parameter: ParameterUnderflowMsg |
| Type: string |
| Value: 'none' | 'warning' | 'error' |
| Default: 'none' |
| Application | Setting |
|---|---|
| Debugging | No impact |
| Traceability | No impact |
| Efficiency | No impact |
| Safety precaution | error |
Select the diagnostic action to take when parameter precision loss occurs during simulation.
Default: warning
Simulink software takes no action.
Simulink software displays a warning.
Simulink software terminates the simulation and displays an error message.
Precision loss occurs when Simulink software encounters a parameter whose data type does not have enough precision to represent the parameter's value exactly. As a result, the modeled value differs from the ideal value.
Parameter precision loss differs from parameter overflow, which occurs when the range of the parameter's data type, i.e., that maximum value that it can represent, is smaller than the ideal value of the parameter.
Both parameter overflow and precision loss are quantization errors, and the distinction between them can be a fine one. The Detect Parameter overflow diagnostic reports all parameter quantization errors greater than one bit. For very small parameter quantization errors, precision loss will be reported rather than an overflow when
![]()
where
Max is the maximum value representable by the parameter data type.
Min is the minimum value representable by the parameter data type.
Slope is the slope of the parameter data type (slope = 1 for integers).
Videal is the full-precision, ideal value of the parameter.
| Parameter: ParameterPrecisionLossMsg |
| Type: string |
| Value: 'none' | 'warning' | 'error' |
| Default: 'warning' |
| Application | Setting |
|---|---|
| Debugging | No impact |
| Traceability | No impact |
| Efficiency | No impact |
| Safety precaution | error |
Select the diagnostic action to take when an expression with tunable variables is reduced to its numerical equivalent.
Default: none
Simulink software takes no action.
Simulink software displays a warning.
Simulink software terminates the simulation and displays an error message.
If a tunable workspace variable is modified by Mask Initialization code, or is used in an arithmetic expression with unsupported operators or functions, the expression is reduced to a numeric expression and therefore cannot be tuned.
| Parameter: ParameterTunabilityLossMsg |
| Type: string |
| Value: 'none' | 'warning' | 'error' |
| Default: 'none' |
| Application | Setting |
|---|---|
| Debugging | No impact |
| Traceability | No impact |
| Efficiency | No impact |
| Safety precaution | error |
Select the diagnostic action to take if the model attempts to read data from a data store to which it has not written data in this time step.
Default: Use local settings
For each local data store (defined by a Data Store Memory block or Simulink.Signal object in a model workspace) use the setting specified by the block. For each global data store (defined by a Simulink.Signal object in the base workspace) disable the diagnostic.
Disables this diagnostic for all data stores accessed by the model.
Displays diagnostic as a warning at the MATLAB command line.
Halts the simulation and displays the diagnostic in an error dialog box.
| Parameter: ReadBeforeWriteMsg |
| Type: string |
| Value: 'UseLocalSettings' | 'DisableAll' | 'EnableAllAsWarning' | 'EnableAllAsError' |
| Default: 'UseLocalSettings' |
| Application | Setting |
|---|---|
| Debugging | No impact |
| Traceability | No impact |
| Efficiency | No impact |
| Safety precaution | Enable all as errors |
Data Store Memory block
Simulink.Signal object
Select the diagnostic action to take if the model attempts to write data to a data store after previously reading data from it in the current time step.
Default: Use local settings
For each local data store (defined by a Data Store Memory block or Simulink.Signal object in a model workspace) use the setting specified by the block. For each global data store (defined by a Simulink.Signal object in the base workspace) disable the diagnostic.
Disables this diagnostic for all data stores accessed by the model.
Displays diagnostic as a warning at the MATLAB command line.
Halts the simulation and displays the diagnostic in an error dialog box.
| Parameter: WriteAfterReadMsg |
| Type: string |
| Value: 'UseLocalSettings' | 'DisableAll' | 'EnableAllAsWarning' | 'EnableAllAsError' |
| Default: 'UseLocalSettings' |
| Application | Setting |
|---|---|
| Debugging | No impact |
| Traceability | No impact |
| Efficiency | No impact |
| Safety precaution | Enable all as errors |
Data Store Memory block
Simulink.Signal object
Select the diagnostic action to take if the model attempts to write data to a data store twice in succession in the current time step.
Default: Use local settings
For each local data store (defined by a Data Store Memory block or Simulink.Signal object in a model workspace) use the setting specified by the block. For each global data store (defined by a Simulink.Signal object in the base workspace) disable the diagnostic.
Disables this diagnostic for all data stores accessed by the model.
Displays diagnostic as a warning at the MATLAB command line.
Halts the simulation and displays the diagnostic in an error dialog box.
| Parameter: WriteAfterWriteMsg |
| Type: string |
| Value: 'UseLocalSettings' | 'DisableAll' | 'EnableAllAsWarning' | 'EnableAllAsError' |
| Default: 'UseLocalSettings' |
| Application | Setting |
|---|---|
| Debugging | No impact |
| Traceability | No impact |
| Efficiency | No impact |
| Safety precaution | Enable all as errors |
Data Store Memory block
Simulink.Signal object
Select the diagnostic action to take when one task reads data from a Data Store Memory block to which another task writes data.
Default: warning
Simulink software takes no action.
Simulink software displays a warning.
Simulink software terminates the simulation and displays an error message.
Such a situation is safe only if one of the tasks cannot interrupt the other, such as when the data store is a scalar and the writing task uses an atomic copy operation to update the store or the target does not allow the tasks to preempt each other.
You should disable this diagnostic (set it to none) only if the application warrants it, such as if the application uses a cyclic scheduler that prevents tasks from preempting each other.
| Parameter: MultiTaskDSMMsg |
| Type: string |
| Value: 'none' | 'warning' | 'error' |
| Default: 'warning' |
| Application | Setting |
|---|---|
| Debugging | No impact |
| Traceability | No impact |
| Efficiency | No impact |
| Safety precaution | error |
Data Store Memory block
Simulink.Signal object
Select the diagnostic action to take when the model contains multiple data stores that have the same name. The data stores can be defined with Data Store Memory blocks or Simulink.Signal objects.
Default: none
Simulink software takes no action.
Simulink software displays a warning.
Simulink software terminates the simulation and displays an error message.
This diagnostic is useful for detecting errors that can occur when a lower-level data store unexpectedly shadows a higher-level data store that has the same name.
| Parameter: UniqueDataStoreMsg |
| Type: string |
| Value: 'none' | 'warning' | 'error' |
| Default: 'none' |
| Application | Setting |
|---|---|
| Debugging | No impact |
| Traceability | No impact |
| Efficiency | No impact |
| Safety precaution | No impact |
Data Store Memory block
Simulink.Signal object
Select the diagnostic action to take when the software detects a Merge block with more than one driving block executing at the same time step.
Default: none
Simulink software takes no action.
Simulink software displays a warning.
Simulink software terminates the simulation and displays an error message.
Connecting the inputs of a Merge block to multiple driving blocks that execute at the same time step can lead to inconsistent results for both simulation and generated code. Set Detect multiple driving blocks executing at the same time step to error to avoid such situations.
If Underspecified initialization detection is set to Simplified, this parameter is disabled, and Simulink software automatically uses the strictest setting (error) for this diagnostic. Multiple driving blocks executing at the same time step always result in an error.
This parameter is enabled only if Underspecified initialization detection is set to Classic.
| Parameter: MergeDetectMultiDrivingBlocksExec |
| Type: string |
| Value: 'none' | 'warning' | 'error' |
| Default: 'none' |
| Application | Setting |
|---|---|
| Debugging | error |
| Traceability | error |
| Efficiency | No impact |
| Safety precaution | error |
Select how Simulink software handles initialization of initial conditions for conditionally executed subsystems, Merge blocks, subsystem elapsed time, and Discrete-Time Integrator blocks.
Default: Classic
Initial conditions are initialized the same way they were prior to R2008b.
Initial conditions are initialized using the enhanced behavior, which can improve the consistency of simulation results.
Use Classic to ensure compatibility with previous releases of Simulink.
Use Simplified to improve the consistency of simulation results, especially for models that do not specify initial conditions for conditional subsystem output ports, and for models that have conditionally executed subsystem output ports connected to S-functions.
When using Simplified initialization mode, you must set both Mux blocks used to create bus signals, and Bus signal treated as vector to error on the Connectivity Diagnostics pane.
For existing models, The MathWorks recommends using the Model Advisor to migrate your model to the new settings. To migrate your model, run the following Model Advisor checks:
Check for proper bus usage
Check consistency of initialization parameters for Outport and Merge blocks
For more information, see Check consistency of initialization parameters for Outport and Merge blocks in the Simulink Reference.
Selecting Classic enables the following parameters:
Detect multiple driving blocks executing at the same time step
Check undefined subsystem initial output
Check preactivation output of execution context
Check runtime output of execution context
Selecting Simplified disables these parameters, and automatically sets Detect multiple driving blocks executing at the same time step to error.
| Parameter: UnderspecifiedInitializationDetection |
| Type: string |
| Value: 'classic' | 'simplified' |
| Default: 'classic' |
| Application | Setting |
|---|---|
| Debugging | Simplified |
| Traceability | Simplified |
| Efficiency | Simplified |
| Safety precaution | Simplified |
Check consistency of initialization parameters for Outport and Merge blocks
Merge block
Discrete-Time Integrator block
Specify whether to display a warning if the model contains a conditionally executed subsystem in which a block with a specified initial condition drives an Outport block with an undefined initial condition
Default: On
Displays a warning if the model contains a conditionally executed subsystem in which a block with a specified initial condition drives an Outport block with an undefined initial condition.
Does not display a warning.
This situation occurs when a block with a specified initial condition, such as a Constant, Initial Condition, or Delay block, drives an Outport block with an undefined initial condition (Initial output parameter is set to []).
Models with such subsystems can produce initial results (i.e., before initial activation of the conditionally executed subsystem) in the current release that differ from initial results produced in Release 13 or earlier releases.
Consider for example the following model.

This model does not define the initial condition of the triggered subsystem's output port.
The following figure compares the superimposed output of this model's Step block and the triggered subsystem in Release 13 and the current release.

Notice that the initial output of the triggered subsystem differs between the two releases. This is because Release 13 and earlier releases use the initial output of the block connected to the output port (i.e., the Constant block) as the triggered subsystem's initial output. By contrast, this release outputs 0 as the initial output of the triggered subsystem because the model does not specify the port's initial output.
This parameter is enabled only if Underspecified initialization detection is set to Classic.
| Parameter: CheckSSInitialOutputMsg |
| Type: string |
| Value: 'on' | 'off' |
| Default: 'on' |
| Application | Setting |
|---|---|
| Debugging | No impact |
| Traceability | No impact |
| Efficiency | No impact |
| Safety precaution | On |
Specify whether to display a warning if Simulink software detects potential initial output differences from previous releases.
Default: Off
Displays a warning if Simulink software detects potential initial output differences from previous releases.
Does not display a warning.
This diagnostic is triggered if the model contains a block that meets the following conditions:
The block produces nonzero output for zero input (e.g., a Cosine block).
The block is connected to an output of a conditionally executed subsystem.
The block inherits its execution context from that subsystem.
The Outport to which it is connected has an undefined initial condition, i.e., the Outport block's Initial output parameter is set to [].
Models with blocks that meet these criteria can produce initial results (i.e., before the conditionally executed subsystem is first activated in the current release that differ from initial results produced in Release 13 or earlier releases.
Consider for example the following model.

The following figure compares the superimposed output of the Pulse Generator and cos block in Release 13 and the current release.

Note that the initial output of the cos block differs between the two releases. This is because in Release 13, the cos block belongs to the execution context of the root system and hence executes at every time step whereas in the current release, the cos block belongs to the execution context of the triggered subsystem and hence executes only when the triggered subsystem executes.
This parameter is enabled only if Underspecified initialization detection is set to Classic.
| Parameter: CheckExecutionContextPreStartOutputMsg |
| Type: string |
| Value: 'on' | 'off' |
| Default: 'on' |
| Application | Setting |
|---|---|
| Debugging | No impact |
| Traceability | No impact |
| Efficiency | No impact |
| Safety precaution | On |
Specify whether to display a warning if Simulink software detects potential output differences from previous releases.
Default: Off
Displays a warning if Simulink software detects potential output differences from previous releases.
Does not display a warning.
This diagnostic is triggered if the model contains a block that meets the following conditions:
The block has a tunable parameter.
The block is connected to an output of a conditionally executed subsystem.
The block inherits its execution context from that subsystem.
The Outport to which it is connected has an undefined initial condition, i.e., the Outport block's Initial output parameter is set to [].
Models with blocks that meet these criteria can produce results when the parameter is tuned in the current release that differ from results produced in Release 13 or earlier releases.
Consider for example the following model.

In this model, the tunevar S-function changes the value of the Gain block's k parameter and updates the diagram at simulation time 7 (i.e., it simulates tuning the parameter).
The following figure compares the superimposed output of the model's Pulse Generator block and its Gain block in Release 13 and the current release.

Note that the output of the Gain block changes at time 7 in Release 13 but does not change in the current release. This is because in Release 13, the Gain block belongs to the execution context of the root system and hence executes at every time step whereas in the current release, the Gain block belongs to the execution context of the triggered subsystem and hence executes only when the triggered subsystem executes, i.e., at times 5, 10, 15, and 20.
This parameter is enabled only if Underspecified initialization detection is set to Classic.
| Parameter: CheckExecutionContextRuntimeOutputMsg |
| Type: string |
| Value: 'on' | 'off' |
| Default: 'on' |
| Application | Setting |
|---|---|
| Debugging | No impact |
| Traceability | No impact |
| Efficiency | No impact |
| Safety precaution | On |
Select the diagnostic action to take when blocks write data to locations outside the memory allocated to them.
Default: none
Simulink software takes no action.
Simulink software displays a warning.
Simulink software terminates the simulation and displays an error message.
Use this option to check whether execution of each instance of a block during model simulation writes data to memory locations not allocated to the block. This can happen only if your model includes a user-written S-function that has a bug.
Enabling this option slows down model execution considerably. Thus, you should enable it only if you suspect that your model contains a user-written S-function that has a bug.
This option causes Simulink software to check whether a block writes outside the memory allocated to it during simulation. Typically this can happen only if your model includes a user-written S-function that has a bug.
See Writing S-Functions for more information on using this option.
| Parameter: ArrayBoundsChecking |
| Type: string |
| Value: 'none' | 'warning' | 'error' |
| Default: 'none' |
| Application | Setting |
|---|---|
| Debugging | warning |
| Traceability | No impact |
| Efficiency | none |
| Safety precaution | No impact |
Enable model verification blocks in the current model either globally or locally.
Default: Use local settings
Enables or disables blocks based on the value of the Enable assertion parameter of each block. If a block's Enable assertion parameter is on, the block is enabled; otherwise, the block is disabled.
Enables all model verification blocks in the model regardless of the settings of their Enable assertion parameters.
Disables all model verification blocks in the model regardless of the settings of their Enable assertion parameters.
Simulation and code generation ignore the Model Verification block enabling parameter when model verification blocks are inside a S-function.
| Parameter: AssertControl |
| Type: string |
| Value: 'UseLocalSettings' | 'EnableAll' | 'DisableAll' |
| Default: 'UseLocalSettings' |
| Application | Setting |
|---|---|
| Debugging | No impact |
| Traceability | No impact |
| Efficiency | No impact |
| Safety precaution | Disable all |
![]() | Diagnostics Pane: Sample Time | Diagnostics Pane: Type Conversion | ![]() |

Learn more about Simulink through this collection of videos, articles, technical literature and the Getting Started with Simulink Guide.
| © 1984-2009- The MathWorks, Inc. - Site Help - Patents - Trademarks - Privacy Policy - Preventing Piracy - RSS |