Simulation Log in the Debugger

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 Inspect Entities, Blocks, and Events.

Key Parts of the Simulation Log

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 SummaryExamplesInterpretation
    Action statementExecuting, scheduling, advancing, generating, and othersThe action is about to happen. It has not happened yet.
    Verb in the past tenseDetectedThe 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 Display > Remove Highlighting.

Optional Displays of Event Calendar in the Simulation Log

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 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 Events in SimEvents Models.

  • Event priority. The value can be a number, SYS1, or SYS2. For details, see Event Sequencing or 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 Display > 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 Customize the Debugger Simulation Log.

Interpret the 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.

Event Scheduling, Execution, and Cancelation Messages

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 Server

Sample 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 Server

For more information, see Event Sequencing and Event Calendar Usage for Queue-Server Model.

Detection Messages

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 Generator

Entity Operation Messages

Various 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 Server

Sample 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 Queue

Sample 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 Attribute

Sample 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 Server1

Sample Entity Replication Message

A Replicate block replicates entity en1 to produce entity en2.

    %..........................................................................%
    Replicating Entity (en1)
    : Replica 1 of 2 = en2
    : Block = Replicate

Sample Entity Destruction Message

An Entity Sink block destroys entity en1.

    %..........................................................................%
    Destroying Entity (en1)
    : Block = Entity Sink

Monitoring Block Messages

When 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 Workspace

Initialization Messages

Early in the debugging session, the debugger indicates initialization activities.

MessageDescription
Initializing Model sedemo_timeoutAppears when the debugging session starts and the model is in the initialization stage.
Initializing Time-Based Entity GeneratorsAppears 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.

Signal Operation Messages

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 Value

Sample 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 = Gain

Execution of Time-Based Blocks in Event-based Systems Block Messages

The debugger detects the execution of time-based blocks in event-based systems.

MessageDescription
Executing Signal BlockAppears when the debugger detects the start of execution of such a block.

Was this topic helpful?