|
|
|
| R2011b Documentation → SimEvents | |
Learn more about SimEvents |
|
| Contents | Index |
| On this page… |
|---|
In the SimEvents debugger, a breakpoint is a point of interest in the simulation at which the debugger can suspend the simulation and let you enter commands. You decide which points are of interest to you and then use debugger functions to designate those points as debugging breakpoints. After you define one or more breakpoints, you can use them to control the simulation process efficiently. At the sedebug>> prompt, the cont command causes the simulation to proceed until the next breakpoint, bypassing points that you are not interested in and letting you inspect states at a point of interest. To learn more about controlling the simulation after defining breakpoints, see Using Breakpoints During Debugging.
Before defining a breakpoint, you must decide what points in the simulation you want to inspect and then determine a way to refer to the point explicitly when invoking a function to define a breakpoint. The SimEvents debugger supports the following kinds of breakpoints.
| Type of Breakpoint | Debugger Suspends Simulation Upon... | When You Might Use Breakpoint Type |
|---|---|---|
| Timed breakpoint | First operation whose associated time is equal to or greater than the value of the timed breakpoint |
|
| Event breakpoint | Execution or cancelation of the specified event | An event on the event calendar is a point of interest |
| Block breakpoint | Operation involving the specified block, for blocks that support block breakpoints |
|
| Entity breakpoint | Operation that involves the specified entity | An operation that involves the entity is a point of interest |
You cannot set a breakpoint for a Simulink controlled block. Instead, set the breakpoint in the SimEvents block that initiates the signal execution.
To see a list of all events on the event calendar and their event identifiers, at the sedebug>> prompt, enter evcal.
To see a list of blocks in the model that support block breakpoints, at the sedebug>> prompt, enter blklist. The list also shows the block identifiers. (Note, the blklist output also contains the list of time-based blocks in event-based systems. These blocks do not support blkbreak.) For a list of block operations at which the debugger can suspend the simulation, see Block Operations Relevant for Block Breakpoints.
To proceed in the simulation by a fixed amount of time, define a timed breakpoint whose value is relative to the current simulation time using syntax such as tbreak(simtime + fixed_amount). For an example, see the sedb.simtime reference page.
To see a list of all entities and their IDs in a storage block, use blkinfo. Use these IDs to set entity breakpoints.
To investigate the behavior of a block only during particular time intervals, use a combination of timed breakpoints and block breakpoints. During a time interval of interest, the block breakpoint helps you investigate the behavior of the block. When the simulation advances beyond that time interval, you can disable the block breakpoint and use a timed breakpoint to advance to another time interval of interest. To learn more about disabling breakpoints, see Ignoring or Removing Breakpoints.
To see all actions that happen at a particular time, use a pair of timed breakpoints, as in Using Nearby Breakpoints to Focus on a Particular Time.
You might need or want to iteratively refine your points of interest across multiple simulation runs. For example:
A plot of a signal against time might indicate when something of interest to you happens in the simulation. You can read the approximate time from the plot. You can use the approximate time when defining a timed breakpoint in a subsequent run of the simulation.
You can use a pair of timed breakpoints to examine simulation behavior in a time interval and find a relevant event on the event calendar. You can use the event identifier when defining an event breakpoint in a subsequent run of the simulation.
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.
After you have identified a point of interest, you can set a breakpoint by entering one of the commands in the table.
| Type of Breakpoint | At sedebug>> Prompt, Enter... |
|---|---|
| Timed breakpoint at simulation time T = t0 | tbreak(t0) or tbreak t0 |
| Event breakpoint at event whose identifier is the string, evid | evbreak(evid) |
| Block breakpoint at block whose identifier is the string, blkid, or whose path name is the string, blkname | blkbreak(blkid) or blkbreak(blkname) |
| Entity breakpoint at entity whose identifier is the string, enid | enbreak(enid) |
The debugger warns you if it determines that it might not hit the breakpoint that you want to define or if it does not recognize an event identifier that you specify. The warning can alert you to a mistake in your command, but might also follow a correct command. For example, suppose you obtain an event identifier during one run of the simulation and set an event breakpoint on that event in a subsequent run of the simulation, before the event has been scheduled. Setting an event breakpoint before the event has been scheduled is legitimate because event identifiers are the same from one debugging session to the next. However, the debugger cannot distinguish this situation from a mistake in your input argument to evbreak.
If you often intentionally set breakpoints that cause this warning and you want to suppress such warnings in the future, enter warning off last immediately after the warning occurs. For more information about this command, see Warning Control.
To see a tabular display of all breakpoints that you have set, at the sedebug>> prompt, enter this command:
breakpoints
The output includes this information about each breakpoint.
| Label | Description |
|---|---|
| ID | A token that uniquely identifies the breakpoint |
| Type | Block, Event, Timed, or Entity |
| Value | The block identifier of a block breakpoint |
| The event identifier of an event breakpoint | |
| The time of a timed breakpoint | |
| The ID of the entry | |
| Enabled | yes, if the debugger considers the breakpoint when determining where to suspend the simulation |
| no, if the debugger ignores the breakpoint |
The list of breakpoints does not guarantee that the simulation reaches each point before the simulation ends. The sequence of breakpoints in the list does not necessarily represent the sequence in which the simulation reaches each point.
The list of breakpoints does not show a special built-in breakpoint that the debugger always observes at the end of the simulation. You do not set this breakpoint explicitly and you cannot disable or remove it.
Sample Breakpoint List
The sample output of breakpoints shows six breakpoints. Two are timed breakpoints, one is an entity, one is an event breakpoint, and two are block breakpoints. One of the block breakpoints is disabled.
List of Breakpoints: ID Type Value Enabled b1 Event ev4 yes b2 Block blk11 yes b3 Timed 100 yes b4 Timed 101 yes b5 Block blk15 no b6 Entity en3 yes
To learn how to delete or disable breakpoints in the list, see Ignoring or Removing Breakpoints.
To learn how to enable breakpoints in the list, see Enabling a Disabled Breakpoint.
 | Debugger Efficiency Tips | Using Breakpoints During Debugging |  |
Learn how you can use SimEvents discrete-event simulation capabilities through these technical resources.
Get free kit| © 1984-2012- The MathWorks, Inc. - Site Help - Patents - Trademarks - Privacy Policy - Preventing Piracy - RSS |