| Using Simulink | |
The Diagnostics configuration parameters pane enables you to specify what diagnostic action Simulink should take, if any, when it detects an abnormal condition during compilation or simulation of a model.
The options are typically to do nothing or to display a warning or an error message (see Diagnosing Simulation Errors). A warning message does not terminate a simulation, but an error message does.
The pane displays groups of controls corresponding to various categories of abnormal conditions that can occur during a solution. To display controls for a specific category, left-click the category in the Categories list on the left side of the Diagnostics pane. To display controls for additional categories, left-click the categories while pressing the Ctrl key on your keyboard. See the following sections for information on using the controls on the Diagnostics pane:
Solver Diagnostics
This control group enables you to specify the diagnostic action that Simulink should take when it detects a solver-related error.
Algebraic loop. Simulink detected an algebraic loop while compiling 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).
Minimize algebraic loop. Specifies diagnostic action to take if you have requested that Simulink attempt to remove algebraic loops involving a specified subsystem (see Eliminating Algebraic Loops) and an input port of that subsystem has direct feedthrough. If the port is involved in an algebraic loop, Simulink can remove the loop only if at least one other input port in the loop lacks direct feedthrough.
Block priority violation. Simulink detected a block priority specification error while compiling the model.
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 Min step size and Maximum order for more information.
Unspecified inheritability of sample time. Specifies diagnostic action to be taken if this model contains S-functions that do not specify whether they preclude this model from inheriting their sample times from a parent model. Simulink checks for this condition only if the solver used to simulate this model is a fixed-step discrete solver and the periodic sample time constraint for the solver is set to ensure sample time independence (see Periodic sample time constraint).
Solver data inconsistency. Consistency checking is a debugging tool that validates certain assumptions made by Simulink 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 none. 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 matrix, 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:
Automatic solver parameter selection. Specifies diagnostic action to take if Simulink changes a solver parameter setting. For example, suppose that you simulate a discrete model that specifies a continuous solver and warning as the setting for this diagnostic. In this case, Simulink changes the solver type to discrete and displays a warning message about this change at the MATLAB command line.
Sample Time Diagnostics
This control group enables you to specify the diagnostic action that Simulink should take when it detects a compilation error related to model sample times.
Source block specifies -1 sample time. A source block (e.g., a Sine Wave block) specifies a sample time of -1.
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.
Multitask rate transition. An invalid rate transition occurred between two blocks operating in multitasking mode (see Tasking mode for periodic sample times).
Single task rate transition. A rate transition occurred between two blocks operating in single-tasking mode (see Tasking mode for periodic sample times).
Multitask data store. One task reads data from a Data Store Memory block to which another task writes data. Such a situation is safe only if one of the tasks cannot interrupt the other, e.g., 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 therefore disable this diagnostic, i.e., set it to none, only if the application warrants it, e.g. the application uses a cyclic scheduler that prevents tasks from preempting each other.
Tasks with equal priority. One asynchronous task of the target represented by this model has the same priority as another of the target's asynchronous tasks. This option must be set to Error if the target allows tasks having the same priority to preempt each other.
Data Integrity Diagnostics
This control group enables you to specify the diagnostic action that Simulink should take when it detects a condition that could compromise the integrity of data defined by the model.
Signal resolution. Specifies how Simulink resolves signals to Simulink.Signal objects in the MATLAB workspace. The options are
Try to resolve every signal or discrete state that has a name to a Simulink.Signal object having the same name. Display a warning message if a signal or state resolves implicitly to a signal object, i.e., a signal object with the same name as the signal or state exists in the MATLAB workspace but the model does not specify that the signal or state should resolve to a signal object.
Try to resolve every signal or discrete state that has a name to a Simulink.Signal object having the same name regardless of whether the model specifies that the signal or state should resolve to a signal object.
Try to resolve every signal or discrete state that the model specifies should resolve to a Simulink.Signal object in the MATLAB workspace.
| Note Use the Signal Properties dialog box (see Signal Properties Dialog Box) to specify explicit resolution for signals. Use the State Properties dialog boxes of blocks that have discrete states, e.g., the Discrete-Time Integrator block, to specify explicit resolution for discrete states. |
Attempted division by singular matrix. The Product block detected a singular matrix while inverting one of its inputs in matrix multiplication mode.
32-bit integer to single precision 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.
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).
Underspecified data types. Simulink could not infer the data type of a signal during data type propagation.
Duplicate data store names. The model contains multiple Data Store Memory blocks that specify the same data store name.
Array bounds exceeded. 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.
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.
Model Verification block enabling. This parameter allows you to enable or disable model verification blocks in the current model either globally or locally. Select one of the following options:
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.
"rt" prefix for identifiers. The default setting causes code generation to terminate with an error if it encounters a Simulink object name, e.g., the name of a parameter or block or signal, that begins with rt. This is intended to prevent inadvertent clashes with generated identifiers whose names begins with rt.
Conversion Diagnostics
This control group enables you to specify the diagnostic action that Simulink should take when it detects a data type conversion problem while compiling the model.
Unnecessary type conversions. A Data Type Conversion block is used where no type conversion is necessary.
Vector/matrix block input conversion. A vector-to-matrix or matrix-to-vector conversion occurred at a block input (see Vector or Matrix Input Conversion Rules).
Connectivity Diagnostics
This control group enables you to specify the diagnostic action that Simulink should take when it detects a problem with block connections while compiling the model.
Signal label mismatch. The simulation encountered virtual signals that have a common source signal but different labels (see Virtual Signals).
Unconnected block input ports. Model contains a block with an unconnected input.
Unconnected block output ports. Model contains a block with an unconnected output.
Unconnected line. Model contains an unconnected line.
Unspecified bus object at root Outport block. Specifies diagnostic action to take while generating a simulation target for a referenced model if any of the model's root Outport blocks is connected to a bus but does not specify a bus object (see Simulink.Bus).
Element name mismatch. Specifies diagnostic action to take if the name of a bus element does not match the name specified by the corresponding bus object. You can use this diagnostic along with bus objects to ensure that your model meets bus element naming requirements imposed by some blocks, such as the Switch block.
Mux blocks used to create bus signals. This diagnostic detects use of Mux blocks to create buses. The diagnostic considers a signal created by a Mux block to be a bus if the signal meets either or both of the following conditions:
The diagnostic has the following options:
This option enforces the following "strict bus" behavior during model editing, updating, and simulation:
If this option detects a Mux block that violates strict bus behavior while updating or simulating the model, it halts the model update or simulation and displays a message in the Simulink Diagnostic Viewer. The message identifies the offending Mux block.
This option does not enforce strict bus behavior. However, if it detects a Mux block that creates a bus during model update or simulation, it displays a message in the MATLAB Command Window that identifies the offending block. It does this for the first ten Mux blocks that it encounters that violate strict bus behavior.
Disables checking for Mux blocks used to create buses. This is the default setting for this diagnostic.
Note
You can avoid strict bus behavior errors and warnings by using slreplace_mux to remove Mux blocks that violate strict bus behavior from your model. Before executing the command, you should set this diagnostic to warning or none.
|
Invalid function call 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.
Warn if function-call inputs arise inside called context. Controls whether Simulink displays a warning if it has to compute any of a function-call subsystem's inputs directly or indirectly during execution of a call to a function-call subsystem (see the "Function-call systems" examples in the Simulink Subsystem Semantics library for examples of such function-call subsystems). The options are
Causes Simulink to issue a warning only if the corresponding diagnostic is selected on the function-call subsystem's parameters dialog box (see the documentation for the Subsystem block's parameter dialog box for more information).
Compatibility Diagnostics
This control group enables you to specify the diagnostic action that Simulink should take when it detects an incompatibility between this version of Simulink and the model when updating or simulating the model.
S-function upgrade needed. A block was encountered that has not been upgraded to use features of the current release.
Check undefined subsystem initial output. Display a warning if the model contains a conditionally executed subystem in which a block with a specified initial condition (e.g., a Constant, Initial Condition, or Delay block) drives an Outport block with an undefined initial condition, i.e., the Outport block's 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.
Check preactivation output of execution context. Display a warning if the model contains a block that meets the following conditions:
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.
Check runtime output of execution context. Display a warning if the model contains a block that meets the following conditions:
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.
Model Reference Diagnostics
This control group enables you to specify the diagnostic action that Simulink should take when it detects in incompatibility between this version of Simulink and the model while when updating or simulating the model.
Model block version mismatch. Specifies the diagnostic action to take during loading or updating of this model when Simulink detects a mismatch between the version of the model used to create or refresh a Model block in this model and the referenced model's current version. The options are
If you have enabled displaying of referenced model version numbers on Model blocks for this model (see Displaying Referenced Model Version Numbers), Simulink displays a version mismatch on the Model block icon as, for example: Rev:1.0 != 1.2.
Port and parameter mismatch. Specifies the diagnostic action to take during model loading or updating when Simulink detects a mismatch between the I/O ports of a Model block in this model and the root-level I/O ports of the model it references or between the parameter arguments recognized by the Model block and the parameter arguments declared by the referenced model. The options are
Model block icons can display a message indicating port or parameter mismatches. To enable this feature, select Block display -> Model block I/O mismatch from the parent model's Format menu.
Model configuration mismatch. Specifies the diagnostic action to take if the configuration parameters of a model referenced by this model do not match this model's configuration parameters or are inappropriate for a referenced model. The default action is none. Set this diagnostic to warning or error if you suspect that an inappropriate or mismatched configuration parameter may be causing your model to give the wrong result.
Invalid root Inport/Outport block connection. Specifies the diagnostic action to take during code generation if Simulink detects invalid internal connections to this model's root-level Output port blocks.
When this option is set to error, Simulink reports an error if any of the following types of connections appear in this model.
If you select none (the default), Simulink silently inserts blocks to satisfy the constraints wherever possible. In a few cases (such as function-call feedback loops), the inserted blocks may introduce delays and thus may change simulation results.
If you select warning, Simulink warns you that a connection constraint has been violated and attempts to satisfy the constraint by inserting hidden blocks.
Auto-inserting hidden blocks to eliminate root I/O problems stops at subsystem boundaries. Therefore, you may need to manually modify models with subsystems that violate any of the above constraints.
Unsupported data logging. Specifies the diagnostic action to take if this model contains To Workspace blocks or Scope blocks with data logging enabled. The default action warns you that Simulink does not support use of these blocks to log data from referenced models. See Logging Referenced Model Signals for information on how to log signals from a reference to this model.
| | The Optimization Pane | Hardware Implementation Pane | |
© 1994-2005 The MathWorks, Inc.
