|
|
|
| R2012a Documentation → Simulink | |
Learn more about Simulink |
|
| Contents | Index |
| On this page… |
|---|
Limitations on All Model Referencing Limitations on Normal Mode Referenced Models |
The following limitations apply to model referencing. In addition, a model reference hierarchy must satisfy all the requirements listed in Simulink Model Referencing Requirements.
In two cases, Simulink does not propagate 0-based or 1-based indexing information to referenced-model root-level ports connected to blocks that:
Accept indexes (such as the Assignment block)
Produce indexes (such as the For Iterator block)
An example of a block that accepts indexes is the Assignment block. An example of a block that produces indexes is the For Iterator block.
The two cases result in a lack of propagation that can cause Simulink to fail to detect incompatible index connections. These two cases are:
If a root-level input port of the referenced model connects to index inputs in the model that have different 0-based or 1-based indexing settings, Simulink does not set the 0-based or 1-based indexing property of the root-level Inport block.
If a root-level output port of the referenced model connects to index outputs in the model that have different 0-based or 1-based indexing settings, Simulink does not set the 0-based or 1-based indexing property of the root-level Outport block.
If a referenced model has any of the following characteristics, the model must specify Configuration Parameters > Model Referencing > Total number of instances allowed per top model as One. No other instances of the model can exist in the hierarchy. An error occurs if you do not set the parameter correctly, or if more than one instance of the model exists in the hierarchy. The model characteristics that require that the Total number of instances allowed per top model setting be One are:
The model contains any To File blocks
The model references another model which is set to single instance
The model contains a state or signal with non-auto storage class
The model uses any of the following Stateflow constructs:
Stateflow graphical functions
Machine-parented data
Mask callbacks cannot add Model blocks. Also, mask callbacks cannot change the Model block name or simulation mode. These invalid callbacks generate an error.
If a mask specifies the name of the model that a Model block references, the mask must provide the name of the referenced model directly. You cannot use a workspace variable to provide the name.
The mask workspace of a Model block is not available to the model that the Mask block references. Any variable that the referenced model uses must resolve to either of these workspaces:
A workspace that the referenced model defines
The MATLAB base workspace
For information about creating and using block masks, see Working with Block Masks.
Working with the Simulink Debugger in a parent model, you can set breakpoints at Model block boundaries. Setting those breakpoints allows you to look at the input and output values of the Model block. However, you cannot set a breakpoint inside the model that the Model block references. See Simulink Debugger for more information.
The Model Browser does not display Model blocks in its tree view. To browse a referenced model hierarchy, use the Model Explorer.
You cannot reference a model multiple times in the same model reference hierarchy if that model that contains a Stateflow chart that:
Contains exported graphical functions
Is part of a Stateflow model that contains machine-parented data
You cannot place a Model block in an iterator subsystem, if the Model block references a model that contains Assignment blocks that are not in an iterator subsystem.
In a configurable subsystem with a Model block, during model update, do not change the subsystem that the configurable subsystem selects.
Referenced models can only use asynchronous rates if the model meets both of these conditions:
An external source drives the asynchronous rate through a root-level Inport block.
The root-level Inport block outputs a function-call signal. See Asynchronous Task Specification.
A referenced model can input or output only those user-defined data types that are fixed-point or that Simulink.DataType or Simulink.Bus objects define.
To initialize the states of a model that references other models with states, specify the initial states in structure or structure with time format. For more information, see Importing and Exporting State Information for Referenced Models.
A referenced model cannot directly access the signals in a multi-rate bus. To overcoming this limitation, see Connecting Multi-Rate Buses to Referenced Models.
A continuous sample time cannot be propagated to a Model block that is sample-time independent.
Goto and From blocks cannot cross model reference boundaries.
You cannot print a referenced model from a top model.
To use a masked subsystem in a referenced model that uses model arguments, do not create in the mask workspace a variable that derives its value from a mask parameter. Instead, use blocks under the masked subsystem to perform the calculations for the mask workspace variable.
You can simulate a model that has multiple instances of a referenced model that are in Normal mode. All of the instances of the referenced model are part of the simulation. However, Simulink displays only one of the instances in a model window. The Normal Mode Visibility setting determines which instance Simulink displays. Normal Mode Visibility includes the display of Scope blocks and data port values.
To set up your model to control which instance of a referenced model in Normal mode has visibility and to ensure proper simulation of the model, see Setting Up a Model with Multiple Instances of a Referenced Model in Normal Mode.
In Normal mode, enabling the Simulink Profiler on a parent model does not enable profiling for referenced models. You must enable profiling separately for each referenced model. See Capturing Performance Data.
When set to Normal mode, a Model block with a sim viewing device is not updated during Rapid Accelerator simulation.
If you generate code for an atomic subsystem as a reusable function, when you use Accelerator mode, the inputs or outputs that connect the subsystem to a referenced model can affect code reuse. See Reusable Code and Referenced Models for details.
Simulink tools that require access to the internal data or the configuration of a model have no effect on referenced models executing in Accelerator mode. Specifications made and actions taken by such tools are ignored and effectively do not exist. Examples of tools that require access to model internal data or configuration include:
Model Coverage
Simulink Report Generator™
Simulink Debugger
Simulink Profiler
Some blocks include runtime checks that are disabled when you include the block in a referenced model in Accelerator mode. Examples of these blocks include Assignment, Selector, and MATLAB Function blocks)
The following logging methods have no effect when specified in referenced models executing in Accelerator mode:
To Workspace blocks (for formats other than Timeseries)
Scope blocks
All types of runtime display, such as Port Values Display
During simulation, the result is the same as if the constructs did not exist.
You must set Configuration Parameters > Model Referencing > Total number of instances allowed per top model> > to One for a referenced model that executes in Accelerator mode and has any of the following characteristics:
A subsystem that is marked as function
An S-function that is:
Inlined but has not set the option SS_OPTION_WORKS_WITH_CODE_REUSE
Not inlined
A function-call subsystem that:
Has been forced by Simulink to be a function
Is called by a wide signal
An error occurs in either of these cases:
You do not set the parameter correctly.
Another instances of the model exists in the hierarchy, in either Normal mode or Accelerator mode
For restrictions that apply to grouped custom storage classes in referenced models in Accelerator mode, see Custom Storage Class Limitations.
Simulation target code generation for referenced models in Accelerator mode does not support data type replacement.
If a referenced model in Accelerator mode contains an S-function that should be inlined using a Target Language Compiler file, the S-function must use the ssSetOptions macro to set the SS_OPTION_USE_TLC_WITH_ACCELERATOR option in its mdlInitializeSizes method. The simulation target does not inline the S-function unless the S-function sets this option.
You cannot use the Simulink Coder S-function target in a referenced model in Accelerator mode.
A referenced model in Accelerator mode cannot use noninlined S-functions in the following cases:
The model uses a variable-step solver.
Simulink Coder generated the S-function.
The S-function supports use of fixed-point numbers as inputs, outputs, or parameters.
The model is referenced more than once in the model reference hierarchy. To work around this limitation:
Make copies of the referenced model.
Assign different names to the copies.
Reference a different copy at each location that needs the model.
The S-function uses string parameters.
A MATLAB Function block in a referenced model that executes in Accelerator mode cannot call MATLAB functions.
A Stateflow chart in a referenced model that executes in Accelerator mode cannot call MATLAB functions.
The Simulink Coder grt_malloc targets do not support model referencing.
The Simulink Coder S-function target does not support model referencing.
When you create a model, you cannot use that model as an Accelerator mode referenced model until you have saved the model to disk. You can work around this limitation by setting the model to Normal mode. See Specifying the Simulation Mode.
When the sim command executes a referenced model in Accelerator mode, the source workspace is always the MATLAB base workspace.
Accelerator mode does not support the External mode option. If you enable the External mode option, Accelerator mode ignores it.
Only one branch (top model and all subordinates) in a model reference hierarchy can execute in PIL mode.
If you create a model, you cannot use that model as a PIL mode referenced model until you have saved the model to disk. To work around this limitation, set the model to Normal mode. See Specifying the Simulation Mode.
For more information about using PIL mode with model referencing, see Referenced Models in the Embedded Coder documentation.
 | Logging Signals in Referenced Models | Creating Conditional Subsystems |  |
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 |
