Controlling the Execution Order
Simulink uses a set of basic rules to determine the execution order of the blocks in your model. Simulink refers to the process of determining the execution order of the blocks as "sorting" the blocks. For example, a block whose output drives the inputs of other blocks should be executed before the blocks it is driving. In general, the blocks are executed sequentially if they are wired together in a daisy-chain fashion. For blocks that are not wired together i.e., two different sets of blocks without any data dependency, Simulink sorts them on a first-come first-serve basis. For example, if you have two source blocks in your model which have no dependencies whatsoever, then Simulink typically executes the block added to the model first and then the second block. For a complete discussion on how Simulink sorts the order of blocks in the model, please refer to the Controlling and Displaying the Sorted Order section in the Simulink documentation.
In order to display the sorted order of blocks in your model, select
from the Simulink menu in the model window. This option displays the order in which blocks get executed. Once you enable this option,
a pair of numbers appear on the top right corner of each block. The first number indicates the
number of the non-virtual subsystem to which the block belongs while the second number indicates the execution order of the
block in the same subsystem. The first number will be 0 if the block belongs to the root level of the model. Note that only non-virtual
subsystems are numbered - that is, subsystems which are atomic in nature, such as the Atomic Subsystem
and the conditionally executed subsystems, such as the Enabled Subsystem. Non-virtual subsystems are
indicated by a bold border around the block. Non-virtual subsystems also display a third number in curly braces, which indicates the
number assigned to the non-virtual subsystem itself (the first number indicates the number of its parent non-virtual subsystem).
The Subsystem block is a virtual subsystem. Simulink
considers the blocks in a virtual subsystem as belonging directly to their parent, essentially "flattening" the model hierarchy. Thus, blocks in
a Subsystem at the root level of the model will be sorted against the blocks which are actually in the
root level of the model. Their sorted order will indicate a 0 as the first number even though they belong to the
Subsystem because Simulink considers them as belonging to the root-level of the model. This
flattening of the model does not occur for non-virtual subsystems, like the Atomic Subsystem.
Non-virtual subsystems are treated as if they are a single block - a "black box" - and are sorted like any other block in the
model that is not a subsystem. Hence, blocks in a non-virtual subsystem are always grouped together in the execution order while
blocks in a virtual subsystem may execute disparately, with other blocks outside the virtual subsystem executing in between
different blocks inside the virtual subsystem.
Every time you add blocks to your model and update your diagram, Simulink recomputes the sorted order. Hence, the sorted order numbers displayed for each block change to take the new blocks into account. For a complete discussion on the sorted order and the number of combinations for the sorted order display, please refer to the Controlling and Displaying the Sorted Order section in the Simulink documentation.
Circumstances occasionally arise in which you may wish to control the execution order of blocks in the diagram. This situation is particularly true when accessing hardware and that hardware must be accessed in a certain sequence. Communications is another example where the execution order can be important. This section describes two methods of changing the execution order of blocks in the model: using the Atomic Subsystem block and changing block priorities. Quanser recommends the first technique because it is simpler to use and provides immediate visual confirmation of the execution order. Using block priorities can be complicated at times, and can even produce errors if not specified correctly. Please use the following list to refer to each method:
Using the Block
One method to control the execution order of blocks in your model is to use the Atomic Subsystem block from the Simulink/Ports & Subsystems library in the Simulink Library Browser. The Atomic Subsystem block is a non-virtual subsystem. Hence, the blocks within it are treated as an atomic unit and are always grouped together in the execution order. For more information on this block, please refer to the Atomic Subsystem block reference page in the Simulink documentation.
If you have multiple Atomic Subsystem blocks connected in a daisy-chain fashion, they get sorted sequentially. Since blocks within an Atomic Subsystem are always grouped together in the execution order, the blocks in the first Atomic Subsystem in the chain will always execute before the blocks in the next Atomic Subsystem, and so on down the chain. You can take advantage of this fact and order the blocks in your model by putting the blocks you wish to execute first in the first Atomic Subsystem in the chain, and blocks you wish to execute later in subsequent Atomic Subsystem blocks. Consider the following example in which this method has been used to control the execution order of the blocks.
Notice that since the first Atomic Subsystem drives the second subsystem's input, it will precede the
second subsystem in the execution order.
The numbers inside braces represent the number assigned to the non-virtual subsystem. For instance, the first
Atomic Subsystem is the first non-virtual subsystem in the model, so it is designated as non-virtual
subsystem 1 and a 1 is displayed inside the braces. The root level of the model is assigned a number of
0. Hence, a 0 is displayed as the first number for both Atomic Subsystem blocks.
The following two figures illustrate each subsystem's contents.
Blocks within the first Atomic Subsystem display a 1 as the first number in their
sorted order because they belong to non-virtual subsystem 1. Likewise,
blocks within the second Atomic Subsystem display a 2 as the first number in their
sorted order because they belong to non-virtual subsystem 2.
You can add blocks to each Atomic Subsystem knowing that the blocks in the first subsystem will always get executed before the blocks in the second subsystem. In this example, there are only two Sine Wave generators and Scopes being used, for simplicity. Note that this technique requires the use of an Atomic Subsystem because they are non-virtual. The Subsystem block cannot be used to control the execution order because it is a virtual subsystem.
Block Prioritization
Simulink also allows the sorted order of blocks to be changed by letting the user prioritize the blocks. However, it places restrictions on the execution order of blocks that are wired together, based on their data dependency. If you attempt to change the execution order to one that violates Simulink's data dependency rules, then Simulink produces a data dependency violation error. Blocks that do not have any data dependency with each other may be sorted in any order desired.
The priority of a block may be set using the "Block Properties" dialog. Right-click on any block and select the menu item from the context menu. The dialog that appears is illustrated below.
The Priority parameter under the General pane is used to set the priority of the block. This parameter accepts integers, including negative numbers and zero. The lower the number, the higher the priority. For example, a block with a priority of -10 has higher priority than one having 2 as its priority.
Higher priority blocks appear before lower priority blocks in the execution order, though not necessarily before the blocks with no priority. For the blocks with no priority set for them, Simulink uses its block sorting algorithm to sort their order relative to the blocks with priorities. In addition, Simulink honors the block priorities that you specify only if they are consistent with Simulink's block sorting algorithm. If Simulink is unable to honor a block priority, a Block Priority Violation occurs. You can specify the action Simulink should take upon block priority violations: displaying a warning message or an error message. If a warning message is to be displayed, Simulink ignores the block priority you have specified. For instance, you may have a source block with a lower priority than a sink block whose input port is driven by that source block. In this case, the source block appears before the sink block despite the fact that the sink has higher priority. If an error message is to be produced, Simulink issues an error message, which in turn prevents the model from running. In order to specify the action Simulink should take upon a block priority violation, select from the Simulink menu in the model window. Under the Diagnostics pane, the third parameter is called Block priority violation and can be used to choose between displaying a warning or an error. The figure below illustrates the aforementioned pane.
For more information on this pane, please refer to the Diagnostics Pane: Solver section in the Simulink documentation.
The recommended method of controlling the execution order is to use the Atomic Subsystem blocks rather than specifying priorities for the blocks. In the block prioritization process, you may violate the data dependency rules of Simulink and not get the execution order desired, or get an error. More importantly, it often becomes necessary to specify priorities for every block in your model in order to ensure that Simulink produces the sorted order desired, which is time consuming. Also, the sorted order has to be verified every time a block is added to the model because Simulink recomputes the execution order each time the model is changed. With Atomic Subsystem blocks, the flow of the diagram ensures the correct execution order because Simulink's data dependency rules will require the correct order. Finally, unless the sorted order is displayed, there is no visual confirmation of the execution order of the blocks as there is with the Atomic Subsystem blocks. Even when the sorted order is displayed, the numbers can be hard to read on a large diagram and blocks within a virtual subsystem are sorted along with the blocks in the parent subsystem so it is not even possible in most cases to see the execution order of all the blocks at the same time. With Atomic Subsystem blocks the execution order is readily apparent because it follows the natural flow of the diagram.
Copyright ©2024 Quanser Inc. This page was generated 2024-04-16. Submit feedback to Quanser about this page.
Link to this page.