|On this page…|
Using the SimEvents® debugger, you can proceed step by step in the simulation. After each step, you can inspect states or issue other commands at the sedebug>> prompt.
Stepping is appropriate if one of these is true:
You want to see what happens next in the simulation and you want frequent opportunities to inspect states as the simulation proceeds.
You want the simulation to proceed but cannot formulate a condition suitable for a breakpoint.
Note: Simulink® also provides a tool, the Simulation Stepper, that allows you to step through a model simulation. For a comparison of the SimEvents Debugger with the Simulink Simulation Stepper, see SimEvents Debugger versus Simulink Simulation Stepper.
Stepping is not the best way to proceed with the simulation in the debugger if one of these is true:
You want the simulation to proceed until it satisfies a condition that you can formulate using a breakpoint, and you do not need to enter debugging commands until the condition is satisfied. In this case, using breakpoints might require you to enter fewer commands compared to stepping; for details, see Use Breakpoints During Debugging.
You want the simulation to proceed until the end, and you do not need to enter other commands. In this case, at the sedebug>> prompt, enter runtoend instead of stepping repeatedly.
You want the simulation to proceed until the end, and you need to enter commands only at the end of the simulation. In this case, remove or disable any breakpoints you might have set earlier, and, at the sedebug>> prompt, enter cont instead of stepping repeatedly.
If you have decided that stepping is appropriate for your debugging needs, at the sedebug>> prompt, enter one of the commands in the next table. To learn about the choices for granularity of steps, see Choose the Granularity of a Step.
|If Latest Message in Simulation Log Is...||And You Want to...||At sedebug>> Prompt, Enter...|
|An independent operation (not indented)||Take the smallest possible step||step or step in|
|Skip consequences of the current operation and stop at the next independent operation that appears in the simulation log||step over|
|A dependent operation (indented)||Take the smallest possible step||step or step in or step over|
|Skip remaining consequences of the previous independent operation and stop at the next independent operation that appears in the simulation log||step out|
As a result, the simulation proceeds and the simulation log displays one or more messages to reflect the simulation progress.
Using the SimEvents debugger, you can proceed in the simulation by an amount that corresponds to one message in the simulation log, or a collection of messages. The endpoint of a step depends on these factors:
What is happening in the simulation.
As the section Interpret the Simulation Log describes, the simulation log does not use a strictly time-based, block-based, or entity-based approach to determine the messages that appear. Similarly, proceeding step by step through a simulation in the SimEvents debugger does not use a strictly time-based, block-based, or entity-based approach to determine the endpoints of the steps.
The detail settings in effect before you invoke step.
If you change the detail settings from their default values to cause the simulation log to omit entity messages or event messages, you cannot step to an operation that corresponds to an omitted message unless a breakpoint coincides with the operation. For instance, see Skip Entity Operations When Stepping.
In particular, if your detail settings cause the simulation log to omit all messages (equivalent to the detail none command), you cannot step to anything other than breakpoints.
The step size you choose when you invoke step. Choices are described, following.
The smallest possible step in the SimEvents debugger corresponds to one message in the simulation log. Taking the smallest possible step is appropriate if one of these is true:
You are not sure what the simulation will skip if you take a larger step, and you want as many opportunities as possible to inspect states as the simulation proceeds. This might be true if you are new to SimEvents software, new to the debugger, unfamiliar with the model you are debugging, or unsure where to look for a simulation problem you are trying to diagnose.
You know that if you take a larger step, the simulation will skip a point in the simulation at which you want to inspect states.
A potentially larger step in the SimEvents debugger corresponds to a series message in the simulation log. The last message in the series is not indented, while other messages in the series are indented to show that they represent consequences of an earlier operation. Taking a larger step is appropriate if one of these is true:
The current operation is not relevant to you and you want to skip over its immediate consequences.
You find it more efficient to scan a series of messages visually than enter a command interactively after viewing each message, and you do not need to inspect states at intermediate points in the larger step.
You find it easier to understand a series of related messages when all are visible, and you do not need to inspect states at intermediate points in the larger step.
Ensuring the action has happened — If you want to inspect states to confirm the effect of the action in the most recent message in the simulation log, first ensure that the action has happened. If the message uses an action statement such as "executing," use step before inspecting states. If the message uses a verb in the past tense, such as "detected," the extra step is not necessary because the action has already happened.
Clicking shortcuts — If you use a certain step command frequently, a shortcut you can click might provide an efficient way to issue the command repeatedly. To learn about shortcuts, see Create Shortcuts to Rerun Commands.
Connection between step and detail — If your detail settings cause the simulation log to omit all messages (equivalent to the detail none command), you cannot step to anything other than breakpoints. In the absence of breakpoints, a step causes the simulation to proceed until the end. If you inadvertently reach the end of the simulation in this way and want to return to the point in the simulation from which you tried to step, use information in the Command Window to set a breakpoint in a subsequent debugging session. For example, if the last message in the simulation log before you inadvertently stepped too far indicates the execution of event ev5, you can enter evbreak ev5; cont in the next debugger session.