|
|
|
| R2012a Documentation → Simulink | |
Learn more about Simulink |
|
| Contents | Index |
Ports & Subsystems
The Model block allows you to include a model as a block in another model. The included model is called a referenced model, and the model containing it (via the Model block) is called the parent model.
The Model block displays input ports and output ports corresponding to the top-level input and output ports of the referenced model. Use these ports allow you to connect the referenced model to other blocks in the parent model. See Referencing a Model for more information.
A Model block can specify the referenced model:
Statically, as a Model block parameter value, which must name the model literally
Dynamically, depending on base workspace values
A Model Variants block is a Model block with variants enabled. The Model block parameter dialog box contains the Enable Variants button by default. If you click the Enable Variants button, the Model Variants block parameter dialog opens. The Model Variants block parameter dialog contains the Disable Variants button by default. Therefore, you can use either the Model block or Model Variants block for implementing model variants. For more information about how to specify a referenced model for multiple specifications, see Modeling Variant Systems.
By default, the contents of a referenced model are user-visible, but you can hide the contents as described in Protecting Referenced Models.
A signal that connects to a Model block is functionally the same signal outside and inside the block. A given signal can have at most one associated signal object, so the signal connected to the Model block cannot have a signal object in both the parent and the referenced models. For more information, see Simulink.Signal.
The Model block supports signal label propagation. For details specific to model referencing and model variants, see:
Determined by the root-level inputs and outputs of the model referenced by the Model block.
Name of the model this block references.
Default: <Enter Model Name>
The value must be a valid MATLAB identifier.
The extension is optional. If you use an extension, use .mdl or .mdlp.
To navigate to the model that you want to reference from this block, use the Browse button to the right of the Model name parameter.
To confirm that the model you specify is the one you intended, you can use the Open Model button to the right of the Model name parameter.
| Parameter: ModelNameDialog |
| Type: string |
| Value: Any valid value |
| Default: The name of the referenced model exactly as you typed it in, with any surrounding whitespace removed. When you set ModelNameDialog programmatically or with the GUI, Simulink automatically sets the values of ModelName and ModelFile based on the value of ModelNameDialog. |
Display model arguments accepted by the model referenced by this block.
Declaring a variable to be a model argument allows each instance of the model to use a different value for that variable.
Default: ''
This is a read-only parameter that displays model arguments for the model referenced by this block. To create model arguments, refer to Using Model Arguments.
Specify values to be passed as model arguments to the model referenced by this block each time the simulation invokes the model.
Enter the values in this parameter as a comma-separated list in the same order as the corresponding argument names appear in the Model arguments field.
| Parameter: ParameterArgumentValues |
| Type: string |
| Value: Any valid value |
| Default: '' |
Set the simulation mode for the model referenced by this block. This setting specifies whether to simulate the model by generating and executing code or by interpreting the model in Simulink.
Default: Accelerator
Creates a MEX-file for the submodel, then executes the submodel by running the S-function.
Executes the submodel interpretively, as if the submodel were an atomic subsystem implemented directly within the parent model.
This option requires Embedded Coder software. Generates production code using model reference target for the submodel. This code is compiled for, and executed on, the host platform.
This option requires Embedded Coder software. Generates production code using model reference target for the submodel. This code is compiled for, and executed on, the target platform. A documented target connectivity API supports exchange of data between the host and target at each time step during the PIL simulation.
| Parameter: SimulationMode |
| Type: string |
| Value: 'Accelerator' | 'Normal' | 'Software-in-the-loop (SIL)' | 'Processor-in-the-loop (PIL)' |
| Default: 'Accelerator' |
Enables variants and opens the Model Variants block parameter dialog box, which is hidden by default. The Model Variants block parameter dialog box is the default block parameter dialog box for the Model Variants block.
Default: Disabled
This button enables the Model Variants Sections, which include: Variant choices table, Model parameters for the chosen variant in table section, parameters to override variants, and a Code generation section.
The following example shows the Model variants options from the demo model sldemo_mdlref_variants.
Displays a table of Simulink.Variant objects, associated model names, and conditions, which are Boolean expressions that determine which is the active variant.
Default: The table has a row for each variant object in the base workspace. The Variant choices table includes the name of each Variant object, its associated Condition, and the corresponding Model name.
Use the Add a new variant object button to add a new row to the table. See the description of the Variant object, Condition and Model name table columns for information about how to set values for table rows.
You can use buttons to the left of the Variant choices table to modify the table.
| Function | Button |
|---|---|
| Add a new variant: Add a new, empty row below the currently selected row |
 |
| Delete selected variant: Delete the currently selected row. (Models and objects are not affected.) |
 |
| Create/Edit selected variant object: Creates a Simulink.Variant object in the base workspace and opens the Simulink.Variant object parameter dialog in order to specify the variant Condition. |
 |
| Move variant up: Move the currently selected row up one slot in the table |
 |
| Move variant down: Move the currently selected row up one slot in the table |
 |
