Store 
| Products & Services | Solutions | Academia | Support | User Community | Company |
 |
Download Product Updates | | |  |
Get Pricing | | | |
Trial Software |
| Documentation → Simulink |
| Products & Services | Solutions | Academia | Support | User Community | Company |
|
Download Product Updates | | | |
Get Pricing | | | |
Trial Software |
| Documentation → Simulink |
| Contents | Index |
| Learn more about Simulink |
This table summarizes what's new in V7.4 (R2009b):
| 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 | Printable Release Notes: |
New features and changes introduced in this version are organized by these topics:
An enhanced sim command provides for greater ease of use and for greater compatibility with parfor loops. Since the command now saves all simulation results to a single object, the management of output variables is straightforward for all cases, including parallel computing.
Simulink Rapid Accelerator mode now supports root inputs of enumerated data type and fixed-point parameters of any word length.
Simulink Accelerator mode now supports the SimState feature. You can therefore save the simulation state and later resume the simulation from the exact save time.
For fixed-step simulations, Simulink now computes sample time hits using integer arithmetic. This modification improves the timing resolution of sample hits of multirate models.
Compatibility Considerations. Previously, if an S-function had two rates, and if (ssIsSampleHit(S, idx1) == true && ssIsSampleHit(S,idx2) == true, then Simulink would adjust the task times to be evaluated as ssGetTaskTime(S, idx1) == ssGetTaskTime(S, idx2). Simulink no longer forces this equality; instead, Simulink now leaves the individual task times to be integer multiples of their corresponding periods. Consequently, existing code with logic that relies upon the equality of the task times needs to be updated.
In addition, the behavior of the command get_param(model, 'SimulationTime') is now different. Instead of returning the time of the next known sample hit at the bottom of the current step, this command now returns the current time.
For variable-step discrete simulation of purely discrete models, where the fundamental step size is the same as the fastest discrete rate, Simulink now uses the specified start and stop times.
Compatibility Considerations. Previously, if the fundamental step size was equal to the fastest discrete rate, the Simulink simulation did not uniformly honor the user-specified start and stop times. Specifically, if the start and stop times were not exact multiples of the fundamental step size, then the start time was adjusted to the time of the first sample time hit and the simulation stopped at the sample time hit just before the specified stop time. However, if the simulation was required to hit certain time points (either by specifying TSPAN in the sim command such as 'sim('Model_A',[0 10])', or via the OutputTimes parameter), then the start and stop times were not adjusted
Now Simulink variable-step simulation of purely discrete models consistently honors the user-specified start and stop times, irrespective of whether the fastest discrete sample time is the GCD of all of the other sample times
In R2009b, improved library link management facilitates visualizing and restoring edited library links.
Model reference variants allow you to configure any Model block to select its referenced model from a set of candidate models. The selection occurs when you compile the model that contains the Model block, and depends on the values of one or more MATLAB variables or Simulink parameters in the base workspace. To configure a Model block to select the model that it references, you:
Provide a set of Boolean expressions that reference base workspace values.
Associate each expression with one of the models that the block could reference.
When you compile the model, Simulink evaluates all the expressions. Each Model block that uses model reference variants then selects the candidate model whose associated expression is true, and ignores all the other models. Compilation then proceeds exactly as if you had entered the name of the selected model literally in the Model block's Model name field.
You can nest Model blocks that use variants to any level, allowing you to define any number of arbitrarily complex customized models within a single framework. No matter how many simulation environments you define, selecting one requires only setting variable or parameter values appropriately in the base workspace.
For more information about model reference variants, see Using Model Reference Variants.
A protected model is a referenced model from which all block and line information has been eliminated. Protecting a model does not use encryption technology. A protected model can be distributed without revealing the intellectual property that it embodies. The model is said to run in Protected mode, and gives the same results that its source model does when run in Accelerator mode.
You can use a protected model much as you could any referenced model that executes in Accelerator mode. Simulink tools work with protected models to the extent possible given that the model's contents are obscured. For example, the Model Explorer and the Model Dependency Viewer show the hierarchy under an ordinary referenced model, but not under a protected model. Signals in a protected model cannot be logged, because the log could reveal information about the protected model's contents.
When a referenced model requires object definitions or tunable parameters that are defined in the MATLAB base workspace, the protected version of the model may need some or all of those same definitions when it executes as part of a third-party model. Simulink provides techniques for identifying and obtaining the needed data. You can use the Simulink Manifest Tools or other techniques to package the model and any data for delivery.
Protecting a model requires a Real-Time Workshop® license, which makes code generation capabilities available for use internally when creating the protected version of the model. The receiver of a protected model does not need a Real-Time Workshop license to use the model, and cannot use Real-Time Workshop to generate code for the model or any model that references it.
To accommodate protected models, the Model block now accepts a suffix in the Model name field. This suffix can be .mdl for an unprotected model or .mdlp for a protected model. If the suffix is omitted, Model block first searches the MATLAB path for a block with the specified name and the suffix .mdl. If that search fails, the block searches the path for a model with the suffix .mdlp.
The Model block now has a field named ProtectedModel, a boolean that indicates whether the referenced model is protected, and three fields for representing the name of the referenced model in different formats: ModelNameDialog, ModelName, and ModelFile. See the Model block parameters in Ports & Subsystems Library Block Parameters for information about these parameters. For more information about protecting models, see Protecting Referenced Models.
Enhanced Simulink Manifest Tools now discover and analyze model variants, protected models, and Simscape™ files.
New manifest analysis options for controlling whether to report file dependency locations for user files, all files, or no files. For example, you may not want to view the file locations of all the dependencies on MathWorks products. This is typical if your main use of Simulink Manifest Tools is to discover and package all the required files for your model. By not analyzing file locations, you speed up report creation, and the report is smaller and easier to navigate. If you need to trace all dependencies to understand why a particular file or toolbox is required by a model, you can always regenerate the full report of all files.
The manifest report is enhanced with sortable columns, and now MATLAB Programs as well as P-files are reported in the manifest if both exist.
For more information, see Model Dependencies in the Simulink User's Guide.
Enhanced S-Function Builder that support bus signals for managing complex signal interfaces
New capability that allows signal sizes to change during execution facilitates modeling of systems with varying environments, resources, and constraints. For Simulink models that demonstrate using variable-size signals, see Working with Variable-Size Signals
Referenced Model
Simulink Accelerator and Rapid Accelerator
Bus Signals
C-mex S-function
Level-2 M-file S-function
Simulink Debugger
Signal Logging and Loading
Block Run-Time Object
Support for variable-size signal inputs and outputs in over 40 Simulink blocks including many blocks from the Math Operations library. For a list of Simulink blocks, see Simulink Block Support for Variable-Size Signals
Embedded MATLAB Function blocks now support variable-size arrays and matrices with known upper bounds. With this feature, you can define inputs, outputs, and local variables to represent data that varies in size at runtime.
The Lock output scaling against changes by the autoscaling tool check box is now Lock data type setting against changes by the fixed-point tools. Previously, this check box was visible only if you entered an expression or a fixed-point data type, such as fixdt(1,16,0). This check box is now visible for any data type specification. This enhancement enables you to lock the current data type settings on the dialog box against changes that the Fixed-Point Advisor or Fixed-Point Tool chooses.
The new compilation report provides compile-time type information for the variables and expressions in your Embedded MATLAB™ functions. This information helps you find the sources of error messages and understand type propagation issues, particularly for fixed-point data types. For more information, see Working with Compilation Reports in the Simulink User's Guide.
Compatibility Considerations. The new compilation report is not supported by the MATLAB internal browser on Sun™ Solaris™ 64-bit platforms. To view the compilation report on Sun Solaris 64-bit platforms, you must configure your MATLAB Web preferences to use an external browser, for example, Mozilla Firefox. To learn how to configure your MATLAB Web preferences, see Web Preferences in the MATLAB documentation.
In simulation, the code generated for Embedded MATLAB function blocks includes various run-time checks. To reduce the size of the generated code, and potentially improve simulation times, you can use new Simulation Target configuration parameters to control whether or not your generated code performs:
Integrity checks to detect violations of memory integrity in the generated code. For more information, see Ensure memory integrity in the Simulink Graphical User Interface.
Responsiveness checks to periodically check for Ctrl+C breaks and refresh graphics. For more information, see Ensure responsiveness in the Simulink Graphical User Interface.
The new Simulink.saveVars function can save variables from the base workspace to an M-file. The file containing the variables is human-readable and can be edited. Loading the file restores the saved variables to the base workspace. If MATLAB code cannot be generated for a variable, the variable is saved into a corresponding MAT-file "filename.mat".
Saving Variables. Simulink.saveVars('filename') – Saves all workspace variables to MATLAB script, "filename.m". Executing this script restores the variables into the current workspace.
Simulink.saveVars('filename', 'X', 'Y', 'Z') – Saves variables X, Y and Z. The wildcard '*' can be used to save all variables that match a pattern.
Updating a File. Simulink.saveVars('filename', ..., '-update') – Resaves only those variables that are created by an existing MATLAB script. The order of variables in the file is preserved.
Simulink.saveVars('filename', ..., '-append') – Saves workspace variables to an existing MATLAB script. The order of existing variables in the file is preserved. The code for any new variables is appended at the end of the file.
[r1, r2] = Simulink.saveVars('filename', ..., 'updateOption', 'matversion')
filename – Valid MATLAB file name (.m extension is optional). This filename cannot duplicate the name of any variable in the workspace.
List of variable names (optional) – Explicit list of variables (e.g., 'X', 'Y', 'Z') or list of variables matching wildcard (e.g., 'X*') or a regular expression (e.g., '-regexp', 'expr1', 'expr2')
updateOption (optional)
-create: Create new MATLAB script file (default behavior).
-update: Update existing file (only save variables already in file).
-append: Update existing file (update existing variables and append new variables to the end of file).
r1 – List of variables saved to MATLAB script.
r2 – List of variables saved to MAT-file.
You can use the R2009b Mask Editor to create a mask that has tabbed panes, and define the same signal attribute specifications in a mask that built-in Simulink blocks provide.
The Constant block can output enumerated values but provides parameters that do not apply to enumerated types, such as Output minimum and Output maximum. In R2009b, the Sources library includes an Enumerated Constant block:
This block provides those Constant block parameters that are specific to enumerated types and omits all others. The Enumerated Constant dialog box initially looks like this:
The Output data type field specifies the enumerated type from which you want the block to output a value. The initial value, Enum: SlDemoSign, is a dummy enumerated type provided to prevent a newly cloned block from initially causing an error. The Value field specifies the enumerated values that the block will output. The initial value, SlDemoSign.Positive, is a dummy enumerated value provided to prevent an initial error in a newly cloned block.
To specify the desired enumerated type, enter Enum: ClassName in the Output data type field, where ClassName is the name of the MATLAB class that defines the type.
As soon as you specify an Output data type, the first enumerated value defined by the type appears in the Value field, and all values in the type are available in the Value menu. You can now:
Select a value from the menu.
Type a value or array of values literally.
Enter an expression or tunable parameter that evaluates to a value or array of values.
You must define all enumerated values specified using any technique in the Output data type. Be sure to prefix the specification of any enumerated value that you enter manually with the name of its class, e.g., BasicColors.Yellow rather than just Yellow.
For more information, see Using Enumerated Data in the Simulink documentation.
The Switch Case block supports enumerated data types for the input signal and case conditions. You specify Case conditions as a cell array of enumerated values, for example:
{BasicColors.Red, [BasicColors.Yellow, BasicColors.Blue]}When the case conditions contain enumerated values:
All case conditions must be of the same enumerated data type.
The input signal must be of that same enumerated data type.
All case conditions must have different underlying integers.
The Switch Case block icon shows the enumerated names that correspond to the case conditions, for example:
The generated code includes the enumeration strings corresponding to the case conditions:
/* Exported block signals */
real_T OUTPUT1; /* '<S2>/Merge' */
BasicColors INPUT; /* '<S1>/CnvToEnum' */
/* SwitchCase: '<Root>/Switch Case' incorporates:
* ActionPort: '<S5>/Action Port'
* ActionPort: '<S6>/Action Port'
* ActionPort: '<S7>/Action Port'
* SubSystem: '<S2>/Case0'
* SubSystem: '<S2>/Case1'
* SubSystem: '<S2>/Case2'
*/
switch (INPUT) {
case Red:
Case0(&OUTPUT1);
break;
case Yellow:
case Blue:
Case1(&OUTPUT1);
break;
default:
Case2(&OUTPUT1);
break;
}
For more information, see Using Enumerated Data in the Simulink documentation.
In previous releases, generated code for a Multiport Switch block that uses enumerated data contains the underlying integer for each enumerated value rather than its name. In R2009b, the code contains the name of each enumerated value rather than its underlying integer. This change adds readability and facilitates comparing the code with the model, but has no effect on the behavior of the code.
For more information, see Using Enumerated Data in the Simulink documentation.
Some classes and properties in the Simulink data class infrastructure have been deprecated in R2009b. See Working with Data for information about Simulink data classes.
Compatibility Considerations. If you use any of the deprecated constructs, Simulink posts a warning that identifies the construct and describes one or more techniques for eliminating it. The techniques differ depending on the construct. You can ignore these warnings in R2009b, but The MathWorks recommends making the described changes now because the deprecated constructs may be removed from future releases, upgrading the warnings to errors.
Enhanced sim command that saves all simulation results to a single object for easier management of simulation results.
In order to restart an R2009a simulation in R2009b, you should first regenerate the initial SimState in R2009b.
Compatibility Considerations. The SimState that Simulink saves from a R2009a simulation might be incompatible with the internal representation of the same model in R2009b. Simulink detects this incompatibility when the R2009a SimState is used to restart a R2009b simulation. If the mismatch resides in the model interface only, then Simulink issues a warning. (You can use the Simulink diagnostic ‘SimState interface checksum mismatch' to turn off such warnings or to direct Simulink to report an error.) However, if the mismatch resides in the structural representation of the model, then Simulink reports an error. To avoid these errors and warnings, you need to regenerate the initial SimState in R2009b.
Support for custom floating-point types, float(TotalBits, ExpBits), will be removed in a future release.
In R2009b, Simulink continues to process these types.
For more information, see float.
The following functions are no longer available:
adams.m
euler.m
gear.m
linsim.m
rk23.m
rk45.m
In R2009b, you will no longer be able to use the SaveAs feature to save a model to releases R12 or R13. You will, however, be able to save models to R12 and R13 using the command-line. In R2010a, the command-line capability will also be removed.
When you use the save_system function to save a model to an earlier release, you will no longer receive a dialog box that indicates that the save was successful.
You can implement a continuous- or discrete-time PID controller with just one block by using one of the new PID Controller and PID Controller (2DOF) blocks. With the new blocks, you can:
Configure your controller in any common controller configuration, including PID, PI, PD, P, and I.
Tune PID controller gains either manually in the block or automatically in the new PID Tuner. (PID Tuner requires a Simulink® Control Design™ license.)
Generate code to implement your controller using any Simulink data type, including fixed-point data types (requires a Real-Time Workshop license).
You can set many options in the PID Controller and PID Controller (2DOF) blocks, including:
Ideal or parallel controller configurations
Optional output saturation limit with anti-windup circuitry
Optional signal-tracking mode for bumpless control transfer and multiloop controllers
Setpoint weighting in the PID Controller (2DOF) block
The blocks are available in the Continuous and Discrete libraries. For more information on using the blocks, see the PID Controller and PID Controller (2DOF) reference pages. For more information on tuning the PID blocks, see Automatic PID Tuning in the Simulink Control Design reference pages.
The Constant block can output enumerated values but provides parameters that do not apply to enumerated types, such as Output minimum and Output maximum. In R2009b, the Sources library includes an Enumerated Constant block:
This block provides those Constant block parameters that are specific to enumerated types and omits all others. The Enumerated Constant dialog box initially looks like this:
The Output data type field specifies the enumerated type from which you want the block to output a value. The initial value, Enum: SlDemoSign, is a dummy enumerated type provided to prevent a newly cloned block from initially causing an error. The Value field specifies the enumerated values that the block will output. The initial value, SlDemoSign.Positive, is a dummy enumerated value provided to prevent an initial error in a newly cloned block.
To specify the desired enumerated type, enter Enum: ClassName in the Output data type field, where ClassName is the name of the MATLAB class that defines the type.
As soon as you specify an Output data type, the first enumerated value defined by the type appears in the Value field, and all values in the type are available in the Value menu. You can now:
Select a value from the menu.
Type a value or array of values literally.
Enter an expression or tunable parameter that evaluates to a value or array of values.
You must define all enumerated values specified using any technique in the Output data type. Be sure to prefix the specification of any enumerated value that you enter manually with the name of its class, e.g., BasicColors.Yellow rather than just Yellow.
For more information, see Using Enumerated Data in the Simulink documentation.
The Switch Case block supports enumerated data types for the input signal and case conditions. You specify Case conditions as a cell array of enumerated values, for example:
{BasicColors.Red, [BasicColors.Yellow, BasicColors.Blue]}When the case conditions contain enumerated values:
All case conditions must be of the same enumerated data type.
The input signal must be of that same enumerated data type.
All case conditions must have different underlying integers.
The Switch Case block icon shows the enumerated names that correspond to the case conditions, for example:
The generated code includes the enumeration strings corresponding to the case conditions:
/* Exported block signals */
real_T OUTPUT1; /* '<S2>/Merge' */
BasicColors INPUT; /* '<S1>/CnvToEnum' */
/* SwitchCase: '<Root>/Switch Case' incorporates:
* ActionPort: '<S5>/Action Port'
* ActionPort: '<S6>/Action Port'
* ActionPort: '<S7>/Action Port'
* SubSystem: '<S2>/Case0'
* SubSystem: '<S2>/Case1'
* SubSystem: '<S2>/Case2'
*/
switch (INPUT) {
case Red:
Case0(&OUTPUT1);
break;
case Yellow:
case Blue:
Case1(&OUTPUT1);
break;
default:
Case2(&OUTPUT1);
break;
}
For more information, see Using Enumerated Data in the Simulink documentation.
In previous releases, generated code for a Multiport Switch block that uses enumerated data contains the underlying integer for each enumerated value rather than its name. In R2009b, the code contains the name of each enumerated value rather than its underlying integer. This change adds readability and facilitates comparing the code with the model, but has no effect on the behavior of the code.
For more information, see Using Enumerated Data in the Simulink documentation.
The following enhancements apply to the Discrete Transfer Fcn block:
Improved numerics and run-time performance of outputs and states by reducing the number of divide operations in the filter to one
Support for signed fixed-point and signed integer data types
Support for vector and matrix inputs
Support for input and coefficients with mixed complexity
A new Initial states parameter for entering nonzero initial states
A new Optimize by skipping divide by leading denominator coefficient (a0) parameter that provides more efficient implementation by eliminating all divides when the leading denominator coefficient is one. This enhancement provides optimized block performance.
Compatibility Considerations. Due to these enhancements, you might encounter the following compatibility issues:
Realization parameter removed
The Real-Time Workshop software realization parameter has been removed from this block. You can no longer use the set_param and get_param functions on this block parameter. The generated code for this block has been improved to be similar to the former 'sparse' realization when the Optimize by skipping divide by leading denominator coefficient (a0) parameter is selected, while maintaining tunability as in the former 'general' realization when the parameter is not selected.
State changes
Due to the reduction in the number of divide operations that the block performs, you might notice that your logged states have changed when the leading denominator coefficient is not one.
The Lookup Table (n-D) block supports breakpoint data types that differ from input data types. This enhancement provides these benefits:
Lower memory requirement for storing breakpoint data that uses a smaller type than the input signal
Sharing of prescaled breakpoint data between two Lookup Table (n-D) blocks with different input data types
Sharing of custom storage breakpoint data in Real-Time Workshop generated code for blocks with different input data types
The Lookup Table (n-D) block supports table data types that differ from output data types. This enhancement provides these benefits:
Lower memory requirement for storing table data that uses a smaller type than the output signal
Sharing of prescaled table data between two Lookup Table (n-D) blocks with different output data types
Sharing of custom storage table data in Real-Time Workshop generated code for blocks with different output data types
The Lookup Table (n-D) block also supports separate data type specification for intermediate results. This enhancement enables use of a higher precision for internal computations than for table data or output data.
For consistency with other lookup table blocks, the Process out-of-range input parameter prompt is now Action for out-of-range input. Similarly, the command-line parameter is now ActionForOutOfRangeInput. For backward compatibility, the old command-line parameter ProcessOutOfRangeInput continues to work. The parameter settings also remain the same: None, Warning, or Error.
For the Prelookup and Lookup Table (n-D) blocks, Real-Time Workshop generated code now stores only the first breakpoint, spacing, and number of breakpoints when:
The breakpoint data is nontunable.
The index search method is Evenly spaced points.
This enhancement reduces memory use and provides faster code execution. Previously, the code stored all breakpoint values in a set, regardless of the tunability or spacing of the breakpoints.
The following enhancements also provide more efficient code for the two blocks:
| Block | Enhancement for Code Efficiency |
|---|---|
| Lookup Table (n-D) | Removal of unnecessary bit shifts for calculating the fraction |
| Prelookup and Lookup Table (n-D) | Use of simple division instead of computationally expensive function calls for calculating the index and fraction |
The Math Function block now supports a new function for computing the reciprocal of a square root: 1/sqrt. You can use one block instead of two separate blocks for this computation, resulting in smaller block diagrams.
You can select one of two methods for computing the reciprocal of a square root: Exact or Newton-Raphson. Both methods support real input and output signals. When you use the Newton-Raphson method, you can also specify the number of iterations to perform the algorithm.
The Math Function block now supports Real-Time Workshop code generation in these cases:
Complex input and output signals for the pow function, for use with floating-point data types
Fixed-point data types with fractional slope and nonzero bias for the magnitude^2, square, and reciprocal functions
The Relational Operator block now includes isInf, isNaN, and isFinite functions to detect signals that are infinite, NaN, or finite. These new functions support real and complex input signals. If you select one of these functions, the block changes automatically to one-input mode.
The Lock output scaling against changes by the autoscaling tool check box is now Lock output data type setting against changes by the fixed-point tools. Previously, this check box was visible only if you entered an expression or a fixed-point data type for the output, such as fixdt(1,16,0). This check box is now visible for any output data type specification. This enhancement helps you lock the current data type settings on a dialog box against changes that the Fixed-Point Advisor or Fixed-Point Tool chooses.
This enhancement applies to the following blocks:
The Lock scaling against changes by the autoscaling tool check box is now Lock data type settings against changes by the fixed-point tools. Previously, this check box was visible only if you entered an expression or a fixed-point data type, such as fixdt(1,16,0). This check box is now visible for any data type specification. This enhancement helps you lock the current data type settings on a dialog box against changes that the Fixed-Point Advisor or Fixed-Point Tool chooses.
This enhancement applies to the following blocks:
The Direct Lookup Table (n-D) block now supports:
Direct entry of Number of table dimensions
Entry of Table data using the Lookup Table Editor
Previously, entering an integer greater than 4 for the Number of table dimensions required editing Explicit number of table dimensions. This extra parameter no longer appears on the block dialog box. For backward compatibility, scripts that contain explicitNumDims continue to work.
The other parameters for the block have changed as follows. For backward compatibility, the old command-line parameters continue to work.
| Prompt on Block Dialog Box | Old Command-Line Parameter | New Command-Line Parameter |
|---|---|---|
| Number of table dimensions | maskTabDims | NumberOfTableDimensions |
| Inputs select this object from table | outDims | InputsSelectThisObjectFromTable |
| Make table an input | tabIsInput | TableIsInput |
| Table data | mxTable | Table |
| Action for out-of-range input | clipFlag | ActionForOutOfRangeInput |
| Sample time | samptime | SampleTime |
Compatibility Considerations. In R2009b, signal dimension propagation can behave differently from previous releases. Your model might not compile under these conditions:
A Direct Lookup Table (n-D) block is in a source loop.
Underspecified signal dimensions exist.
If your model does not compile, set dimensions explicitly for underspecified signals.
Conversion of the Unary Minus block from a masked S-Function to a core block enables more efficient simulation of the block.
You can now specify sample time for the block. The Saturate to max or min when overflows occur check box is now Saturate on integer overflow, and the command-line parameter is now SaturateOnIntegerOverflow. For backward compatibility, the old command-line parameter DoSatur continues to work.
Conversions of the Weighted Sample Time and Weighted Sample Time Math blocks from masked S-Functions to core blocks enable more efficient simulation of the blocks.
The following parameter changes apply to both blocks. For backward compatibility, the old command-line parameters continue to work.
| Old Prompt on Block Dialog Box | New Prompt on Block Dialog Box | Old Command-Line Parameter | New Command-Line Parameter |
|---|---|---|---|
| Output data type mode | Output data type | OutputDataType | OutDataTypeStr |
| Saturate to max or min when overflows occur | Saturate on integer overflow | DoSatur | SaturateOnIntegerOverflow |
For the Switch Case block, the command-line parameter for the Show default case check box is now ShowDefaultCase. For backward compatibility, the old command-line parameter CaseShowDefault continues to work.
For the Signal Conversion block, the parameter prompt for the Override optimizations and always copy signal check box is now Exclude this block from 'Block reduction' optimization.
The Enable zero-crossing detection parameter is now on by default for the Compare To Constant and Compare To Zero blocks. This change provides consistency with other blocks that support zero-crossing detection.
You can no longer see the system under the Signal Builder block mask. In previous releases, you could right-click this block and select Look Under Mask.
In the Model Explorer, the Signal Builder block no longer appears in the Model Hierarchy view. In previous releases, this view was visible.
R2009b introduces context-sensitive help for parameters that appear in Simulink blocks of the Continuous library. This feature provides quick access to a detailed description of the block parameters.
To use the context-sensitive help:
Place your pointer over the label of a parameter and right-click.
A What's This? context menu appears.
For example, the following figure shows the What's This? context menu that appears after right-clicking the Enable zero-crossing detection parameter for the PID Controller block.
Click What's This? A window appears showing a description of the parameter.
If you are using the same block repeatedly in a model, then you can save time by using the:
Most Frequently Used Blocks tab in the Library Browser
Most Frequently Used Blocks context menu option in the Model Editor
These features provide quick access to blocks you have added to models frequently. For details, see Adding Frequently Used Blocks.
The Highlight to Destination option for a signal provides more information now for duplicate inport blocks. Applying this option to a signal of an inport block that has duplicate blocks highlights:
The signal and destination block for that signal
The signals and destination blocks of the duplicate blocks at the currently opened level in the model
You can add a Simulink.NumericType object to the model workspace using the Model Explorer, provided you do not enable the Is alias option.
An example of when you might use this feature is when you:
Want to define user-defined data types together in the model
Do not need to preserve the data type name in the model or in the generated code
The Block Output Display dialog now includes OK and Cancel buttons to specify whether or not to apply your option settings.
Historically, you could not use the hybrid sample time to effectively identify a multirate subsystem or block. A subsystem was marked as "hybrid" and colored in yellow whether it contained two discrete sample times or one discrete sample time and one or more blocks with constant sample time [inf, 0]. Now, in R2009b, the check for the hybrid attribute no longer includes constant sample times, thereby improving the usefulness of the hybrid sample time color in identifying subsystems (and blocks) that are truly multirate.
In R2009b, the Model Advisor includes a Find option to help you find checks. The find option, accessible through the Edit menu, allows you to find checks and folders more easily by searching names and analysis descriptions.
For more information, see Overview of the Model Advisor Window.
 | Simulink Release Notes | Version 7.3 (R2009a) Simulink Software |  |
Learn more about Simulink through this collection of videos, articles, technical literature and the Getting Started with Simulink Guide.
| © 1984-2009- The MathWorks, Inc. - Site Help - Patents - Trademarks - Privacy Policy - Preventing Piracy - RSS |
