| Version 1.2 (R2006b) SimEvents® Software Release Notes | |
This table summarizes what's new in Version 1.2 (R2006b):
| New Features and Changes | Version Compatibility Considerations | Fixed Bugs and Known Problems | Related Documentation at Web Site |
|---|---|---|---|
| Yes Details below | Yes—Details labeled as Compatibility Considerations, below. See also Summary. | Bug Reports Includes fixes | No |
New features and changes introduced in this version are
The new Event-Based Sequence block provides data to an event-driven process by producing a scalar event-based output signal whose values come from a vector. The block selects the next value from the vector upon each notification from a port of a subsequent block. For example, if you connect the Event-Based Sequence block to the t input port of a Single Server block, the values in the vector become the service times for the entities arriving at the server. You provide the values in the vector, but do not need to know in advance when the entities arrive at the server.
Version 1.2 (R2006b) introduces these new demonstration models:
Tutorial Demos
Application Demos
The Signal-Based Event to Function-Call Event block can delay its generation of a function call by an amount of time that you specify using either an input signal or the Function-call time delay parameter. In V1.1 (R2006a), the block lets you specify the delay amount using the parameter, but not an input signal.
To access the new feature, select Specify event priority for function-call generation (or, in V2.0 (R2007a), select Resolve simultaneous signal updates according to event priority). Then set the new Function-call delay from parameter to Signal port t, as shown. Then connect a nonnegative-valued signal to the t signal input port that appears on the block.
If you save a model containing the Signal-Based Event to Function-Call Event or Discrete Event Subsystem block using V1.2 (R2006b), then opening the model in V1.1 (R2006a) produces warnings like these:
Warning: In instantiating linked block 'mysys/Signal-Based Event to Function-Call Event' : Signal-Based Event to Function- Call Event block (mask) does not have a parameter named 'FunctionCallDelayFrom'.
Saving the model in the earlier version prevents the warnings from reappearing, but causes the Signal-Based Event to Function-Call Event block to omit the t input port if you later open the model in V1.2 (R2006b).
The Number of entity input ports parameter of the Input Switch and Path Combiner blocks can be any positive integer. The Number of entity output ports parameter of the Output Switch and Replicate blocks also can be any positive integer. In V1.1 (R2006a), these parameters can assume only the values 1, 2, 3, and 4.
If you save a model in which one of the blocks listed above has more than four entity input ports or more than four entity output ports, then the model will not work in V1.1 (R2006a).
All SimEvents® blocks now have well-defined initial values for any numerical output signals they produce.
The initial value of an output signal of a SimEvents block is in effect from the start of the simulation until the block updates the output signal for the first time during the simulation. For example, if an N-Server block is configured to produce a #n output signal representing the number of entities in the server, then #n has a well-defined initial value of 0 at the start of the simulation. The initial value persists until the first arrival of an entity at the N-Server block, which could occur well after the start of the simulation, if at all.
The block reference pages indicate the initial values of the block output signals.
If you connect the Signal Latch block to a ts, tr, or vc signal input port of a SimEvents block, the input port might detect an event at the start of the simulation in V1.1 (R2006a) that no longer occurs in V1.2 (R2006b). This is because the Signal Latch block assumes its initial condition in a true initialization stage in V1.2 (R2006b) rather than slightly after the simulation start in V1.1 (R2006a). If your model relies on an event at the start of the simulation (to invoke a discrete event subsystem or generate an event or an entity, for example), then you might see a change in simulation behavior between the two versions.
For example, the model below uses a Discrete Event Subsystem block to compute a signal that indicates whether a gate is open or closed.
Subsystem Invoked at Simulation Start in V1.1 (R2006a), but Not V1.2 (R2006b)
In V1.1 (R2006a), the Signal Latch block's output signal has a sample time hit at the start of the simulation. This sample time hit invokes the subsystem, which initializes the gate's en input signal to 1. As a result, the gate is open at the start of the simulation. In V1.2 (R2006b), the Signal Latch block does not have a sample time hit at the start of the simulation, so the initial condition of the subsystem's outport determines the initial condition of the gate's en input signal. As a result, the gate is closed at the start of the simulation.
An alternative approach that works in both versions is to move the Signal Latch block so that it follows the Discrete Event Subsystem block. The Signal Latch block directly provides the gate's initial condition.
Correct Gate Initialization in Both V1.1 (R2006a) and V1.2 (R2006b)
The following blocks include new Store data when scope is closed and Limit data points to parameters on the new Data History tab of the dialog box:
The parameters determine how much data the blocks cache, letting you balance data visibility with simulation efficiency. Caching data lets you view it later, even if the scope is closed during part or all of the simulation. Caching less or no data accelerates the simulation and uses less memory. In V1.1 (R2006a), if you have the scope closed for the first T seconds of simulation and then open the scope, you can view only the data for t>T.
Version 1.2 (R2006b) changes some aspects of the way you interact with the scope blocks:
A Pan toolbar button lets you move your view of a plot.
A Parameters toolbar button opens the block dialog box.
Double-clicking on the block opens the plot if it is not already open. In V1.1 (R2006a), double-clicking on the block opens the block dialog box. To open the block dialog box in V1.2 (R2006b), click the Parameters toolbar button on the plot.
The autoscale feature no longer changes the initial axis limits that you specify in the block dialog box. A new Save axes limits menu option lets you update the initial axis limits to match the plot's current limits. The current limits might differ from their initial values due to stretching, shifting, panning, zooming, or autoscaling operations that occurred since the initial values were last set.
The former Open at start of simulation parameter is now called Open scope at start of simulation and has moved from the Figure tab of the dialog box to the Plotting tab.
The scope blocks also plot initial conditions without a plotting marker. In V1.1 (R2006a), initial conditions typically do not appear in plots.
Finally, the scope blocks run significantly faster in V1.2 (R2006b).
If your legacy models contain scope blocks that plot more than 1000 points, then the default values of the new Store data when scope is closed and Limit data points to parameters cause the scope to retain only the last 1000 points. To plot all points, set Store data when scope is closed to Unlimited.
If you save a model containing a scope block using V1.2 (R2006b), then opening the model in an earlier version produces warnings about the parameters that are not in the earlier block. For example,
Warning: In instantiating linked block 'mysys/Attribute Scope' : Attribute Scope block (mask) does not have a parameter named 'DataStoreOption'. Warning: In instantiating linked block 'mysys/Attribute Scope' : Attribute Scope block (mask) does not have a parameter named 'DataPointsLimit'.
Saving the model in the earlier version prevents the warnings from reappearing, but also causes the block to use default values for the new parameters if you later open the model in V1.2 (R2006b).
The Event-Based Random Number block produces random numbers from a lognormal distribution when you set the Distribution parameter to Lognormal. Different texts use different parameterizations of the lognormal distribution. V1.2 (R2006b) renames some parameters in this block to clarify the relationship between a lognormal random variable X and the normal random variable log(X).
| V1.1 (R2006a) Parameter Name | V1.2 (R2006b) Parameter Name |
|---|---|
| Scale | Mu |
| Shape | Sigma |
The block behaves the same in V1.1 (R2006a) and V1.2 (R2006b) because the change merely renames parameters. However, the parameter names in V1.2 (R2006b) more accurately reflect the block's behavior.
All SimEvents blocks are compatible with accelerator mode. Version 1.1 (R2006a) does not support simulating models in accelerator mode if the models contain the Event-Based Random Number block.
SimEvents software can detect livelock during a simulation. When it detects livelock, it halts the simulation with an error message that indicates too many simultaneous events. In V1.1 (R2006a), livelock can potentially cause MATLAB® software to crash.
For details, see Livelock Prevention.
It is possible for the application to consider a situation to be livelock when it is actually a large but finite loop. Such simulations might work in V1.1 (R2006a) but not in V1.2 (R2006b).
| Version 2.0 (R2007a) SimEvents® Software | Version 1.1 (R2006a) SimEvents® Software | |
| © 1984-2008- The MathWorks, Inc. - Site Help - Patents - Trademarks - Privacy Policy - Preventing Piracy - RSS |