|
|
|
| R2012a Documentation → Simulink | |
Learn more about Simulink |
|
| Contents | Index |
Use the Simulink Model Advisor checks to configure your model for simulation.
Consulting the Model Advisorin the Simulink documentation.
Embedded Coder Checks in the Simulink Coder documentation.
Simulink Verification and Validation Checks in the Simulink Verification and Validation documentation.
Uses the slupdate command analysis mode to check for common upgrade issues.
Check blocks, settings, and references in the model for compatibility issues resulting from using a new version of Simulink software.
| Condition | Recommended Action |
|---|---|
| Referenced models recommended for update. | Run Simulink update tool, slupdate on the listed models. |
| Check library update status. | Verify that indicated libraries are valid. |
| Check update status for the Level 2 API S-functions. | Consider replacing Level 1 S-functions with Level 2. |
| Blocks have configuration sets or ports with undesired settings. | Run Simulink update tool, slupdate, in update mode. |
Clicking Modify replaces blocks from a previous release of Simulink software with the latest versions.
slupdate in the Simulink documentation.
Developing S-Functions in the Simulink documentation.
Uses the slupdate command analysis mode to check for common upgrade issues.
Check blocks, settings, and references for compatibility issues resulting from upgrading to a new version of Simulink software. Some block upgrades require the collection of information or data when the model is in the compile mode. For this check, the model is set to compiled mode and then checked for upgrades.
| Condition | Recommended Action |
|---|---|
| Model contains Lookup Table or Lookup Table (2-D) blocks and some of the blocks specify Use Input Nearest or Use Input Above for a lookup method. | Replace Lookup Table blocks and Lookup Table (2-D) blocks with n-D Lookup Table blocks. Do not apply Use Input Nearest or Use Input Above for lookup methods; select another option. |
| Model contains Lookup Table or Lookup Table (2-D) blocks and some blocks perform multiplication first during interpolation. | Replace Lookup Table blocks and Lookup Table (2-D) blocks with n-D Lookup Table blocks. However, because the n-D Lookup Table block performs division first, this replacement might cause a numerical difference in the result. |
| Model contains Lookup Table or Lookup Table (2-D) blocks. Some of these blocks specify Interpolation-Extrapolation as the Lookup method but their input and output are not the same floating-point type. | Replace Lookup Table blocks and Lookup Table (2-D) blocks with n-D Lookup Table blocks. Then change the extrapolation method or the port data types for block replacement. |
Clicking Modify replaces blocks from a previous release of Simulink software with the latest versions.
slupdate in the Simulink documentation.
n-D Lookup Table in the Simulink documentation.
Check for unconnected lines or ports.
This check lists unconnected lines or ports. These can have difficulty propagating signal attributes such as data type, sample time, and dimensions.
| Condition | Recommended Action |
|---|---|
| Lines, input ports, or output ports are unconnected. | Connect the signals. Double-click the list of unconnected items to locate failure. |
Use the PortConnectivity command to obtain an array of structures describing block input or output ports.
Common Block Parameters in the Simulink documentation for information on the PortConnectivity command.
Check that root model Inport blocks fully define dimensions, sample time, and data type.
Using root model Inport blocks that do not fully define dimensions, sample time, or data type can lead to undesired simulation results. Simulink software back-propagates dimensions, sample times and data types from downstream blocks unless you explicitly assign them values.
| Condition | Recommended Action |
|---|---|
| Root-level Inport blocks have undefined attributes. | Fully define the attributes of the root-level Inport blocks. |
Working with Data Types in the Simulink documentation.
Determining Output Signal Dimensions in the Simulink documentation.
How to Specify the Sample Time in the Simulink documentation.
Check for optimizations that can lead to nonoptimal code generation and simulation.
This check reviews the status of optimizations that can improve code efficiency and simulation time.
| Condition | Recommended Action |
|---|---|
| The specified optimizations are off. | Select the following optimization check boxes in the Optimization pane of the Configuration Parameters dialog box: Select the following optimization check boxes in the Optimization > Signals and Parameters pane of the Configuration Parameters dialog box: Select the following optimization check boxes in the Optimization > Stateflow pane of the Configuration Parameters dialog box: |
| Application lifespan (days) is set as infinite. This could lead to expensive 64-bit counter usage. | Choose a stop time if this is not intended. |
| The specified diagnostics, which can increase the time it takes to simulate your model, are set to warning or error. | Select none for:
|
| The specified Embedded Coder parameters are off. | If you have a Embedded Coder license, and
you are using an ERT-based system target file, select the following
check boxes:
|
If the system contains Model blocks and the referenced model is in Accelerator mode, simulating the model requires generating and compiling code.
Optimization Pane: General in the Simulink documentation.
Checks if parameter tunability information is included in the Model Parameter Configuration dialog box.
Simulink software ignores tunability information specified in the Model Parameter Configuration dialog box. This check identifies those models containing parameter tunability information that Simulink software will ignore if the model is referenced by other models.
| Condition | Recommended Action |
|---|---|
| Model contains ignored parameter tunability information. | Click the links to convert to equivalent Simulink parameter objects in the MATLAB workspace. |
Parameters in the Simulink documentation.
Identify models that attempt to resolve named signals and states to Simulink.Signal objects.
Requiring Simulink software to resolve all named signals and states is inefficient and slows incremental code generation and model reference. This check identifies those signals and states for which you may turn off implicit signal resolution and enforce resolution.
| Condition | Recommended Action |
|---|---|
| Not all signals and states are resolved. | Turn off implicit signal resolution and enforce resolution for each signal and state that does resolve. |
Resolving Signal Objects for Output Data in the Simulink documentation.
Identify virtual buses that could be made nonvirtual. Making these buses nonvirtual improves generated code efficiency.
This check identifies blocks incorporating virtual buses that cross a subsystem boundary. Changing these to nonvirtual improves generated code efficiency.
| Condition | Recommended Action |
|---|---|
| Blocks that specify a virtual bus crossing a subsystem boundary. | Change the highlighted bus to nonvirtual. |
Working with Signals in the Simulink documentation.
Virtual and Nonvirtual Buses in the Simulink documentation.
Identify Discrete-Time Integrator blocks with state ports and initial condition ports that are fed by neither an Initial Condition nor a Constant block.
Discrete-Time Integrator blocks with state port and initial condition ports might not be suitably initialized unless they are fed from an Initial Condition or Constant block. This is more likely to happen when Discrete-Time Integrator blocks are used to model second-order or higher-order dynamic systems.
| Condition | Recommended Action |
|---|---|
| Discrete-Time Integrator blocks are not initialized during the model initialization phase. | Add a Constant or Initial Condition block to feed the external Initial Condition port. |
IC block
Discrete-Time Integrator block
Constant block
Search model for disabled library links.
Disabled library links can cause unexpected simulation results. Resolve disabled links before saving a model.
Note This check may overlap with Check model, local libraries, and referenced models for known upgrade issues. |
| Condition | Recommended Action |
|---|---|
| Library links are disabled. | Use Restore Link from the Link Options setting in the context menu. |
Use the Model Browser to find library links.
To enable a broken link, right-click a block in your model to display the context menu. Choose Link Options and click Restore Link.
The Model Browser in the Simulink documentation.
Search model for parameterized library links.
Parameterized library links that are unintentional can result in unexpected parameter settings in your model. This can result in improper model operation.
| Condition | Recommended Action |
|---|---|
| Parameterized links are listed. | Verify that the links are intended to be parameterized. |
Right-click a block in your model to display the context menu. Choose Link Options and click Go To Library Block to see the original block from the library.
To parameterize a library link, choose Look Under Mask, from the context menu and select the parameter.
in the Simulink documentation.
Search the model for unresolved library links, where the specified library block cannot be found.
Check for unresolved library links. Models do not simulate while there are unresolved library links.
| Condition | Recommended Action |
|---|---|
| Library links are unresolved. | Locate missing library block or an alternative. |
Fixing Unresolved Library Links
Check model diagnostic settings that apply to function-call connectivity and that might impact model execution.
Check for connectivity diagnostic settings that might lead to non-deterministic model execution.
| Condition | Recommended Action |
|---|---|
| Diagnostics > Connectivity > Invalid function-call connection is set to none or warning. This might lead to non-deterministic model execution. | Set Diagnostics > Connectivity > Invalid function-call connection to error. |
| Diagnostic > Connectivity > Context-dependent inputs is set to Disable All or Use local settings. This might lead to non-deterministic model execution. | Set Diagnostics > Connectivity > Context-dependent inputs to Enable All. |
Look for modeling issues related to Data Store Memory blocks.
Checks for multitasking data integrity, strong typing, and shadowing of data stores of higher scope.
| Condition | Recommended Action |
|---|---|
| The Duplicate data store names check is set to none or warning. | Consider setting the Duplicate data store names check to error in the Configuration Parameters > Diagnostics > Data Validity pane. |
The data store variable names are not strongly typed in one
of the following:
| Specify a data type other than auto by taking one of the following
actions:
|
| The Multitask data store check is set to none or warning. | Consider setting the Multitask data store check to error in Configuration Parameters > Diagnostics > Data Validity pane. |
For data store blocks in the model, enable the read-and-write diagnostics order checking to detect run-time issues.
Check for the read-and-write diagnostics order checking. By enabling the read-and-write diagnostics, you detect potential run-time issues.
| Condition | Recommended Action |
|---|---|
| The Detect read before write check is disabled. | Consider enabling Detect read before write in the Configuration Parameters > Diagnostics > Data Validity pane. |
| The Detect write after read check is disabled. | Consider enabling Detect write after read in the Configuration Parameters > Diagnostics > Data Validity pane. |
| The Detect write after write check is disabled. | Consider enabling Detect write after write in the Configuration Parameters > Diagnostics > Data Validity pane. |
.
The run-time diagnostics can slow simulations down considerably. Once you have verified that Simulink does not generate warnings or errors during simulation, set them to Disable all.
Identify modeling errors due to the sample times of data store blocks.
Check data store blocks for continuous or zero-order hold sample times.
| Condition | Recommended Action |
|---|---|
| Data store blocks in your model have continuous or zero-order-hold sample times. | Consider making the listed blocks discrete or replacing them with either Memory or Goto and From blocks. |
Look for read/write issues which may cause inaccuracies in the results.
During an Update Diagram, identify potential issues relating to read-before-write, write-after-read, and write-after-write conditions for data store blocks.
| Condition | Recommended Action |
|---|---|
| Reading and writing (read-before-write or write-after-read condition) occur out of order. | Consider restructuring your model so that the Data Store Read block always executes before the Data Store Write block. |
| Multiple writes occur within a single time step. | Change the model to write data only once per time step or refer to the following Tips section. |
This check performs a static analysis which might not identify every instance of improper usage. Specifically, Function-Call Subsystems, Stateflow Charts, MATLAB for code generation, For Iterator Subsystems, and For Each Subsystems can cause both missed detections and false positives. For a more comprehensive check, consider enabling the following diagnostics in the Data Validity pane of the Configuration Parameters Diagnostics: Detect read before write, Detect write after read, and Detect write after write.
Identify blocks that use partial structures as parameter values for bus signals.
This check compares structures that provide parameter values for bus signals, to identify partial structures. This check returns a table listing the:
Paths to blocks that use partial structures as parameter values for bus signals
Names the block parameters that use the partial structure
For all data stores that you define with a Simulink.Signal object that uses a partial structure for its Initial value parameter, this check lists the following information, in a second table:
Name of the signal object
Workspace (MATLAB or model) of the signal object
Name of the signal object parameter that uses the partial structure
| Condition | Recommended Action |
|---|---|
Block using partial structure | Consider using the Simulink.Bus.createMATLABStructure function to convert a partial structure parameter to a full structure of parameter values for the listed blocks. |
Signal objects using partial structure | Consider using the Simulink.Bus.createMATLABStructure function to convert a partial structure parameter to a full structure of parameter values for the listed signals. |
Specifying partial structures for block parameter values can be useful during the iterative process of creating a model. You can use partial structures to focus on a subset of signals in a bus.
Specifying full structures for code generation offers these advantages:
Generated code is more readable than the code generated for partial structures.
Supports a modeling style that explicitly initializes unspecified signals. When you use partial structures, Simulink initializes unspecified signals implicitly.
Identify calls to the internal function slDataTypeAndScale.
In some previous versions of Simulink, opening a model that had been saved in an earlier version triggers an automatic upgrade to code for data type handling. The automatic upgrade inserts calls to the internal function slDataTypeAndScale. Although Simulink continues to support some uses of the function, if you eliminate calls to it, you get cleaner and faster code.
Simulink does not support calls to slDataTypeAndScale when:
The first argument is a Simulink.AliasType object.
The first argument is a Simulink.NumericType object with property IsAlias set to true.
Running Check for calls to slDataTypeAndScale identifies calls to slDataTypeAndScale that are required or recommended for replacement. In most cases, running the check and following the recommended action removes the calls. You can ignore calls that remain. Run the check unless you are sure there are not calls to slDataTypeAndScale.
| Condition | Recommended Action |
|---|---|
| Required Replacement Cases | Manually or automatically replace calls to slDataTypeAndScale. Cases listed require you to replace calls to slDataTypeAndScale. |
| Recommended Replacement Cases | For the listed cases, it is recommended that you manually or automatically replace calls to slDataTypeAndScale. |
| Manual Inspection Cases | Inspect each listed case to determine whether it should be manually upgraded. |
Do not manually insert a call to slDataTypeAndScale into a model. The function was for internal use only.
Running Check for calls to slDataTypeAndScale calls the Simulink function slRemoveDataTypeAndScale. Calling this function directly provides a wider range of conversion options. However, you very rarely need more conversion options.
For more information about upgrading data types and scales, in the MATLAB Command Window, execute the following:
help slDataTypeAndScale
help slRemoveDataTypeAndScale
Identify Mux blocks used as a bus creator and bus signal that Simulink treats as a vector.
Models should not contain bus signals that Simulink software implicitly converts to vectors. Instead, either insert a Bus to Vector conversion block between the bus signal and the block input port that it feeds, or use the Simulink.BlockDiagram.addBusToVector command.
| Condition | Recommended Action |
|---|---|
Model uses Mux blocks to create bus signals. | Replace Mux blocks with Bus Creator blocks. |
Model is not configured to identify Mux blocks used as bus creators. | In the Configuration Parameters dialog box, set Mux blocks used to create bus signals to error. |
Bus signals are implicitly converted to vectors. | Use Simulink.BlockDiagram.addBusToVector or insert a Bus to Vector block. |
Model is not configured to identify bus signals Simulink treats as vectors. | In the Configuration Parameters dialog set Bus signal treated as vector to error. |
Clicking Modify causes one of the following:
Mux blocks are replaced by Bus Creator blocks.
Bus to Vector blocks are inserted at the inports of blocks that implicitly convert bus signals to vectors.
The Bus to Vector conversion block resides in the Simulink/Signal Attributes library.
Run this check before running Check consistency of initialization parameters for Outport and Merge blocks.
The Non-bus signals treated as bus signals diagnostic detects when Simulink implicitly converts a non-bus signal to a bus signal to support connecting the signal to a Bus Assignment or Bus Selector block. This diagnostic is in the Configuration Parameters > Diagnostics > Connectivity pane.
Using a Mux block to create a virtual bus does not support strong type checking and increases the likelihood of run-time errors. In new applications, do not use Mux blocks to create bus signals. Consider upgrading existing applications to that use of Mux blocks.
Simulink generates a warning when you load a model created in a release prior to R2010a, if that model contains a Mux block to create a bus signal. For new models, Simulink generates an error.
Identify function-call return values that might be delayed because Simulink software inserted an implicit Signal Conversion block.
So that signals reside in contiguous memory, Simulink software can automatically insert an implicit Signal Conversion block in front of function-call initiator block input ports. This can result in a one-step delay in returning signal values from calling function-call subsystems. The delay can be avoided by ensuring the signal originates from a signal block within the function-call system. Or, if the delay is acceptable, insert a Unit Delay block in front of the affected input ports.
| Condition | Recommended Action |
|---|---|
| The listed block input ports could have an implicit Signal Conversion block. | Decide if a one-step delay in returning signal values is acceptable
for the listed signals.
|
Signal Conversion block
Unit Delay block
Find continuous sample time, non-floating-point output signals.
Non-floating-point signals might not represent continuous variables without loss of information.
| Condition | Recommended Action |
|---|---|
| Signals with continuous sample times have a non-floating-point data type. | On the identified signals, either change the sample time to be discrete or fixed-in-minor-step ([0 1]). |
Working with Sample Times in the Simulink documentation.
Analyze Merge blocks in the same tree as a group, and determine the possibility for them to execute at the same time step.
Blocks that directly drive the same tree of Merge blocks should have mutually exclusive execution in each time step. This check identifies those blocks that drive the same tree of Merge blocks, and so are likely to execute at the same time step.
| Condition | Recommended Action |
|---|---|
| Merge blocks can be interconnected to form a tree structure. | Rework your model so that no blocks drive the same tree of Merge blocks. |
Identify Outport and Merge blocks with parameter settings that can lead to unexpected initialization behavior, and migrate your model to the simplified initialization mode.
In R2008b or later versions, you can choose the simplified initialization mode for conditionally executed subsystems, Merge blocks, subsystem elapsed time, and Discrete-Time Integrator blocks. The simplified initialization mode improves the consistency of simulation results. This result is especially true for models that do not specify initial conditions for conditionally executed subsystem output ports, and for models that have conditionally executed subsystem output ports connected to S-functions.
Note Before running this consistency check, verify that your block diagram conforms to the modeling standards set by this diagnostic. For more information, see the Simulink documentation under 'Diagnostics Pane: Connectivity' or complete the following steps: .
|
This Model Advisor check identifies settings in your model that can cause problems if you use the simplified initialization mode. The results of the subchecks contain two types of statements: Failed and Warning. Failed statements identify issues that you must address manually before you can migrate the model to the simplified initialization mode. Warning statements identify issues or changes in behavior that may occur after migration.
After running this Model Advisor consistency check, if you select the Explore Result button, then the messages will only pertain to blocks that are not library-linked blocks.
Note Because it is difficult to undo these changes, use the Save Restore Point As feature to backup your model before migrating to the simplified initialization mode. |
| Condition | Recommended Action | |
|---|---|---|
| Check the run-time diagnostic setting of the Merge block. |
| |
| Verify that Model blocks are using the simplified initialization mode. | Migrate the model referenced by the Model block to the simplified initialization mode, then migrate the top model. | |
| Check for Model blocks that are using the PIL simulation mode. | The simplified initialization mode does not support the Processor-in-the-loop (PIL) simulation for model references. | |
| Check for single-input Merge blocks. | Replace both the Mux block used to produce the
input signal and the Merge block with one multi-input Merge block. Single-input Merge blocks are not supported in the simplified initialization mode. | |
| Check for root Merge blocks that have an unspecified 'Initial output'. | Specify an explicit value for the Initial output parameter
of root Merge blocks. A root Merge block is a Merge block with an output port that does not connect to another Merge block. | |
| Check for Merge blocks with nonzero input port offsets. | Clear the Allow unequal port widths parameter of the Merge block. | |
| Check for Merge blocks that have unconnected inputs or that have inputs from non-conditionally executed subsystems. | Set the Number of inputs parameter of
the Merge block to the number of Merge block inputs.
You must connect each input to a signal. Verify that each Merge block input is driven by a conditionally executed subsystem. Merge blocks cannot be driven directly by an Iterator Subsystem or a block that is not a conditionally executed subsystem. | |
| Check for Merge blocks with inputs that are combined or reordered outside of conditionally executed subsystems. | Verify that any combination or reordering of Merge block input signals takes place within a conditionally executed subsystem. Such designs may use Mux, Bus Creator, or Selector blocks. | |
| Check for Merge blocks with inconsistent input sample times. | Verify that input signals to each Merge block have the same Sample time. Failure to do so could result in unpredictable behavior. Consequently, the simplified initialization mode does not allow inconsistent sample times. | |
| Check for Merge blocks with multiple input ports that are driven by a single source. | Verify that the Merge block does not have multiple input signals that are driven by the same conditionally executed subsystem or conditionally executed Model block. | |
| Check for Outport blocks that have conflicting signal buffer requirements. | The Outport block has a function-call trigger or function-call data dependency signal passing through it, along with standard data signals. Some of the standard data signals require an explicit signal buffer for the initialization of the output signal of the corresponding subsystem. However, buffering function-call related signals leads to a function-call data dependency violation. Consider modifying the model to pass function-call related signals through a separate Outport block. For examples of function-call data dependency violations, see the demo model sl_subsys_semantics. A standard data signal may require an additional signal copy for one of the following reasons:
| |
| Check for Outport blocks that require an explicit signal copy. | An explicit copy of the bus signal driving the Outport block
is required for the initialization of the output signal of the corresponding
subsystem. Insert a Signal Conversion block before the Outport block, then set the Output parameter of the Signal Conversion block to Bus copy. A standard data signal may require an additional signal copy for one or more of the following reasons:
| |
| Check for merged Outport blocks that are driven by nested conditionally executed subsystems. | Determine if the new behavior of the Outport blocks is acceptable. If it is not acceptable, modify the model to account for the new behavior before migrating to the simplified initialization mode. | |
| Check for merged Outport blocks that reset when the blocks are disabled. | Set the Output when disabled parameter of the Outport block to held. This setting is required because the Outport block connects to a Merge block. For more information, see the Outport block documentation. | |
| Check for Outport blocks that have an undefined 'Initial output' value. | Specify the Initial output parameter for the Outport block, unless you want the block to obtain its Initial output value from its input signal. If you want the Outport block to obtain its Initial output value from its input signal, verify that its sources are valid. For the simplified initialization mode, valid sources from which an Outport blocks can inherit Initial output value are: Constant, Initial Condition, Merge (with initial output), or conditionally executed subsystem blocks.
| |
| Check Outport blocks that have automatic rate transitions. | Simulink has inserted a Rate Transition block
at the input of the Outport block. If this rate transition is required, then specify the Initial output parameter for each Outport block. Otherwise, perform the following procedure:
| |
| Check Outport blocks that have a special signal storage requirement. | Specify the Initial output parameter for the Outport block. The Outport block cannot obtain Initial output values from its input signals because of its special internal signal storage requirement. | |
| Check the 'Initial output' setting of Outport blocks that reset when they are disabled. | Specify the Initial output parameter of the Outport block. You must specify the Initial output value for blocks that are configured to reset when they become disabled. | |
| Check the 'Initial output' setting for Outport blocks that pass through a function-call data dependency signal. | You cannot specify an Initial output value for the Outport block because function-call data dependency signals are passing through it. To set the Initial output value:
| |
| Check for blocks inside of the Iterator Subsystem that require elapsed time. | Within an Iterator Subsystem hierarchy, do not use blocks that require a service that maintains the time that has elapsed between two consecutive executions. Since an Iterator Subsystem can execute multiple times at a given time step, the concept of elapsed time is not well-defined between two such executions. Using these blocks inside of an Iterator Subsystem can cause unexpected behavior. | |
| Check for Outport blocks that use signal objects to specify the 'Initial output' value. | Verify that the following behavior is acceptable. In the simplified initialization mode, signal objects cannot specify the Initial output parameter of an Outport block. You can still initialize the input or output signals for an Outport block using signal objects, but the initialization results may be overwritten by those of the Outport block. | |
| Check for merged Outport blocks that are either unconnected or connected to a Ground block. | Verify that the following behavior is acceptable. The Outport block is driving a Merge block, but its inputs are either unconnected or connected to Ground blocks. In the classic initialization mode, unconnected or grounded outports do not update the merge signal even when their parent conditionally executed subsystems are executing. In the simplified initialization mode, however, these outports will update the merge signal with a value of zero when their parent conditionally executed subsystems are executing. | |
| Check for Merge blocks that use signal objects to specify the 'Initial output' value. | Verify that the following behavior is acceptable. In the simplified initialization mode, signal objects cannot specify the Initial output parameter of the Merge block. While you can still initialize the output signal for a Merge block using a signal object, the initialization result may be overwritten by that of the Merge block. | |
| Check for Outport blocks that obtain the 'Initial output' value from an input signal when they are migrated. | Verify that the following behavior is acceptable. The Initial output parameter of the Outport block is not specified. As a result, the simplified initialization mode will assume that the Initial output value for the Outport block is derived from the input signal. This assumption may result in different initialization behavior. If this behavior is not acceptable, modify your model before you migrate to the simplified initialization mode. | |
| Check for innermost Outport blocks with variable-size input and an unspecified 'Initial output'. | In classic initialization mode, Simulink assumes that the 'Initial output' parameter is 0 when it is unspecified ([]) for the innermost Outport block. This block has variable-size input for which the signal size varies only when the parent subsystem is re-enabled. Unless you specify the value of the Initial output parameter, it will be set to zero when your model is migrated to the simplified initialization mode. | |
| Check for outer Outport blocks that have an explicit 'Initial output'. | Verify that the following behavior is acceptable. In the classic initialization mode, the Initial output and Output when disabled parameters of the Outport block must match those of their source Outport blocks. Consequently, Simulink will set the 'Source of initial output value' parameter to 'Input signal' in the simplified initialization mode. | |
| Check for conditionally executed subsystems that propagate execution context across the output boundary. | Verify that the following behavior is acceptable. The Propagate execution context across subsystem boundary parameter is selected for the subsystem. Execution context will still be propagated across input boundaries; however, the propagation will be disabled on the output side for the initialization in the simplified initialization mode. | |
| Check for Discrete-Time Integrator blocks. | Verify that the following behavior is acceptable. Simulink has changed the initialization behavior of the Discrete-Time Integrator block to be more consistent and robust in the simplified initialization mode. These changes include:
See the Discrete-Time Integrator block documentation for more information on the simplified initialization for the Discrete-Time Integrator. | |
| Check for blocks that read input from conditionally executed subsystems during initialization. | Verify that the following behavior is acceptable. Some blocks, such as the Discrete-Time Integrator block, read their inputs from conditionally executed subsystems during initialization in the classic initialization mode. Simulink performs this step as an optimization technique. This optimization is not allowed in the simplified initialization mode because the output of a conditionally executed subsystem at the first time step after initialization may be different than the initial value declared in the corresponding Outport block. In particular, this discrepancy occurs if the subsystem is active at the first time step. | |
| Check for library blocks with instances that cannot be migrated. | Examine the failed subcheck results for each block to determine the corrective actions. | |
| Check for library blocks with instances that have warnings. | Examine the warning subcheck results for each block before migrating to the simplified initialization mode. | |
| Check for a migration conflict for Outport blocks that will use a 'Dialog' as the 'Source of initial output value'. | Other instances of Outport blocks with the same library link either cannot be migrated or are being migrated in a different manner. Review the results from the Check for library blocks with instances that cannot be migrated to learn about the different migration paths for other instances of each Outport block. The Outport block will maintain its current settings and use its specified Initial output value. | |
| Check for a migration conflict for Outport blocks that will use an 'Input signal' as the 'Source of initial output' value. | Other instances of Outport blocks with the same library link either cannot be migrated or are being migrated in a different manner. Review the results from the Check for library blocks with instances that cannot be migrated to learn about the different migration paths for other instances of each Outport block. The Outport block currently specifies an Initial output of [] (empty matrix), and the Output when disabled as held. This means that each outport does not perform initialization, but implicitly relies on source blocks to initialize its input signal. After migration, the parameter Source of initial output value will be set to Input signal to reflect this behavior. | |
| Check for a migration conflict for Outport blocks that have SimEvents semantics. | Other instances of Outport blocks with the same library link either cannot be migrated or are being migrated in a different manner. Review the results from the Check for library blocks with instances that cannot be migrated to learn about the different migration paths for other instances of each Outport block. The Outport blocks will continue to use an Initial output value of [] (empty matrix) and an Output when disabled setting of held. Simulink will maintain these settings because their parent conditionally executed subsystems are connected to SimEvents blocks. | |
| Check for a migration conflict for innermost Outport blocks with variable-size input and unspecified 'Initial output'. | For these Outport blocks, the signal size varies only when the parent subsystem of the block is re-enabled. Therefore, Simulink implicitly assumes that the Initial output parameter is equal to 0, even though the parameter is unspecified, []. Consequently, unless you specify the parameter, the Model Advisor will explicitly set the parameter to 0 when the model is migrated to the simplified initialization mode. Other instances of Outport blocks with the same library link either cannot be migrated or are being migrated in a different manner. Review the results from the Check for library blocks with instances that cannot be migrated to learn about the different migration paths for other instances of each Outport block. | |
| Check for a migration conflict for merged Outport blocks without explicit specification of 'Initial output'. | Review the results from subcheck Check for library blocks with instances that cannot be migrated to learn about different migration paths for other instances of each Outport block |
Clicking Modify Settings causes the following:
The Model parameter is set to simplified
If an Outport block has the Initial output parameter set to the empty string , [] , then the SourceOfInitialOutputValue parameter is set to Input signal.
If an Outport has an empty Initial output and a variable-size signal, then the Initial output is set to zero.
Merge block
Discrete-Time Integrator block
Outport block
Detect multiple driving blocks executing at the same time step
Identify noncontinuous signals that drive derivative ports.
Noncontinuous signals that drive derivative ports cause the solver to reset every time the signal changes value, which slows down simulation.
| Condition | Recommended Action |
|---|---|
| There are noncontinuous signals in the model driving derivative ports. |
|
How Simulink Works in the Simulink documentation.
Check array bounds and solver consistency if S-Function blocks are in the model.
Validates whether S-Function blocks adhere to the ODE solver consistency rules that Simulink applies to its built-in blocks.
| Condition | Recommended Action |
|---|---|
| Solver data inconsistency is set to none. | Set Solver data inconsistency in the Configuration Parameters > Diagnostics pane to warning or error. |
| Array bounds exceeded is set to none. | Set Array bounds exceeded in the Configuration Parameters > Diagnostics > Data Validity pane to warning or error |
Developing S-Functions in the Simulink documentation
 | Model Advisor Checks | Simulink Limits |  |
Learn more about Simulink through this collection of videos, articles, technical literature and the Getting Started with Simulink Guide.
| © 1984-2012- The MathWorks, Inc. - Site Help - Patents - Trademarks - Privacy Policy - Preventing Piracy - RSS |
