Using Simulink    

The Diagnostics Pane

You can indicate the desired action for many types of events or conditions that can be encountered during a simulation by selecting the Diagnostics tab on the Simulation Parameters dialog box. This dialog box appears.

The dialog box includes the following options.

Consistency Checking

Consistency checking is a debugging tool that validates certain assumptions made by Simulink's ODE solvers. Its main use is to make sure that S-functions adhere to the same rules as Simulink built-in blocks. Because consistency checking results in a significant decrease in performance (up to 40%), it should generally be set to off. Use consistency checking to validate your S-functions and to help you determine the cause of unexpected simulation results.

To perform efficient integration, Simulink saves (caches) certain values from one time step for use in the next time step. For example, the derivatives at the end of a time step can generally be reused at the start of the next time step. The solvers take advantage of this to avoid redundant derivative calculations.

Another purpose of consistency checking is to ensure that blocks produce constant output when called with a given value of t (time). This is important for the stiff solvers (ode23s and ode15s) because, while calculating the Jacobian, the block's output functions can be called many times at the same value of t.

When consistency checking is enabled, Simulink recomputes the appropriate values and compares them to the cached values. If the values are not the same, a consistency error occurs. Simulink compares computed values for these quantities:

Bounds Checking

This option causes Simulink 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. If enabled, this check is performed for every block in the model every time the block is executed. As a result, enabling this option slows down model execution considerably. Thus, to avoid slowing down model execution needlessly, you should enable the option only if you suspect that your model contains a user-written S-function that has a bug. See Writing S-Functions for more information on using this option.

Configuration options

This control lists abnormal types of events that can occur during execution of the model. For each event type, you can choose whether you want no message, a warning message, or an error message. A warning message does not terminate a simulation, but an error message does.

Event
Description  
-1 sample time in source
A source block (e.g., a Sine Wave block) specifies a sample time of -1.
Algebraic loop
Simulink detected an algebraic loop while simulating the model. See Algebraic Loops for more information. If you set this option to Error, Simulink displays an error message and highlights the portion of the block diagram that comprises the loop (see Highlighting Algebraic Loops).
Block Priority Violation
Simulink detected a block priority specification error while simulating the model.
Check for singular matrix
The Product block detected a singular matrix while inverting one of its inputs in matrix multiplication mode.
Data overflow
The value of a signal or parameter is too large to be represented by the signal or parameter's data type. See Working with Data Types for more information.
Discrete used as continuous
The Unit Delay block, which is a discrete block, inherits a continuous sample time from the block connected to its input.
int32 to float conversion
A 32-bit integer value was converted to a floating-point value. Such a conversion can result in a loss of precision. See Working with Data Types for more information.
Invalid FcnCall Connection
Simulink has detected an incorrect use of a Function-Call subsystem in your model (see the "Function-call systems "examples in the Simulink Subsystem Semantics library for examples of invalid uses of Function-Call subsystems.. Disabling this error message can lead to invalid simulation results.
Min step size violation
The next simulation step is smaller than the minimum step size specified for the model. This can occur if the specified error tolerance for the model requires a step size smaller than the specified minimum step size. See Step Sizes and Error Tolerances for more information.
Multitask rate transition
An invalid rate transition occurred between two blocks operating in multitasking mode (see Multitasking Options).
Parameter downcast
Computation of the output of the block required converting the parameter's specified type to a type having a smaller range of values (e.g., from uint32 to uint8). This diagnostic applies only to named tunable parameters.
Parameter overflow
The data type of the parameter could not accommodate the parameter's value.
Parameter precision loss
Computation of the output of the block required converting the specified data type of the parameter to a less precise data type (e.g., from double to uint8).
S-function upgrades needed
A block was encountered that has not been upgraded to use features of the current release.
Signal label mismatch
The simulation encountered virtual signals that have a common source signal but different labels (see Virtual Signals).
SingleTask rate transition
A rate transition occurred between two blocks operating in single-tasking mode (see Multitasking Options).
Unconnected block input
Model contains a block with an unconnected input.
Unconnected block output
Model contains a block with an unconnected output.
Unconnected line
Model contains an unconnected line.
Underspecified data types
Simulink could not infer the data type of a signal during data type propagation.
Unneeded type conversions
A Data Type Conversion block is used where no type conversion is necessary.
Vector/Matrix conversion
A vector-to-matrix or matrix-to-vector conversion occurred at a block input (see Vector or Matrix Input Conversion Rules).


  The Workspace I/O Pane The Advanced Pane