Learn more about Simulink

General Considerations when Building Simulink Models

On this page…
Avoiding Invalid Loops Shadowed Files Model Building Tips

Avoiding Invalid Loops

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 Modeling 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 Function-Call Subsystems for a description of function-call subsystems)

• Self-triggering subsystems and loops containing non-latched triggered subsystems (see Triggered Subsystems 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:

• simulink/Ports&Subsystems/sl_subsys_semantics/Triggered subsystem/sl_subsys_trigerr1 (sl_subsys_trigerr1)

• simulink/Ports&Subsystems/sl_subsys_semantics/Triggered subsystem/sl_subsys_trigerr2 (sl_subsys_trigerr2)

• simulink/Ports&Subsystems/sl_subsys_semantics/Function-call systems/sl_subsys_fcncallerr3 (sl_subsys_fcncallerr3)

You might find it useful to study these examples to avoid creating invalid loops in your own models.

Detecting Invalid Loops

To detect whether your model contains invalid loops, select Update Diagram from the model's Edit menu. If the model contains invalid loops, the invalid loops are highlighted. This is illustrated in the following model (open),

and displays an error message in the Simulation Diagnostics Viewer.

Back to Top

Shadowed Files

If there are two Model files with the same name (e.g. mylibrary.mdl) 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.

Making Sure the Correct Block Diagram Is Loaded

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:

1. Enter sldemo_hydcyl4 to open the Simulink demo model sldemo_hydcyl4.

2. 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.

3. 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:

• Simulation errors

• "Bad Link" icons on blocks which are library links

• Wrong results

To prevent these conditions, it is necessary to close the library explicitly as follows:

close_system('hydlib')

Then, when the Simulink software next needs to use a block in a library called hydlib it will use the file called hydlib.mdl which is highest on the MATLAB path at the time. Alternatively, to make the library visible, enter:

open_system('hydlib')

Detecting and Fixing Problems

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.mdl is being used. To see which file called mylibrary.mdl is loaded into memory, enter:

 which mylibrary

C:\work\Model1\mylibrary.mdl

To see all the files called mylibrary which are on the MATLAB path (note that this can include M-files), enter:

which -all mylibrary

C:\work\Model1\mylibrary.mdl
C:\work\Model2\mylibrary.mdl  % Shadowed

To close the block diagram called mylibrary and let the Simulink software load the file which is highest on the MATLAB path, enter:

close_system('mylibrary')

Back to Top

Model Building Tips

Here are some model-building hints you might find useful:

• Memory issues

  In general, more memory will increase performance.

• Using hierarchy

  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 Creating Subsystems. The Model Browser provides useful information about complex models (see The Model Browser).

• Cleaning up models

  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 Naming Signals and Annotating Diagrams.

• Modeling strategies

  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.

Back to Top

Modeling Best Practices

Modeling a Continuous System

© 1984-2010- The MathWorks, Inc.    -   Site Help   -   Patents   -   Trademarks   -   Privacy Policy   -   Preventing Piracy   -   RSS