| Products & Services | Solutions | Academia | Support | User Community | Company |
| Download Product Updates | | | Get Pricing | | | Trial Software |
| Documentation → SimEvents |
| Contents | Index |
| Learn more about SimEvents |
| On this page… |
|---|
One way that you can see details about which events occur simultaneously and the sequence in which the application processes them is by running the simulation with the SimEvents debugger. The debugger displays messages in the Command Window to indicate what is happening in the simulation, and lets you inspect states at any point where the debugger suspends the simulation. You might still need to infer some aspects of the simulation behavior that do not appear in the Command Window messages.
Tips for how you can use the debugger to explore simultaneous events, where the commands mentioned are valid at the sedebug>> prompt of the debugger, are:
If you want to view the event calendar at any point in the simulation, enter evcal.
If all the events you want to explore are on the event calendar and you are not interested in entity operations, enter detail('en',0). The simulation log no longer issues messages about entity operations and the step function ignores entity operations.
The opposite command is detail('en',1), which causes the simulation log to include messages about entity operations and makes it possible for step to suspend the simulation at an entity operation.
If you want to see everything that happens at a particular time, use a pair of timed breakpoints, as in Using Nearby Breakpoints to Focus on a Particular Time.
If you want to proceed in the simulation until it executes or cancels a particular event that is on the event calendar, find the event identifier (using evcal or the simulation log), use the event identifier in an evbreak command, and then enter cont.
An event breakpoint is not the same as a timed breakpoint whose value equals the scheduled time of the event. The two breakpoints can cause the simulation to stop at different points if the execution or cancelation of the event is not the first thing that happens at that value of time. For an example, see the sedb.evbreak reference page.
The simulation log indicates the sequence of simultaneous events, but you might still have questions about why events are in that sequence. Referring to earlier messages in the simulation log might help answer your questions. If not, you might need to run the simulation again and inspect states at earlier points in the simulation. Debugging is often an iterative process.
Create a timed breakpoint at the time that you are interested in. For example, if you are interested in what happens at T=3, at the sedebug>> prompt, enter this command:
tbreak(3)
Enter cont to reach the breakpoint from step 1.
If the time that you specified in step 1 is an earlier approximation of the actual time at which something interesting happens, the simulation might stop at a time later than the time of the breakpoint. For example, suppose you guess T=3 from looking at a plot, but the actions of interest really occur at T=3.0129. In this case, having the simulation stop at T=3.0129 is desirable if nothing happens in the simulation at exactly T=3.
Create a timed breakpoint shortly after the current simulation time, by entering:
tbreak(simtime + 128*eps*simtime)
Enter cont to reach the next breakpoint. The portion of the simulation log between the last two cont commands contains the items of interest.
Overview of the SimEvents Debugger — More information about the debugger
Example: Choices of Values for Event Priorities — An example that explores simultaneous events and illustrates interpreting the debugger simulation log
![]() | Overview of Simultaneous Events | Choosing an Approach for Simultaneous Events | ![]() |

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 |