Define a Breakpoint

What Is a Breakpoint?

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 Use Breakpoints During Debugging.

Identify a Point of Interest

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 BreakpointDebugger Suspends Simulation Upon...When You Might Use Breakpoint Type
Timed breakpointFirst operation whose associated time is equal to or greater than the value of the timed breakpoint
  • You know a time at which something of interest to you occurs

  • You want to proceed in the simulation by a fixed amount of time

  • A point of interest is not associated with an event on the event calendar or a block in the model

  • You do not have an event identifier to use to define an event breakpoint

Event breakpointExecution or cancelation of the specified eventAn event on the event calendar is a point of interest
Block breakpointOperation involving the specified block, for blocks that support block breakpoints
  • You want to understand how a block behaves

  • A block seems to cause or reflect the problem you are investigating

Entity breakpointOperation that involves the specified entityAn 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.

Tips for Identifying Points of Interest

  • 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 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 Ignore or Remove 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.

Set a Breakpoint

After you have identified a point of interest, you can set a breakpoint by entering one of the commands in the table.

Type of BreakpointAt sedebug>> Prompt, Enter...
Timed breakpoint at simulation time T = t0tbreak(t0) or tbreak t0
Event breakpoint at event whose identifier is the string, evidevbreak(evid)
Block breakpoint at block whose identifier is the string, blkid, or whose path name is the string, blknameblkbreak(blkid) or blkbreak(blkname)
Entity breakpoint at entity whose identifier is the string, enidenbreak(enid)

Warning When Setting Certain Breakpoints

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 Issue Warnings and Errors.

View All Breakpoints

To see a tabular display of all breakpoints that you have set, at the sedebug>> prompt, enter this command:


The output includes this information about each breakpoint.

IDA token that uniquely identifies the breakpoint
TypeBlock, Event, Timed, or Entity
ValueThe block identifier of a block breakpoint
The event identifier of an event breakpoint
The time of a timed breakpoint
The ID of the entry
Enabledyes, 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 Ignore or Remove Breakpoints.

To learn how to enable breakpoints in the list, see Enable a Disabled Breakpoint.

Was this topic helpful?