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… |
|---|
During the initialization phase of simulation, Simulink determines the order in which to invoke the block methods (see Block Methods) during simulation. This ordering is the sorted order. You cannot set this order, but you can assign priorities to nonvirtual blocks to indicate to Simulink their relative order . Simulink then tries to honor your priority settings when it creates the sorted order according to the sorting rules. To confirm the results of any priorities that you have set or to debug your model, you can display and review the sorted order of your nonvirtual blocks and subsystems.
To display the sorted order of a system, from the Format menu, select Block Displays > Sorted Order. As a result, Simulink displays a notation in the top right corner of each nonvirtual block and each nonvirtual subsystem in the block diagram.
The following figure shows the sorted order for the van der Pol Equation model. The integrator with the sorted order 0:0 runs first followed by Out1 of order 0:1. The remaining blocks run in numeric order from 0:2 to 0:8.
The following model consists of a root-level system and two subsystems — an atomic, nonvirtual subsystem named "Discrete Cruise Controller" and a virtual subsystem called "Car Dynamics." Both subsystems produce graphical hierarchy in the model. The atomic subsystem also provides execution hierarchy. (See Creating Subsystems.) The sorted order of the blocks is shown for the case when the Desired Speed (Constant) block is set with a priority of one and the Car Dynamics (virtual) subsystem is set with a priority of two.
Car Dynamics Subsystem
Discrete Cruise Controller Subsystem
The sorted order notation for most blocks has the format s:b, where s is a system index that prefixes all blocks belonging to the execution context of that system. (See Conditional Execution Behavior for more information.) The b specifies the block position within the sorted order for the same execution context. For nonvirtual subsystems, the notation becomes s:b{ si} where s and b have the same meaning as before and where si represents the index of the execution context of a given subsystem.
For example the sorted order 0:4{1} appears on the Discrete Cruise Controller subsystem. The 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. The 4 indicates that the atomic subsystem is the fifth block that Simulink executes relative to the blocks within the root level. And the 1 represents the subsystem index. This index does not indicate the relative order in which the atomic subsystem runs. Like s, si is a means of identifying or referencing the subsystem. Also, si becomes s within the respective subsystem; each of the sorted orders in the Discrete Cruise Controller subsystem are of the form 1:b.
Because the sorted order of a Function-Call Subsystem cannot be determined at compile time, Simulink replaces the block position b with a single letter. 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 a subsystem that connects to more than one initiator, s is no longer unique; therefore, Simulink uses the letter notation M:F{si}.
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 the letter B stands for "bus." See Bus-Capable Blocks for more information.
Virtual blocks, such as the Mux block , exist only graphically and do not execute. Consequently, they are not part of a sorted order and do not display any sorted order notation. Similarly, the "Car Dynamics" subsystem is a virtual subsystem and thus is only a graphical entity created for organizational purposes. Unlike an atomic subsystem, a virtual subsystem does not execute as a unit and thus, like a virtual block, is not part of the sorted order. Instead, the blocks within the virtual subsystem are part of the root-level system sorted order, and therefore share the 0 index.
Simulink uses the following basic rules to sort blocks:
If a block drives the direct-feedthrough port of another block, it must appear in the sorted order ahead of the block it drives. (See About Direct-Feedthrough Ports.)
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 which 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.
The result of applying these rules is a sorted order in which blocks without direct-feedthrough ports appear at the beginning of the list in no particular order, followed by blocks with direct-feedthrough ports arranged such that they can supply valid inputs to the blocks which they drive. This is illustrated in the previous block diagrams (Car Dynamics Subsystem). The Integrator and the Constant blocks do not have direct-feedthrough and thus appear at the beginning of the sorted order of the root-level system. Also, all of the Gain blocks, which have direct-feedthrough ports, run before the Sum blocks that they drive.
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 its inputs. 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 the Gain, Product, and Sum blocks. Examples of blocks that have non-direct-feedthrough inputs include the Integrator block (its output is a function purely of its state), the Constant block (it does not have an input), and the Memory block (its output is dependent on its input from the previous time step).
During the sorting process, Simulink checks for and flags the occurrence of algebraic loops, that is, signal loops in which a direct-feedthrough output of a block connects directly or indirectly to a direct-feedthrough input of the same block. Such loops seemingly create a deadlock condition because the block needs the value of the direct-feedthrough input to compute its output.
However, an algebraic loop can represent a set of simultaneous algebraic equations (hence the name) where the block inputs and outputs are the unknowns. These equations can have valid solutions at each time step. Accordingly, Simulink assumes that loops involving direct-feedthrough ports represent a solvable set of algebraic equations. Simulink attempts to solve the equations each time it needs the block output during a simulation. For more information, see Algebraic Loops.
You can assign a priority to a nonvirtual blocks or to an entire subsystem (see Virtual Blocks). Higher priority blocks appear before lower priority blocks in the sorted order. The lower the number, the higher the priority.
You can assign block priorities programmatically or interactively.
To set priorities programmatically, use the command
set_param(b,'Priority','n')
where b is the block path and n is any valid integer. (Negative integers and 0 are valid priority values.)
To set the priority of a block interactively, enter the priority in the Priority field of the Block Properties dialog box. (See Block Properties Dialog Box.) You can interactively set the priority of any subsystem using the same method
.
Returning to the car model, the Constant block (Desired Speed) has been set to priority 1 by the user, while the virtual subsystem has been set to priority 2. Since the Constant block has a higher priority, it runs before the Integrator block of the subsystem. Whereas if you do not assign any priorities, the Integrator block runs first, followed by the Scope block and then the Constant block.
Simulink honors the block priorities that you specify only if they are consistent with the Simulink block sorting algorithm. In assessing your priority assignments, Simulink attempts to create a sorted order such that the priorities you set for the individual blocks within the root system or within a nonvirtual subsystem are honored relative to one another. Consider, for example, if you set the following priorities in the car model:
In Discrete Cruise Controller:
| Block | Priority |
|---|---|
| Gain | 3 |
| Gain1 | 2 |
| Gain2 | 1 |
In Car Dynamics:
| Block | Priority |
|---|---|
| Gain | 2 |
| Gain1 | 1 |
The results, as shown below, illustrate the three rules pertaining to priorities:
Priorities are relative: The priority of a block is relative to the priority of the blocks within the same system or subsystem.
Priorities are hierarchal.
A lack of priority does not necessarily result in a low priority (higher sorting order) for a given block.
Car Dynamics Subsystem
Discrete Cruise Controller Subsystem
The application of the first rule is evident in the Discrete Cruise Controller subsystem. The sorted order values of the Gain, Gain1, and Gain2 blocks reflect the respective priorities assigned: Gain2 has highest priority and comes first; Gain1 has second priority and comes second. However note that the Gain blocks are not the first, second, and third blocks to run. Nor do they have consecutive sorted orders. In other words, the sorted order values do not necessarily correspond to the priority values; however, Simulink arranges the blocks such that their priorities are honored relative to each other.
The sorted orders of the two subsystems illustrate the result of the second rule. You are allowed to 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 with those of any other subsystem. Thus the atomic subsystem has an independent sorted order with the blocks arranged consecutively from 0 to 8. In contrast, the blocks within the virtual subsystem are part of the primary or root system hierarchy and thus are part of the root-level sorted order.
Because of the third rule, the Integrator block in the Car Dynamics subsystem has no priority yet runs first. Similarly the Unit Delay, the Zero-Order Hold, and the Unit Delay1 blocks have no priority, yet they all execute before the Gain blocks. Simulink places these blocks first because they do not have direct-feedthrough ports.
If a model has two atomic subsystems A and B, you can assign priorities of 1 and 2 respectively to A and B and thereby cause all of the blocks in A to run before any of the blocks in B. (Recall that the blocks within an atomic subsystem execute as a single unit, so the subsystem has its own sorted order.)
Finally, if Simulink is unable to honor a block priority, it displays a Block Priority Violation diagnostic message(See Diagnostics Pane: Solver).
 | Displaying Block Outputs | 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-2009- The MathWorks, Inc. - Site Help - Patents - Trademarks - Privacy Policy - Preventing Piracy - RSS |
