Store 
| Products & Services | Solutions | Academia | Support | User Community | Company |
 |
Download Product Updates | | |  |
Get Pricing | | | |
Trial Software |
| Documentation → Simulink |
| Products & Services | Solutions | Academia | Support | User Community | Company |
|
Download Product Updates | | | |
Get Pricing | | | |
Trial Software |
| Documentation → Simulink |
| Contents | Index |
| Learn more about Simulink |
| On this page… |
|---|
Limitations on All Model Referencing Limitations on Normal Mode Referenced Models |
The following Simulink limitations apply to model referencing. In addition, a model reference hierarchy must satisfy all the requirements listed in Simulink Model Referencing Requirements.
In the following 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, like the Assignment block, or produce indexes, like the For Iterator block.
If a root-level input port of the referenced model is connected 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.
If a root-level output port of the referenced model is connected 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.
In these cases, the lack of propagation can cause Simulink to fail to detect incompatible index connections.
If a referenced model has any of the following properties, 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. If the parameter is not set correctly, or more than one instance of the model exists in the hierarchy, an error occurs. The properties are:
The model contains any To File blocks, to avoid multiple instances writing to the same file
The model references another model which has been 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 events
Machine-parented data
Mask callbacks cannot add Model blocks or change Model block name or simulation mode. Violating this requirement generates an error.
If a mask specifies the name of the model referenced by a Model block, the name of the referenced model must be provided directly by the mask, rather than being obtained by evaluating a workspace variable.
The mask workspace of a Model block is not visible to the model that it references. Any variable used by the referenced model must resolve to a workspace defined in the referenced model, or to the MATLAB base workspace.
See Working with Block Masks for information about creating and using block masks.
Working with the Simulink Debugger in a parent model, you can set breakpoints at Model block boundaries, allowing you to look at the block's input and output values, but you cannot set a breakpoint inside the submodel that the Model block references. See Simulink Debugger for more information.
A model that contains a Stateflow chart cannot be referenced multiple times in the same model reference hierarchy if:
The Stateflow chart contains exported graphical functions.
The Stateflow model contains machine-parented data or events.
Referenced models cannot use asynchronous rates internally. However, a function-call model referenced in a top model can be triggered by an asynchronous source within the top model. See Defining Function-Call Models for more information.
A referenced model can input or output only those user-defined data types that are fixed-point or defined by Simulink.DataType or Simulink.Bus objects.
Model blocks referencing models that contain assignment blocks that are not in an iterator subsystem cannot be placed in an iterator subsystem.
If you want to initialize the states of a model that references other models with states, you must specify the initial states in structure format.
The Model Browser does not display Model blocks in its tree view. Use the Model Explorer to browse a referenced model hierarchy.
A referenced model cannot directly access the signals in a multi-rate bus. Connecting Multi-Rate Buses to Referenced Models describes a technique for overcoming this limitation.
A continuous sample time cannot be propagated to a Model block that is sample-time independent.
Goto/From blocks cannot cross model reference boundaries.
You cannot print a referenced model from a top model.
Enabling the Simulink Profiler on a parent model does not enable profiling for referenced models. Profiling must be enabled separately for each submodel. See Capturing Performance Data.
When the same submodel appears more than once in a hierarchy, at most one of these instances can specify Normal mode. All the rest must specify Accelerator mode.
Accelerator mode simulation ignores custom code settings in the Configuration Parameter dialog box and custom code blocks when generating the simulation target for a referenced model.
Some restrictions exist on grouped custom storage classes in referenced models. See Custom Storage Class Limitations for details.
Data type replacement is not supported for simulation target code generation for referenced models. Also, the custom code is ignored in Simulation Target > Custom code
To Workspace blocks, Scope blocks, and all types of runtime display, such as Port Values Display, have no effect when specified in referenced models executing in Accelerator mode. The result during simulation is the same as if the constructs did not exist.
Referenced models executing in Accelerator mode cannot log data to MAT-files. If data logging is enabled for a referenced model, Simulink disables the option before code generation and re-enables it afterwards.
If a referenced model has any of the following properties, and the model executes in Accelerator mode, 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, in either Normal mode or Accelerator mode. If the parameter is not set correctly, or more than one instance of the model exists in the hierarchy, an error occurs. The properties are:
The model contains a subsystem that is marked as function
The model contains an S-function that is:
Inlined but has not set the option SS_OPTION_WORKS_WITH_CODE_REUSE
Not inlined
The model contains a function-call subsystem that:
Has been forced by Simulink to be a function
Is called by a wide signal
If a referenced model 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 will not inline the S-function unless this flag is set.
The Real-Time Workshop S-function target does not support model referencing.
A referenced model cannot use noninlined S-functions in the following cases:
The model uses a variable-step solver.
The S-function was generated by Real-Time Workshop.
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, and reference a different copy at each location that needs the model.
Simulink tools that require access to a model's internal data or configuration (including Model Coverage, the Report Generator, the Simulink Debugger, and the Simulink Profiler) 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.
A Stateflow chart in a referenced model that executes in Accelerator mode cannot call MATLAB functions.
If a subsystem contains Model blocks, you cannot build a subsystem module by right-clicking the subsystem or by using Tools > Real-Time Workshop > Build subsystem.
If you generate code for an atomic subsystem as a reusable function, inputs or outputs that connect the subsystem to a referenced model can affect code reuse, as described in Reusable Code and Referenced Models.
The Real-Time Workshop grt_malloc targets do not support model referencing.
The Real-Time Workshop 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, as described in Specifying the Simulation Mode.
When the sim command executes a referenced model in Accelerator mode, the source workspace is always the MATLAB base workspace (SrcWorkspace is base) even if a simset options structure specifies some other source workspace.
Errors can occur if a Model block is part of a cycle; the Model block is a direct feedthrough block; and an algebraic loop results. See Model Blocks and Direct Feedthrough for details.
Accelerator mode does not support the External mode option. If the option is enabled, it is ignored in Accelerator mode.
Only one branch (top model and all subordinates) in a model reference hierarchy can execute in PIL mode.
If you create a new model, you cannot use that model as a PIL mode referenced model until you have saved the model to disk. You can work around this limitation by setting the model to Normal mode, as described in Specifying the Simulation Mode.
For more information, see Creating Model Components in the Real-Time Workshop documentation, and Verifying Compiled Object Code with Processor-in-the-Loop Simulation in the Real-Time Workshop Embedded Coder documentation.
 | Refreshing Model Blocks | Working with Blocks |  |
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 |