Enable variants enables this parameter.
| Parameter: Variants |
| Type: array |
| Value: array of variant structures where each element specifies one variant. The structure fields are: |
variant.Name (string) — The name of the Simulink.Variant object that represents the variant to which this element applies.
variant.ModelName (string) — The name of the referenced model associated with the specified variant object in this Model block.
variant.ParameterArgumentNames (string) — Read-only string containing the names of the model arguments for which the Model block must supply values.
variant.ParameterArgumentValues (string) — The values to supply for the model arguments when this variant is the active variant.
variant.SimulationMode (string) — The execution mode to use when this variant is the active variant.
Possible values are 'Accelerator' | 'Normal' | 'Software-in-the-loop (SIL)' | 'Processor-in-the-loop (PIL)'
Configuring the Model Variants Block
Display the Simulink.Variant objects in the base workspace or enter a variant object name in a new row.
Default: Variant1
To enter a variant object name, double-click a Variant object cell in a new row and type in the variant object name.
Enable variants enables this parameter.
| Structure field: Represented by the variant.Name field in the Variants parameter structure |
| Type: string |
| Value: name of the Simulink.Variant object that represents the variant to which this element applies. |
| Default: '' |
Display the condition for the Simulink.Variant object.
This read-only field displays the condition for the associated model variant in the base workspace. Click the Edit selected variant object button to specify the condition for the selected variant object.
The variant condition must be a Boolean expression that references at least one base workspace variable or parameter. For example, FUEL==2 && EMIS==1. Do not surround the condition with parentheses or single quotes. The expression can include:
MATLAB variables defined in the base workspace
Simulink parameter objects defined in the base workspace
Scalar variables
Enumerated values
Operators ==, !=, &&, ||, ~
Parentheses for grouping
Note To control variants using meaningful readable names, use a Simulink.Parameter object of enumerated type to define the variant condition. |
Enable variants enables this parameter.
Configuring the Model Variants Block
Display or enter the name of the model associated with the variant object in the Variant choices table.
Default: ''
Double-click the table cell to enter a model name. The name must be a valid MATLAB identifier.
The extension is optional. If you use an extension, use .mdl or .mdlp.
You can type the model name into the table, or you can use the Model parameters for chosen variant in table controls to find and open models:
To navigate to the model that you want to reference for the selected variant in the table, click the Browse button to the right of the Model name edit box.
To confirm that the model you specify is the one you intended, click the Open Model button to the right of the Model name edit box.
Enable variants enables this parameter.
| Structure field: represented by the variant.ModelName field in the Variants parameter structure |
| Type: string |
| Value: any valid value |
| Default: name of the referenced model exactly as you typed it, with any surrounding white space removed. When you set the model name programmatically or with the GUI, Simulink automatically sets the values of ModelName and ModelFile based on the value of ModelNameDialog. |
Display or enter the name of the model associated with the selected variant object in the Variant choices table.
Default: ''
Must be a valid MATLAB identifier.
The extension is optional. If you use an extension, use .mdl or .mdlp.
You can type the model name in either the table cell or the Model name edit box for the selected variant in the table. Use the controls to find and open models as follows:
To navigate to the model that you want to reference from this block, use the Browse button to the right of the Model name parameter.
To confirm that the model you specify is the one you intended, you can use the Open Model button to the right of the Model name parameter.
Enable variants enables this parameter.
| Structure field: represented by the variant.ModelName field in the Variants parameter structure |
| Type: string |
| Value: any valid value |
| Default: name of the referenced model exactly as you typed it, with any surrounding white space removed. When you set the model name programmatically or with the GUI, Simulink automatically sets the values of ModelName and ModelFile based on the value of ModelNameDialog. |
Display model arguments for the model variant object highlighted in the Variant choices table.
Declaring a variable to be a model argument allows each instance of the model to use a different value for that variable.
Default: ''
This is a read-only parameter that displays model arguments for the variant object highlighted in the Variant choices table. To create model arguments, refer to Using Model Arguments.
Enable variants enables this parameter.
| Structure field: Represented by the variant.ParameterArgumentNames field in the Variants parameter structureOneArgName |
| Type: string |
| Value: Enter model arguments as a comma separated list |
| Default: '' |
Specify values to be passed as model arguments to for the model variant object highlighted in the Variant choices table, each time the simulation invokes the model.
Enter the values in this parameter as a comma-separated list in the same order as the corresponding argument names appear in the Model arguments field.
Enable variants enables this parameter.
| Structure field: Represented by the variant.ParameterArgumentValues field in the Variants parameter structureOneArgName |
| Type: string |
| Value: Any valid value |
| Default: '' |
Set the simulation mode for the model variant object highlighted in the Variant choices table. This setting specifies whether to simulate the model by generating and executing code or by interpreting the model in Simulink.
Default: Accelerator
Creates a MEX-file for the submodel, then executes the submodel by running the S-function.
Executes the submodel interpretively, as if the submodel were an atomic subsystem implemented directly within the parent model.
This option requires Embedded Coder software. Generates production code using model reference target for the submodel. This code is compiled for, and executed on, the host platform.
This option requires Embedded Coder software. Generates production code using model reference target for the submodel. This code is compiled for, and executed on, the target platform. A documented target connectivity API supports exchange of data between the host and target at each time step during the PIL simulation.
Enable variants enables this parameter.
| Structure field: Represented by the variant.SimulationMode field in the Variants parameter structure |
| Type: string |
| Value: 'Accelerator' | 'Normal'| 'Software-in-the-loop (SIL)' | 'Processor-in-the-loop (PIL)' |
| Default: 'Accelerator' |
Specify whether to override the variant conditions and make the specified Variant parameter the active variant.
Default: Off
On Override the variant conditions and set the active variant to the value of the Variant parameter
OffDetermine the active variant by the value of the variant conditions
Both this GUI parameter and the Variant GUI parameter (following) use the same API parameter, OverrideUsingVariant.
Enable variants enables this parameter.
This parameter enables Variant.
| Parameter: OverrideUsingVariant |
| Type: string |
| Value: '' if no overriding variant object is specified, or the name of the overriding variant object |
| Default: '' |
Specify the variant object name associated with the model to use if you select Override variant conditions and use the following variant.
Default: ''
Must be a valid MATLAB identifier.
You can use the Variant edit box pulldown list to scroll a list of all variant objects currently in the base workspace, and their associated models.
Both this GUI parameter and the Override variant conditions and use following variant GUI parameter (above) use the same API parameter, OverrideUsingVariant.
Enable variants and Override variant conditions and use the following variant enable this parameter.
| Parameter: OverrideUsingVariant |
| Type: string (read-only) |
| Value: Name of the Simulink.Variant object |
Control whether generated code contains preprocessor conditionals. This check box is relevant only to code generation, and has no effect on the behavior of a model in Simulink. See Variant Systems for more information.
Default: Disabled
The check box is available for generating only ERT targets.
Override variant conditions and use following variant is cleared ('off')
Configuration Parameters > Optimization > Inline parameters is selected ('on')
Configuration Parameters > Code Generation > Interface > Generate preprocessor conditionals is set to Use local settings.
| Parameter: GeneratePreprocessorConditionals |
| Type: string |
| Value: 'off' | 'on' |
| Default: 'off' |
Disable model reference variants and hide the Model Variants Section. The block retains any information you have entered and approved by clicking Apply or OK. For more information, see Disabling and Enabling Model Variants.
| Parameter: Variant |
| Type: string |
| Value: 'off' | 'on' |
| Default: 'off' |
When you double-click a Model block, the block behaves differently compared to other blocks. This customized behavior depends on the current status of the Model block:
Double-clicking the prototype Model block in the Ports & Subsystems library opens its Block Parameters dialog box for inspection, but does not allow you to specify parameter values.
Double-clicking an unresolved Model block opens its Block Parameters dialog box. You can then resolve the block by specifying a Model name.
Double-clicking a resolved Model block opens the model that the block references. You can also open the model by choosing Open Model from the Context or Edit menu.
To display the Block Parameters dialog box for a resolved Model block, choose Model Reference Parameters from the Context or Edit menu.
When a Model block is part of a cycle, and the block is a direct feedthrough block, an algebraic loop can result. An algebraic loop in a model is not necessarily an error, but it may not give the expected results. See:
Algebraic Loops for information about direct feedthrough and algebraic loops.
Highlighting Algebraic Loops Using the Algebraic Loop Diagnostic for information about seeing algebraic loops graphically
Displaying Algebraic Loop Information for information about tracing algebraic loops in the debugger.
The Diagnostics Pane: Solver pane Algebraic loop option for information about detecting algebraic loops automatically.
A Model block may be a direct feedthrough block due to the structure of the referenced model. Where direct feedthrough results from submodel structure, and causes an unwanted algebraic loop, you can:
Automatically eliminate the algebraic loop using techniques described in:
Manually insert one or more Unit Delay blocks as needed to break the algebraic loop.
ERT-based targets provide the option Configuration Parameters > Code Generation > Interface > Single output/update function. This option controls whether generated code has separate output and update functions, or a combined output/update function. See:
Embedded Model Functions for information about separate and combined output and update functions.
Single output/update function for information about specifying whether code has separate or combined functions.
When Single output/update function is enabled (the default), a Model block has a combined output/update function. The function makes the block a direct feedthrough block for all inports, regardless of the structure of the referenced model. Where an unwanted algebraic loop results, you can:
Disable Single output/update function. The code for the Model block then has separate output and update functions, eliminating the direct feedthrough and hence the algebraic loop.
Automatically eliminate the algebraic loop using techniques described in:
Manually insert one or more Unit Delay blocks as needed to break the algebraic loop.
Direct Feedthrough | If Single output/update function is enabled (the default), a Model block is a direct feedthrough block regardless of the structure of the referenced model. If Single output/update function is disabled, a Model block may or may not be a direct feedthrough block, depending on the structure of the referenced model. |
Scalar Expansion | Depends on model referenced by this block. |
Multidimensionalized | Yes |
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 |
