| Version 5.1 (R13SP1) Simulink® Software Release Notes | |
This table summarizes what's new in V5.1 (R13SP1):
| New Features and Changes | Version Compatibility Considerations | Fixed Bugs and Known Problems | Related Documentation at Web Site |
|---|---|---|---|
| Yes Details below | No | Fixed Bugs | Printable Release Notes: PDF V5.1 product documentation |
New features and changes introduced in this version are:
Sample time parameters of most Simulink built-in library blocks have been exposed to the user. That is, the sample time parameter of these blocks has been made accessible via the block's dialog box or set_param. This means that most nonvirtual blocks in the Simulink library have a user settable sample time parameter. Prior to this exposure, these blocks had an internal inherited sample time with the exception of the Constant block, which had a constant (inf) sample time. By providing access to the sample time parameter, you no longer need to use the Signal Specification block to apply a nondefault sample times to these blocks.
This release includes enhancements to the Simulink debugger that enable you to step through a simulation showing information not visible in previous releases. The enhancements include
An expanded command set that now enables you to step a simulation method by method. Previous releases showed only output methods.
An expanded toolbar that gives you push button access to new debugger commands
A Simulation Loop pane that shows the current state of the simulation at a glance
Note Methods are functions that Simulink software uses to solve a model at each time step during the simulation. Blocks are made up of multiple methods. "Block execution" in this documentation is shorthand notation for "block methods execution." Block diagram execution is a multi-step operation that requires execution of the different block methods in all the blocks in a diagram at various points during the process of solving a model at each time step during simulation, as specified by the simulation loop. |
These changes allow you to pinpoint problems in your model with greater accuracy. The following sections briefly describe the debugger enhancements. See the Simulink documentation for a detailed description of the new features and their usage.
This release enhances the following debugger commands:
step
In previous releases, this command advanced the simulation from the current block Outputs method over any intervening methods to the next block Outputs method. In this release, step advances the simulation method by method, or into, over, or out of methods, from the first method executed during the simulation to the last. This allows you to determine the result of executing any model, subsystem, or block method executed during the simulation, including block Outputs, Update, and Derivative methods as well as solver methods.
next
In previous releases, this command advanced the simulation to the first block Outputs method executed during the next time step. In this release, it advances the simulation over the next method to be executed, executing any methods invoked by the next method.
break
In previous releases, this command set a breakpoint at the Outputs method of a specified block. In the current release, it sets a breakpoint at any specified method or on all the methods of a specified block.
bafter
In previous releases, this command set a breakpoint after the Outputs method of a specified block. In this release, it sets a breakpoint after a specified method or after each of the methods of a specified block.
minor
In previous releases, this command enabled or disabled stepping across Outputs methods in minor time steps. In the current release, it enables or disables in minor time steps breakpoints set by block for all methods.
This release introduces the following debugger commands:
elist
Displays the method execution lists for the root system and the nonvirtual subsystems of the model being debugged.
etrace
Causes the debugger to display a message in the MATLAB Command Window every time a method is entered or exited while the simulation is running.
where
Displays the call stack of the method at which the simulation is currently suspended.
The debugger toolbar has been expanded to include buttons for the following versions of the step command: step into, step over, step out, and step top.
This release adds a Simulation Loop pane to the debugger GUI that displays by method the point in the simulation loop at which the simulation is currently suspended. The debugger updates the pane after each step, next, or continue command, enabling you to determine at a glance the point to which the command advanced the simulation. The pane also allows you to set breakpoints on simulation loop methods and to navigate to the block at whose method the simulation is currently suspended.
This release renames the Block Execution List pane of the debugger GUI to the Sorted List pane to reflect more accurately what the pane contains. The Sorted List pane displays for the root system and each nonvirtual subsystem of the model being debugged a sorted list of the subsystem's blocks. The sorted lists enable you to determine the block IDs of a model's blocks.
In this release, if a model's Inline parameters setting is selected, Simulink software regards the data type of a tunable parameter as context-sensitive if the data type is not specified. In particular, this release allows the block that uses the parameter to determine the parameter's data type. By contrast, Release 13 regards the type of the parameter to be double regardless of where it is used.
This change affects the behavior of Simulink software in two cases. First, in Release 13, if a tunable parameter's data type is unspecified and a block that uses it needs to convert its type from double to another type, Simulink software by default stops and displays an error message when you update or simulate the model. The error alerts the user to the fact that the type conversion is a downcast and hence could result in a loss of precision. In this release, by contrast, a typecast never occurs because the block itself determines the appropriate type for the parameter. Hence, in this release, Simulink software never generates a downcast error for tunable parameters of unspecified data type.
The following model illustrates the difference in behavior between this release and Release 13 in this case.
Assume that the model's Inline parameters setting is selected (thereby making parameters nontunable by default) and the model declares k as a tunable parameter on the Model Configuration Parameters dialog box. Also assume that the user has specified the value of k on the MATLAB command line as follows:
>> k = 5.7
In other words, the user has specified a value for k but not a data type. In this case, this release regards the type of k to be int16, the type required by the Gain block to compute its output. By contrast, Release 13 regards the type of k to be double and hence assumes that the Gain block must downcast k to compute its output. Release 13 therefore stops and displays an error message by default in this case when you update or simulate the model.
The behavior of this release also differs from Release 13 in the case where a model uses a tunable parameter of unspecified data type in more than one place in the model and the required data type differs in different places. This case creates a conflict under the assumption that the block in which the parameter is used determines the parameter's data type. This assumption requires Simulink software to assign different data types to the same parameter, which is impossible. Therefore, in this release, Simulink software signals an error to alert the user to the conflict. By contrast, in Release 13, Simulink software does not throw an error because the data type of the parameter is double regardless of where it is used. You can avoid the conflicting data types error in Release 13SP1 by specifying the tunable parameter's data type.
The following model illustrates this change in behavior.
The two Gain blocks in this model both use k, a tunable parameter of unspecified type, as their gain parameter. Computing the outputs of the blocks requires that the gain parameter be of types int16 and int32, respectively. In Release 13, Simulink software regards the data type of k to be double and the Gain blocks use typecasts to convert k to the required type in each case. Simulink software simulates the model without error (if the parameter downcasting diagnostic is set to none or warning). By contrast, this release signals an error because this model requires k to be both type int16 and int32, an impossibility. You can avoid this error by explicitly specifying k's data type; for example:
k = int16(6);
This release augments the conditional input branch behavior of the previous release with a more generalized behavior called conditional execution (CE) behavior. The new behavior speeds simulation of models by eliminating unnecessary execution of blocks connected to Switch, Multiport Switch, and conditionally executed blocks.
Note The Simulink documentation has not yet been updated to reflect the new behavior. Consequently, the remainder of this release note provides a detailed explanation of how the behavior works. |
As with the conditional input branch behavior available in the previous release, the new behavior ensures that the block methods that make up an input branch of a Switch or Multiport Switch block execute only when the model selects the corresponding switch input. In addition, the new behavior option generalizes this behavior to conditionally executed subsystems. Consider, for example, the following model.
Simulink software computes the outputs of the Constant block and Gain Block only when the Enabled Subsystem executes (i.e., at time steps 0, 4, 8, and so on). This is because the output of the Constant block is required and the input of the Gain block changes only when the Enabled Subsystem executes. When CE behavior is off, Simulink software computes the outputs of the Constant and Gain blocks at every time step, regardless of whether the outputs are needed or change.
In this example, Simulink software regards the Enabled Subsystem as defining an execution context for the Constant and Gain blocks. Although the blocks reside in the model's root system, their block methods are executed as if the blocks reside in the Enabled Subsystem.
In general, Simulink software defines an execution context as a set of blocks to be executed as a unit. At model compilation time, Simulink software associates an execution context with the model's root system and with each of its nonvirtual subsystems. Initially, the execution context of the root system and each nonvirtual subsystem is simply the blocks that it contains. Simulink software examines whether a block's output is required only by a conditionally executed subsystem or whether the block's input changes only as a result of the execution of a conditionally executed subsystem. If so, Simulink software moves the block into the execution context of the conditionally executed system. This ensures that the block methods are executed during the simulation loop only when the corresponding conditionally executed subsystem executes.
Note This behavior treats the input branches of a Switch or Multiport Switch block as invisible, conditionally executed subsystems, each of which has its own execution context that is enabled only when the switch's control input selects the corresponding data input. As a result, switch branches execute only when selected by switch control inputs. |
To determine the execution context to which a block belongs, select Sorted order from the model window's Format menu. Simulink software displays the sorted order index for each block in the model in the upper right corner of its icon. The index has the format s:b, where s specifies the subsystem to whose execution context the block, b, belongs.
Simulink software also expands the sorted order index of conditionally executed subsystems to include the system ID of the subsystem itself in curly brackets as illustrated in the following figure.
In this example, the sorted order index of the enabled subsystem is 0:1{1}. The 0 indicates that the enable subsystem resides in the model's root system. The first 1 indicates that the enabled subsystem is the second block on the root system's sorted list (zero-based indexing). The 1 in curly brackets indicates that the system index of the enabled subsystem itself is 1. Thus any block whose system index is 1 belongs to the execution context of the enabled subsystem and hence executes when it does. For example, the constant block's index, 1:0, indicates that it is the first block on the sorted list of the enabled subsystem, even though it resides in the root system.
This releases adds the following function-call subsystem-related parameters to the Trigger block:
The States when enabling parameter specifies whether a function-call enable trigger causes Simulink software to reset the states of the subsystem containing this Trigger block to their initial values.
The Sample time type parameter specifies whether the function-call subsystem containing the Trigger block is invoked periodically.
The Sample time parameter species the rate at which the function-call subsystem containing the Trigger block is invoked.
See the Trigger block documentation for additional information.
This release adds an external increment option to the For Iterator block. Selecting this option causes the block to display an input port for the external increment. The value of this input port at the current time step is used as the value of the block's iteration variable at the next iteration. You can select this option by checking the Set next i (iteration variable) externally option on the block's parameter dialog box or by setting its ExternalIncrement parameter to 'on'. See the documentation for the For Iterator block for more information.
Note This enhancement is not backward compatible with R13. Loading models containing For Iterator blocks with this option selected in R13 produces a warning message. Simulating such models in R13 can produce incorrect results. |
Release R13SP1 includes many performance improvements that were designed to particularly benefit large models (containing on the order of 100,000 blocks and/or more than a few megabytes of parameter data). Speed has been improved and memory consumption reduced for model loading, compilation, code generation, and closing. The various improvements span the Simulink, Stateflow, and Real-Time Workshop products and include:
Increased speed and decreased memory consumption through improved incremental loading of library blocks that contain Stateflow blocks.
Increased speed and decreased memory usage through the introduction of a redesigned Signal Specification block. Models saved with the old version of the Signal Specification block should automatically start using the new block when you load the model with this release.
Increased speed in datatype and sample time propagation during the compile phase of certain models.
Increased speed in the Stateflow build process for both simulation and Real-Time Workshop targets.
Increased speed and decreased memory consumption when using N-D Lookup Table blocks that utilize large parameter data.
Increased speed and decreased memory usage when generating code with Real-Time Workshop software or Simulink Accelerator for models with large parameter sets. This improvement involves writing out parameter references instead of the entire parameter data into the Real-Time Workshop file for parameters whose size exceeds 10 elements. The parameter values for such references are retrieved directly from Simulink software during the code generation process.
Decreased memory usage during various phases of code generation process in Real-Time Workshop software or Simulink Accelerator.
Improved speed during model close through streamlining of the close process.
Other minor improvements have also been made to improve performance. Your models should experience corresponding speed and memory improvements, to the extent that these changes apply to your specific models and usage scenarios.
| Version 6.0 (R14) Simulink Software | Version 5.0.1 (R13.0.1) Simulink Software | |
| © 1984-2008- The MathWorks, Inc. - Site Help - Patents - Trademarks - Privacy Policy - Preventing Piracy - RSS |