Simulink®

Setting Breakpoints

About Breakpoints

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.

Back to Top

Setting Unconditional Breakpoints

You can set unconditional breakpoints from the:

• Debugger toolbar

• Simulation Loop pane

• MATLAB^® product Command Window (command-line mode only)

Setting Breakpoints from the Debugger Toolbar

To set a breakpoint on a block's methods, select the block and then click the Breakpoint button on the debugger toolbar. If you set a break point on a block, the debugger stops at any method that the execution reaches in the block.

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,

1. Select the entry.

2. 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).

Setting Breakpoints from the Simulation Loop Pane

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.

Setting Breakpoints from the Command Window

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.

Back to Top

Setting Conditional 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.

Setting Breakpoints at 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.078784598291364      ] vdp.Outputs.Major
(sldebug @18): 

Breaking on Nonfinite Values

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.

Breaking on Step-Size Limiting Steps

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.

Breaking at Zero Crossings

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 demo 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

2 Zero crossings detected at the following locations
  6  0:5:1  Saturate  'zeroxing/Saturation'
  7  0:5:2  Saturate  'zeroxing/Saturation'
ZeroCrossing Events detected. Interrupting model execution
%----------------------------------------------------------------%
[Tm = 0.4                    ] zeroxing.zc.SearchLoop
(sldebug @55): >>

If a model does not include blocks capable of producing nonsampled zero crossings, the command prints a message advising you of this fact.

Breaking on Solver Errors

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.

Back to Top

Running a Simulation Step by Step

Displaying Information About the Simulation