By default, the debugger has a special built-in breakpoint at
the end of the simulation. You can define your own breakpoints, as
described in Define a Breakpoint.
To proceed in the simulation until the debugger reaches the next breakpoint,
sedebug>> prompt, enter this command:
You cannot set breakpoints for a Simulink® controlled block. Instead, set the breakpoint in the SimEvents® block that initiates the signal execution.
When you enter a
cont command, the debugger
proceeds in the simulation until it reaches the first point in the
simulation that meets one of these criteria:
At or after specified time — The simulation time is equal to or greater than the specified time of a timed breakpoint, and the point in the simulation corresponds to an operation that the simulation log is able to show.
If no event executions or relevant updates in signals at reactive ports occur at the specified time of a timed breakpoint, the debugger reaches that breakpoint when the simulation time is strictly later. For example, if time-based blocks in a hybrid simulation have a discrete sample time of 1 and running the simulation without breakpoints causes the simulation log to report operations only at T = 0, 2, 4,..., then a timed breakpoint at T = 3 is equivalent to a timed breakpoint at T = 4.
At execution or cancelation — The simulation is about to execute or cancel the specified event of an event breakpoint.
At operation of a block — The block associated with a block breakpoint is about to perform an operation that the simulation log is able to show. For a list of block operations at which the debugger can suspend the simulation, see Block Operations for Block Breakpoints.
At operation on an entity — The block associated with a entity breakpoint is about to perform an operation that the simulation log is able to show. For a list of entity operations at which the debugger can suspend the simulation, see Block Operations for Block Breakpoints.
At end — The simulation is about to end. This condition corresponds to the built-in breakpoint at the end of the simulation.
The debugger reaches a given timed or event breakpoint zero or one time during the simulation. The debugger can reach a given block or entity breakpoint an arbitrary number of times during the simulation.
Unless all breakpoints are timed breakpoints, you might not be able to predict which breakpoint the debugger reaches next. Even though events have scheduled times, the debugger might reach an event breakpoint upon the cancelation of an event. You might not be able to predict the cancelation.
The table describes options for preventing the debugger from observing a particular breakpoint.
|Treatment of Breakpoints||At sedebug>> Prompt, Enter...||Result|
|Ignore a particular breakpoint while keeping it in the list of breakpoints and being able to reinstate it easily||The list of breakpoints indicates the breakpoint as disabled
and the debugger does not observe the breakpoint. You can reverse
this operation using |
|Ignore a particular breakpoint without keeping it in the list of breakpoints and without being able to reinstate it easily||The breakpoint no longer appears in the list of breakpoints, so the debugger does not observe it.|
|Ignore all timed and event breakpoints and run the simulation until the end||The simulation runs to completion and the debugger session ends.|
To view breakpoint identifiers, at the
To reinstate a breakpoint that you previously disabled:
View breakpoint identifiers. At the
enter this command:
Enter a command like the following, replacing
the identifier of the breakpoint that you want to reinstate:
You might want to disable and enable a breakpoint to focus on behavior of a block during a particular time interval. A block breakpoint helps you focus on that block. Disabling the block breakpoint, when the simulation time is outside the time interval of interest, helps you focus on only those periods that are relevant to you.