| Contents | Index |
| On this page… |
|---|
Running the Simulation Until the Next Breakpoint |
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 Defining a Breakpoint. To proceed in the simulation until the debugger reaches the next breakpoint, at the sedebug>> prompt, enter this command:
cont
You cannot set breakpoints for 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 Relevant 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 Relevant 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 | disable b1, where b1 is the breakpoint identifier | The list of breakpoints indicates the breakpoint as disabled and the debugger does not observe the breakpoint. You can reverse this operation using enable b1. |
| Ignore a particular breakpoint without keeping it in the list of breakpoints and without being able to reinstate it easily | bdelete b1, where b1 is the breakpoint identifier | 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 | runtoend | The simulation runs to completion and the debugger session ends. |
To view breakpoint identifiers, at the sedebug>> prompt, enter breakpoints.
Tip You can apply disable, enable, or bdelete to multiple breakpoints in one command by using all or a cell array as an input argument. For exact syntax, see the reference page for each function. |
To reinstate a breakpoint that you previously disabled:
View breakpoint identifiers. At the sedebug>> prompt, enter this command:
breakpoints
Enter a command like the following, replacing b1 with the identifier of the breakpoint that you want to reinstate:
enable b1
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.
![]() | Defining a Breakpoint | Block Operations Relevant for Block Breakpoints | ![]() |

Model electronic system architectures, process flows, and logistics as queuing systems or agent-based systems.
Get free kit| © 1984-2012- The MathWorks, Inc. - Site Help - Patents - Trademarks - Privacy Policy - Preventing Piracy - RSS |