|
|
|
| R2011b Documentation → SimEvents | |
Learn more about SimEvents |
|
| Contents | Index |
| On this page… |
|---|
When the SimEvents debugger is active, the command prompt is sedebug>> instead of >>. The sedebug>> prompt reminds you that the simulation is suspended in debugging mode.
When you enter commands at the sedebug>> prompt, you can:
Invoke debugger functions using only the function names, without the package qualifier, sedb.. For example, you can enter step at the sedebug>> prompt even though the fully qualified name of the function is sedb.step.
Debugger functions that you invoke at the sedebug>> prompt are in the sedb package, so their fully qualified names start with "sedb.". You can either include or omit the sedb. prefix when entering commands at the sedebug>> prompt because the sedebug function imports the sedb package.
See a list of debugger functions by entering help with no input arguments.
At the >> prompt, the same list is available via the syntax help sedb.
When you enter commands at the sedebug>> prompt, follow these rules:
Do not append additional debugger commands on the same line as a command that causes the simulation to proceed. For example, to step twice, you must enter step on two lines instead of entering the single command step; step.
Do not invoke sedebug or sldebug.
In the sedb package, functions are valid only when the SimEvents debugger is active.
When the simulation proceeds during debugging mode, the debugger displays messages in the Command Window to indicate what is about to happen or what has just happened in the simulation. Collectively, these messages make up the simulation log. These topics describe what you see in the simulation log:
To learn how to obtain additional information via query commands, see Inspecting Entities, Blocks, and Events.
Here is a sample excerpt of the simulation log in its default configuration.
The sample highlights these typical features of messages in the simulation log:
Individual messages typically span multiple lines in the Command Window. Lines that look like %====% or %....% precede each individual message.
The first line of each message provides a summary. The phrasing of the summary indicates whether the message describes something that is about to happen or that has just happened. When you inspect states, knowing the difference is important.
| Phrasing of Summary | Examples | Interpretation |
|---|---|---|
| Action statement | Executing, scheduling, advancing, generating, and others | The action is about to happen. It has not happened yet. |
| Verb in the past tense | Detected | The action has just happened. |
Some messages include the simulation time. Messages that do not include the simulation time describe activities at the simulation time most recently included in the simulation log.
Some messages use tokens in parentheses to identify events or entities uniquely. For details, see Identifiers in the Debugger.
Some messages are indented to indicate operations that are consequences of other operations. For details, see Independent Operations and Consequences in the Debugger.
Block names are underlined and act as hyperlinks.
If you click the path, the model window opens and highlights the block. To clear the highlighting, select View > Remove Highlighting.
You can configure the debugger to list the events on the event calendar, as part of the simulation log. Event calendar listings appear before execution messages. The following illustration is a sample event calendar listing.
The event calendar display spans multiple lines in the Command Window. A line that looks like %----% precedes the event calendar display.
Each listing in the event calendar display includes these event characteristics:
Discrete-event system identifier, which identifies the discrete-event system during the debugger session. See Discrete-Event Simulation Using SimEvents in Simulink Models for more information on discrete-event systems.
Event identifier, which is a token that identifies the event uniquely during the debugger session. For details, see Identifiers in the Debugger.
Scheduled time of the event.
Event type. For details, see Supported Events in SimEvents Models.
Event priority. The value can be a number, SYS1, or SYS2. For details, see Event Sequencing or Overview of Simultaneous Events.
Entity identifier of an entity associated with the event, if applicable. If no entity is associated with the event, <none> appears.
Partial path of the block that processes the event when it occurs. The partial path omits the name of the model, but is otherwise the same as the full path of the block.
Block paths are underlined and act as hyperlinks.
If you click the path, the model window opens and highlights the block. To clear the highlighting, select View > Remove Highlighting.
When comparing the simulation log with the event calendar display, the sequence on the calendar and the sequence in which the events were scheduled might differ, even for simultaneous events that have equal priority. For details, see Procedure for Specifying Equal-Priority Behavior.
To learn how to configure the debugger to show event calendar displays, see Customizing the Debugger Simulation Log.
The most recent message in the simulation log shows you the simulation status while the debugger is waiting for you to enter the next command. When you inspect states, if the phrasing of the summary uses an action statement to indicate that the action has not happened yet, the state does not reflect the completion of the action. For example, if the most recent message in the simulation log indicates that a server block is scheduling a service completion event, the scheduling has not occurred yet and the evcal function does not list the event on the event calendar. If you want to see where the event is on the event calendar relative to other scheduled events, you must proceed in the simulation by one step and then call evcal.
The simulation log shows you what is happening during the simulation. When you simulate in debugging mode, the actions in the simulation log are the units of debugging behavior. By using the debugger on those units of debugging behavior, you can control the simulation process and query simulation behavior. When you proceed in the simulation step by step, the simulation is suspended before or after the actions that the simulation log reports.
By contrast, some approaches that the simulation log does not intend to reflect are:
A block-by-block simulation process. In a discrete-event simulation, a block can take multiple actions at a given time, potentially interspersed with actions of other blocks. Alternatively, a block can take no action for long periods of time, even while other blocks in the system are active. Messages in the simulation log might not be in the same sequence that you see in the topology of the block diagram, even if the topology of the block diagram is linear.
An entity-by-entity simulation process. An entity can advance through multiple blocks or can be the object of multiple actions at a given time, potentially interspersed with actions on other entities. Alternatively, an entity can go for long periods of time without moving, changing, or affecting anything else in the simulation, even while other entities in the system are active.
One message per time value. In a discrete-event simulation, many actions can occur at the same time. Therefore, the debugger lets you query simulation behavior at intermediate points.
The view into simulation behavior is useful during debugging because the simulation log reflects what is happening during the simulation. When you see what is happening, you can diagnose problems, explore solutions, improve your modeling proficiency, and learn about the underlying system that you are modeling.
When the event calendar is about to change during a debugging session, the simulation log displays a message that describes the event that the block is about to schedule, execute, or cancel. The event calendar has not yet changed.
When a block is about to execute a subsystem, function call, memory read, or memory write event that is not on the event calendar, the simulation log displays a message that describes the event. The execution, which is a dependent operation, has not yet occurred.
Sample Scheduling Message
The following sample shows that the Single Server block is about to add a service completion event to the event calendar. The event has priority 500, a scheduled time of T=5, and identifier ev3. The event represents the completion of service on the entity whose identifier is en2.
%..........................................................................%
Scheduling ServiceCompletion Event (ev3)
: EventTime = 5.000000000000000
: Priority = 500
: Entity = en2
: Block = Single ServerSample Independent Execution Message
The following sample shows that the Single Server block is about to execute the service completion event for the entity whose identifier is en2. The event time of T=5 equals the current simulation time. The event has priority 500, which is relevant if multiple events on the event calendar share the same event time. The event identifier is ev3.
%==============================================================================% Executing ServiceCompletion Event (ev3) Time = 5.000000000000000 : Entity = en2 Priority = 500 : Block = Single Server
Sample Cancelation Message
The following sample shows that the Single Server block is about to cancel the service completion event for the entity whose identifier is en2, because the entity has timed out. The service completion event has priority 500 and identifier ev4.
%==============================================================================%
Executing Timeout Event (ev3) Time = 1.000000000000000
: Entity = en2 Priority = 1700
: Block = Single Server
%..........................................................................%
Canceling ServiceCompletion Event (ev4)
: EventTime = 5.000000000000000
: Priority = 500
: Entity = en2
: Block = Single ServerFor more information, see Event Sequencing and Example: Event Calendar Usage for a Queue-Server Model.
Reactive ports, listen for relevant updates in the input signal and cause an appropriate reaction in the block possessing the port. For a list of reactive ports, see Notifying, Monitoring, and Reactive Ports. When labeled reactive ports detect relevant updates during a debugging session, the simulation log displays a message whose summary starts with Detected. These messages indicate that the update in the signal has happened and that the block has detected it. The block has not yet responded to the update. The response depends on the particular block. For details, see individual block reference pages.
The appearance of detection messages depends on their source:
If the input signal is time-based and enters the discrete-event system through the Timed to Event Signal gateway block, the update is an independent operation and the detection message is not indented. This kind of detection message is one of the few ways in which time-based blocks affect the simulation log.
If the input signal is event-based, the update is a dependent operation and the detection message is indented.
Note If a port not in the list of reactive ports, such as the function() input port of a Function-Call Subsystem block, detects a trigger or function call, the simulation log does not display a detection message. |
Sample Detection Message
The following sample shows a detection message that indicates that the Event-Based Entity Generator block has detected that its input signal changed to a new value of 1 from a previous value of 0. Because the block is configured to respond to rising value changes, the signal update is relevant. The block responds by scheduling an entity generation event for the current simulation time (denoted by Now).
%..........................................................................%
Detected Rising Value Change
: NewValue = 1
: PrevValue = 0
: Block = Event-Based Entity Generator
%..........................................................................%
Scheduling EntityGeneration Event (ev2)
: EventTime = 0.000000000000000 (Now)
: Priority = SYS1
: Block = Event-Based Entity GeneratorVarious blocks produce messages in the simulation log that describe how the block are about to impact entities. The details of entity operation messages depend on what information is relevant for the particular block and operation.
Sample Entity Advancement Message
An entity whose identifier is en2 is about to depart from the Schedule Timeout block and arrive at the Single Server block. The entity has not yet advanced.
%..........................................................................%
Entity Advancing (en2)
: From = Schedule Timeout
: To = Single ServerSample Queuing Message
A FIFO Queue block places entity en4 in the third position. Two other entities are ahead en4 in the queue, which has a total capacity of 25.
%..........................................................................%
Queuing Entity (en4)
: FIFO Pos = 3 of 3
: Capacity = 25
: Block = FIFO QueueSample Attribute Assignment Message
A Set Attribute block assigns the value 3 to the attribute named RepCount of entity en1.
%..........................................................................%
Setting Attribute on Entity (en1)
: RepCount = 3
: Block = Set AttributeSample Preemption Message
When a preemption occurs, a Single Server block replaces entity en1 with entity en4, based on values of the entities' PriorityAttributeName attribute.
%..........................................................................%
Preempting Entity (en1)
: NewEntity = en4 (PriorityAttributeName = 1)
: OldEntity = en1 (PriorityAttributeName = 2)
: Block = Single Server1Sample Entity Replication Message
A Replicate block replicates entity en1 to produce entity en2.
%..........................................................................%
Replicating Entity (en1)
: Replica 1 of 2 = en2
: Block = ReplicateSample Entity Destruction Message
An Entity Sink block destroys entity en1.
%..........................................................................%
Destroying Entity (en1)
: Block = Entity SinkWhen a block is about to react to an update in a signal at a monitoring port, the block produces a message in the simulation log.
Sample Scope Message
A Signal Scope block updates its plot.
%..........................................................................%
Executing Scope
: Block = Signal Scope
Sample Workspace Message
A Discrete-Event Signal to Workspace block receives a new data value. The workspace variable is available only after the debugger session ends.
%..........................................................................%
Executing Discrete-Event Signal To Workspace
: Block = Discrete Event Signal to WorkspaceEarly in the debugging session, the debugger indicates initialization activities.
| Message | Description |
|---|---|
| Initializing Model sedemo_timeout | Appears when the debugging session starts and the model is in the initialization stage. |
| Initializing Time-Based Entity Generators | Appears after the model initialization, if the model contains at least one Time-Based Entity Generator block. Initializing a Time-Based Entity Generator block means scheduling its first entity generation event. |
Various blocks produce signal operation messages.
Sample Signal Update Detection Message
A sample time hit is detected in the Initial Value block.
Detected Sample Time Hit
: Block = Receiver/Initial ValueSample Executing Signal Block Message
A signal operation is being performed in the Gain block, which is a time-based block in the event-based system:
Executing Signal Block
: Block = GainThe debugger detects the execution of time-based blocks in event-based systems.
| Message | Description |
|---|---|
| Executing Signal Block | Appears when the debugger detects the start of execution of such a block. |
The simulation log uses tokens to identify blocks, entities, events on the event calendar, and breakpoints uniquely during the debugger session. When requesting information about blocks, entities, or events, or when manipulating breakpoints, you use these identifiers as input arguments.
If you repeat a debugging session in the same version of MATLAB without changing the model structure or parameters, all identifiers of blocks, entities, and events are the same from one session to the next.
This table summarizes the notation for identifiers.
| Type of Identifier | Prefix of Identifier | Example |
|---|---|---|
| Block | blk | blk1 |
| Entity | en | en2 |
| Event | ev | ev3 |
| Breakpoint | b | b4 |
In displays of state information in the debugger, the abbreviation ID refers to an identifier.
Note Discrete-event systems do not have identifiers. The debugger refers to discrete-event systems with numeric values, such as Discrete-Event System ID: 0. See Discrete-Event Simulation Using SimEvents in Simulink Models for more information on discrete-event systems. |
For more information about identifiers, see Inspecting Entities, Blocks, and Events and Using Breakpoints During Debugging.
 | Starting the SimEvents Debugger | Independent Operations and Consequences in the Debugger |  |
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 |