|On this page…|
You can connect the output of a block directly or indirectly (i.e., via other blocks) to its input, thereby, creating a loop. Loops can be very useful. For example, you can use loops to solve differential equations diagrammatically (see Model a Continuous System) or model feedback control systems. However, it is also possible to create loops that cannot be simulated. Common types of invalid loops include:
Loops that create invalid function-call connections or an attempt to modify the input/output arguments of a function call (see Create a Function-Call Subsystem for a description of function-call subsystems)
Self-triggering subsystems and loops containing non-latched triggered subsystems (see Create a Triggered Subsystem in the Using Simulink® documentation for a description of triggered subsystems and Inport in the Simulink reference documentation for a description of latched input)
Loops containing action subsystems
The Subsystem Examples block library in the Ports & Subsystems library contains models that illustrates examples of valid and invalid loops involving triggered and function-call subsystems. Examples of invalid loops include the following models:
You might find it useful to study these examples to avoid creating invalid loops in your own models.
To detect whether your model contains invalid loops, select Update Diagram from the model's Simulation menu. If the model contains invalid loops, the invalid loops are highlighted. This is illustrated in the following model (openopen),
and displays an error message in the Diagnostic Viewer.
If there are two Model files with the same name (e.g. mylibrary.slx) on the MATLAB® path, the one higher on the path is loaded, and the one lower on the path is said to be "shadowed".
The rules Simulink software uses to find Model files are similar to those used by MATLAB software. See "How the Search Path Determines Which Function to Use" in the MATLAB documentation. However, there is an important difference between how Simulink block diagrams and MATLAB functions are handled: a loaded block diagram takes precedence over any unloaded ones, regardless of its position on the MATLAB path. This is done for performance reasons, as part of the Simulink software's incremental loading methodology.
The precedence of a loaded block diagram over any others can have important implications, particularly since a block diagram can be loaded without the corresponding Simulink window being visible.
When using libraries and referenced models, a block diagram may be loaded without showing its window. If the MATLAB path or the current MATLAB folder changes while block diagrams are in memory, these block diagrams may interfere with the use of other files of the same name. For example, after a change of folder, a loaded but invisible library may be used instead of the one the user expects.
To see an example:
Enter sldemo_hydcyl4 to open the Simulink model sldemo_hydcyl4.
Use the find_system command to see which block diagrams are in memory:
find_system('type','block_diagram') ans = 'hydlib' 'sldemo_hydcyl4'
Note that a Simulink library, hydlib, has been loaded, but is currently invisible.
Now close sldemo_hydcyl4. Run the find_system command again, and you will see that the library is still loaded.
If you change to another folder which contains a different library called hydlib, and try to run a model in that folder, the library in that folder would not be loaded because the block diagram of the same name in memory takes precedence. This can lead to problems including:
"Unresolved Link" icons on blocks that are library links
To prevent these conditions, it is necessary to close the library explicitly as follows:
Then, when the Simulink software next needs to use a block in a library called hydlib it will use the file called hydlib.slx which is highest on the MATLAB path at the time. Alternatively, to make the library visible, enter:
When updating a block diagram, the Simulink software checks the position of its file on the MATLAB path and will issue a warning if it detects that another file of the same name exists and is higher on the MATLAB path. The warning reads:
The file containing block diagram 'mylibrary' is shadowed by a file of the same name higher on the MATLAB path.
This may indicate that the wrong file called mylibrary.slx is being used. To see which file called mylibrary.slx is loaded into memory, enter:
which mylibrary C:\work\Model1\mylibrary.slx
To see all the files called mylibrary which are on the MATLAB path, including MATLAB scripts, enter:
which -all mylibrary C:\work\Model1\mylibrary.slx C:\work\Model2\mylibrary.slx % Shadowed
To close the block diagram called mylibrary and let the Simulink software load the file which is highest on the MATLAB path, enter:
In general, more memory will increase performance.
More complex models often benefit from adding the hierarchy of subsystems to the model. Grouping blocks simplifies the top level of the model and can make it easier to read and understand the model. For more information, see Create a Subsystem. The Model Browser provides useful information about complex models (see Model Browser).
Well organized and documented models are easier to read and understand. Signal labels and model annotations can help describe what is happening in a model. For more information, see Signal Names and Labels and Annotations.
If several of your models tend to use the same blocks, you might find it easier to save these blocks in a model. Then, when you build new models, just open this model and copy the commonly used blocks from it. You can create a block library by placing a collection of blocks into a system and saving the system. You can then access the system by typing its name in the MATLAB Command Window.
Generally, when building a model, design it first on paper, then build it using the computer. Then, when you start putting the blocks together into a model, add the blocks to the model window before adding the lines that connect them. This way, you can reduce how often you need to open block libraries.