The debugger allows you to define stopping points called breakpoints
in a simulation. You can then run a simulation from breakpoint to
breakpoint, using the debugger continue
command.
The debugger lets you define two types of breakpoints: unconditional
and conditional. An unconditional breakpoint occurs whenever a simulation
reaches a method that you specified previously. A conditional breakpoint
occurs when a condition that you specified in advance arises in the
simulation.
Breakpoints are useful when you know that a problem occurs at
a certain point in your program or when a certain condition occurs.
By defining an appropriate breakpoint and running the simulation via
the continue
command, you can skip immediately
to the point in the simulation where the problem occurs.
Note
When you stop a simulation at a breakpoint of a MATLAB® S-function in the debugger, to exit MATLAB, you must first quit the debugger.
You can set unconditional breakpoints from the:
Debugger toolbar
Simulation Loop pane
MATLAB product Command Window (command-line mode only)
To enable the Breakpoint button,
Simulate the model.
Click the Step over current method button
until simulationPhase
is highlighted.
Click the Step into current method button.
The debugger displays the name of the selected block in the Break/Display points panel of the Breakpoints pane.
Note
Clicking the Breakpoint button on the toolbar sets breakpoints on the invocations of a block's methods in major time steps.
You can temporarily disable the breakpoints on a block by deselecting the check box in the breakpoints column of the panel. To clear the breakpoints on a block and remove its entry from the panel,
Select the entry.
Click the Remove selected point button on the panel.
Note
You cannot set a breakpoint on a virtual block. A virtual block
is purely graphical: it indicates a grouping or relationship among
a model's computational blocks. The debugger warns you if you try
to set a breakpoint on a virtual block. You can get a listing of a
model's nonvirtual blocks, using the slist
command
(see Displaying a Model's Nonvirtual Blocks).
To set a breakpoint at a particular invocation of a method displayed in the Simulation Loop pane, select the check box next to the method's name in the breakpoint column of the pane.
To clear the breakpoint, deselect the check box.
In command-line mode, use the break
and bafter
commands to set breakpoints
before or after a specified method, respectively. Use the clear
command to clear breakpoints.
You can use either the Break on conditions controls group on the debugger Breakpoints pane
or the following commands (in command-line mode) to set conditional breakpoints.
This command... | Causes the Simulation to Stop... |
---|---|
tbreak [t] | At a simulation time step |
ebreak | At a recoverable error in the model |
nanbreak | At the occurrence of an underflow or overflow ( |
xbreak | When the simulation reaches the state that determines the simulation step size |
zcbreak | When a zero crossing occurs between simulation time steps |
To set a breakpoint at a time step, enter a time in the debugger Break at time field (GUI mode) or enter the
time using the tbreak
command. This causes the
debugger to stop the simulation at the Outputs.Major
method
of the model at the first time step that follows the specified time.
For example, starting vdp
in debug mode and entering
the commands
tbreak 2 continue
causes the debugger to halt the simulation at the vdp.Outputs.Major
method
of time step 2.078
as indicated by the output of
the continue
command.
%----------------------------------------------------------------% [Tm = 2.034340153847549 ] vdp.Outputs.Minor (sldebug @37):
Selecting the debugger NaN values option
or entering the nanbreak
command causes the simulation
to stop when a computed value is infinite or outside the range of
values that is supported by the machine running the simulation. This
option is useful for pinpointing computational errors in a model.
Selecting the Step size limited by state option
or entering the xbreak
command causes the debugger
to stop the simulation when the model uses a variable-step solver
and the solver encounters a state that limits the size of the steps
that it can take. This command is useful in debugging models that
appear to require an excessive number of simulation time steps to
solve.
Selecting the Zero crossings option
or entering the zcbreak
command causes the simulation
to halt when a nonsampled zero crossing is detected in a model that
includes blocks where zero crossings can arise. After halting, the
ID, type, and name of the block in which the zero crossing was detected
is displayed. The block ID (s:b:p
) consists of
a system index s
, block index b
,
and port index p
separated by colons (see Block ID).
For example, setting a zero-crossing break
at the start of execution of the zeroxing
example
model,
>> sldebug zeroxing %-------------------------------------------------------------- % [TM = 0 ] zeroxing.Simulate (sldebug @0): >> zcbreak Break at zero crossing events : enabled
and continuing the simulation
(sldebug @0): >> continue
results in a zero-crossing break at
Interrupting model execution before running mdlOutputs at the left post of (major time step just before) zero crossing event detected at the following location: 6[-0] 0:5:2 Saturate 'zeroxing/Saturation' %----------------------------------------------------------------% [TzL= 0.3435011087932808 ] zeroxing.Outputs.Major (sldebug @16): >>
If a model does not include blocks capable of producing nonsampled zero crossings, the command prints a message advising you of this fact.
Selecting the debugger Solver Errors option
or entering the ebreak
command
causes the simulation to stop if the solver detects a recoverable
error in the model. If you do not set or disable this breakpoint,
the solver recovers from the error and proceeds with the simulation
without notifying you.