|
|
|
| R2012a Documentation → Simulink | |
Learn more about Simulink |
|
| Contents | Index |
| On this page… |
|---|
During the updating phase of simulation, Simulink determines the order in which to invoke the block methods during simulation. This block invocation ordering is the sorted order.
You cannot set this order, but you can assign priorities to nonvirtual blocks to indicate to Simulink their execution order relative to other blocks. Simulink always honors block priority settings, unless there is a conflict with data dependencies. To confirm the results of priorities that you have set, or to debug your model, display and review the sorted order of your nonvirtual blocks and subsystems.
To display the sorted order of the vdp demo model:
Open the van der Pol equation demo model:
vdp
In the model window, select Format > Block Displays > Sorted Order.
Simulink displays a notation in the top-right corner of each nonvirtual block and each nonvirtual subsystem. These numbers indicate the order in which the blocks execute. The first block to execute has a sorted order of 0.
For example, in the van der Pol equation model, the Integrator block with the sorted order 0:0 executes first. The Out1 block, with the sorted order 0:1, executes second. Similarly, the remaining blocks execute in numeric order from 0:2 to 0:8.
You can save the sorted order setting with your model. To display the sorted order when you reopen the model, select Edit > Update diagram.
The sorted order notation varies depending on the type of block. The following table summarizes the different formats of sorted order notation. Each format is described in detail in the sections that follows the table.
| Block Type | Sorted Order Notation | Description |
|---|---|---|
| Nonvirtual Blocks | s:b |
|
| Nonvirtual Subsystems | s:b{ si} |
|
| Virtual Blocks and Subsystems | Not applicable | Virtual blocks do not execute. |
| Function-Call Subsystems | One initiator: s:F{ si} |
|
Two or more initiators:
|
| |
| Function-Call Split Blocks | s:Bb |
|
| Bus-Capable Blocks | s:B |
|
In the van der Pol equation model, all the nonvirtual blocks in the model have a sorted order. The system index for the top-level model is 0, and the block execution order ranges from 0 to 8.
The following model contains an atomic, nonvirtual subsystem named Discrete Cruise Controller.
When you enable the sorted order display for the root-level system, Simulink displays the sorted order of the blocks.
The Scope block in this model has the lowest sorted order, but its input depends on the output of the Car Dynamics subsystem. The Car Dynamics subsystem is virtual, so it does not have a sorted order and does not execute as an atomic unit. However, the blocks within the subsystem execute at the root level, so the Integrator block in the Car Dynamics subsystem executes first. The Integrator block sends its output to the Scope block in the root-level model, which executes second.
The Discrete Cruise Controller subsystem has a sorted order of 0:4{1}:
0 indicates that this atomic subsystem is part of the root level of the hierarchal system comprised of the primary system and the two subsystems.
4 indicates that the atomic subsystem is the fifth block that Simulink executes relative to the blocks within the root level.
{1} represents the subsystem index. This index does not indicate the relative order in which the atomic subsystem runs.
The sorted order of each block inside the Discrete Cruise Controller subsystem has the form 1:b, where:
1 is the system index for that subsystem.
b is the block position in the execution order. In the Discrete Cruise Controller subsystem, the sorted order ranges from 0 to 7.
Virtual blocks, such as the Mux block, exist only graphically and do not execute. Consequently, they are not part of the sorted order and do not display any sorted order notation.
Virtual subsystems do not execute as a unit, and like a virtual block, are not part of the sorted order. The blocks inside the virtual subsystem are part of the root-level system sorted order, and therefore share the system index.
In the model in Nonvirtual Subsystems, the virtual subsystem Car Dynamics does not have a sorted order. However, the blocks inside the subsystem have a sorted order in the execution context of the root-level model. The blocks have the same system index as the root-level model. The Integrator block inside the Car Dynamics subsystem has a sorted order of 0:0, indicating that the Integrator block is the first block executed in the context of the top-level model.
Single Initiator. For each function-call subsystem or model attached to a single initiator, Simulink assigns the block position F. The function-call subsystem (or model) executes when the initiator invokes the function-call subsystem (or model) and, therefore, does not have a sorted order independent of its initiator. Specifically, for a subsystem that connects to one initiator, Simulink uses the notation s:F{ si}, where s is the index of the system that contains the initiator.
For example, the sorted order for the ThresholdCalculation subsystem is 1:F{2}:
1 is the index of the system that contains the initiator, in this case, the ShiftLogic Stateflow chart.
F indicates that this function-call subsystem connects to one initiator.
2 is the system index for the ThresholdCalculation subsystem.
Multiple Initiators. For a function-call subsystem that connects to more than one initiator, the sorted order notation depends on the execution context of the initiators:
If the initiators all execute at the same level of the model hierarchy, the notation is s:F{si}.
If the initiators execute at different levels of the model hierarchy, the notation is M:F{si}
For example, open the sl_subsysm_fcncall6 demo model. The f subsystem has three initiators, two from the Stateflow chart, Chart1, and one from the Stateflow chart, Chart.
Because Chart1 has a system index of 2 and Chart has a system index of 1, the initiators execute at different levels in the model hierarchy. The Function-Call Subsystem f has a sorted order notation of M:F{3}.
When a function-call signal is branched using a Function-Call Split block, Simulink displays the order in which subsystems (or models) that connect to the branches execute when the initiator invokes the function call. Simulink uses the notation s:Bb to indicate this order, where B stands for branch. The block position b ranges from 0 to one less than the total number of subsystems (or models) that connect to branches (B0, B1, etc.). When the function-call is invoked, the subsystems execute in ascending order based on this number.
For example, open the sl_subsys_fcncall11 demo model and display the sorted order. The sorted order indicates that the subsystem f (B0) executes before the subsystem g (B1).
A bus-capable block does not execute as a unit and therefore does not have a unique sorted order. Such a block displays its sorted order as s:B where B stands for bus.
For example, open the sldemo_bus_arrays demo model and display the sorted order. Open the For Each Subsystem to see that the sorted order for the Bus Assignment block appears as 1:B.
For more information, see Bus-Capable Blocks.
To ensure that the sorted order reflects data dependencies among blocks, Simulink categorizes block input ports according to the dependency of the block outputs on the block input ports. An input port whose current value determines the current value of one of the block outputs is a direct-feedthrough port. Examples of blocks that have direct-feedthrough ports include:
Examples of blocks that have non-direct-feedthrough inputs:
Integrator — Output is a function of its state.
Constant — Does not have an input.
Memory — Output depends on its input from the previous time step.
To sort blocks, Simulink uses the following rules:
If a block drives the direct-feedthrough port of another block, the block must appear in the sorted order ahead of the block that it drives.
This rule ensures that the direct-feedthrough inputs to blocks are valid when Simulink invokes block methods that require current inputs.
Blocks that do not have direct-feedthrough inputs can appear anywhere in the sorted order as long as they precede any direct-feedthrough blocks that they drive.
Placing all blocks that do not have direct-feedthrough ports at the beginning of the sorted order satisfies this rule. This arrangement allows Simulink to ignore these blocks during the sorting process.
Applying these rules results in the sorted order. Blocks without direct-feedthrough ports appear at the beginning of the list in no particular order. These blocks are followed by blocks with direct-feedthrough ports arranged such that they can supply valid inputs to the blocks which they drive.
The following model, from Nonvirtual Subsystems, illustrates this result. The following blocks do not have direct-feedthrough and therefore appear at the beginning of the sorted order of the root-level system:
Integrator block in the Car Dynamics virtual subsystem
Speed block in the root-level model
Inside the Discrete Cruise Controller subsystem, all the Gain blocks, which have direct-feedthrough ports, run before the Sum block that they drive.
You can assign a priority to a nonvirtual block or to an entire subsystem. Higher priority blocks appear before lower priority blocks in the sorted order. The lower the number, the higher the priority.
To set priorities programmatically, use the command:
set_param(b,'Priority','n')
where
b is the block path.
n is any valid integer. (Negative integers and 0 are valid priority values.)
To set the priority of a block or subsystem interactively:
Right-click the block and select Block Properties.
On the General tab, in the Priority field, enter the priority.
Simulink honors the block priorities that you specify unless they violate data dependencies. (Block Priority Violations describes situations that cause block property violations.)
In assessing priority assignments, Simulink attempts to create a sorted order such that the priorities for the individual blocks within the root-level system or within a nonvirtual subsystem are honored relative to one another.
Three rules pertain to priorities:
Priorities are relative; the priority of a block is relative to the priority of the blocks within the same system or subsystem.
For example, suppose you set the following priorities in the Discrete Cruise Controller subsystem in the model in Nonvirtual Subsystems.
| Block | Priority |
|---|---|
| Gain | 3 |
| Gain1 | 2 |
| Gain2 | 1 |
After updating the diagram, the sorted order for the Gain blocks is as follows.
The sorted order values of the Gain, Gain1, and Gain2 blocks reflect the respective priorities assigned: Gain2 has highest priority and executes before Gain1 and Gain; Gain1 has second priority and executes after Gain2; and Gain executes after Gain1. Simulink takes into account the assigned priorities relative to the other blocks in that subsystem.
The Gain blocks are not the first, second, and third blocks to execute. Nor do they have consecutive sorted orders. The sorted order values do not necessarily correspond to the priority values. Simulink arranges the blocks so that their priorities are honored relative to each other.
In the Car Dynamics virtual subsystem, suppose you set the priorities of the Gain blocks as follows.
| Block | Priority |
|---|---|
| Gain | 2 |
| Gain1 | 1 |
After updating the diagram, the sorted order for the Gain blocks is as illustrated. With these priorities, Gain1 always executes before Gain.
You can set a priority of 1 to one block in each of the two subsystems because of the hierarchal nature of the subsystems within a model. Simulink never compares the priorities of the blocks in one subsystem to the priorities of blocks in any other subsystem.
For example, consider this model again.
The blocks within the Car Dynamics virtual subsystem are part of the root-level system hierarchy and are part of the root-level sorted order. The Discrete Cruise Controller subsystem has an independent sorted order with the blocks arranged consecutively from 1:0 to 1:7.
A lack of priority does not necessarily result in a low priority (higher sorting order) for a given block. Blocks that do not have direct-feedthrough ports execute before blocks that have direct-feedthrough ports, regardless of their priority.
If a model has two atomic subsystems, A and B, you can assign priorities of 1 and 2 respectively to A and B. This priority causes all the blocks in A to execute before any of the blocks in B. The blocks within an atomic subsystem execute as a single unit, so the subsystem has its own system index and its own sorted order.
Simulink software honors the block priorities that you specify unless they violate data dependencies. If Simulink is unable to honor a block priority, it displays a Block Priority Violation diagnostic message.
As an example:
Open the sldemo_bounce demo model.
Notice that the output of the Memory block provides the input to the Coefficient of Restitution Gain block.
Set the priority of the Coefficient of Restitution block to 1, and set the priority of the Memory block to 2.
Setting these priorities specifies that the Coefficient of Restitution block execute before the Memory block. However, the Coefficient of Restitution block depends on the output of the Memory block, so the priorities you just set violate the data dependencies.
In the model window, enable sorted order by selecting Format > Block displays > Sorted Order.
Select Edit > Update Diagram.
The block priority violation warning appears in the MATLAB Command Window. The warning includes the priority for the respective blocks:
Warning: Unable to honor user-specified priorities. 'sldemo_bounce/Memory' (pri=[2]) has to execute before 'sldemo_bounce/Coefficient of Restitution' (pri=[1]) to satisfy data dependencies
Remove the priorities from the Coefficient of Restitution and Memory blocks and update the diagram again to see the correct sorted order.
 | Displaying Port Values | Accessing Block Data During Simulation |  |
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 |
