|
|
|
| R2012a Documentation → Simulink | |
Learn more about Simulink |
|
| Contents | Index |
This table summarizes what's new in V7.5 (R2010a):
| New Features and Changes | Version Compatibility Considerations | Fixed Bugs and Known Problems |
|---|---|---|
| Yes Details below | Yes—Details labeled as Compatibility Considerations, below. See also Summary. | Bug
Reports Includes fixes |
New features and changes introduced in this version are organized by these topics:
The implicit Simulink solvers now support numerical and analytical methods for computing the Jacobian matrix in one of the following representations: sparse perturbation, full perturbation, sparse analytical, and full analytical. The sparse methods attempt to improve performance by taking advantage of sparsity information associated with the Jacobian matrix. Similarly, the analytical methods attempt to improve performance by computing the Jacobian using analytical equations rather than the perturbation equations.
Since the applicability of these representations is highly model dependent, an auto option directs Simulink to use a heuristic to choose an appropriate representation for your model. In the case of a model that has a large number of states and for which the Jacobian is computed in sparse analytical form, the performance improvement may be substantial. In general, the performance improvement achieved varies from model to model.
For implicit Simulink solvers, the numerical sparse perturbation method for solving the Jacobian supports both RSim and Rapid Accelerator mode.
The zero-crossing bracketing algorithm now uses a smaller tolerance for defining the interval in which an event occurs. The resulting increased accuracy of locating an event means that existing models may exhibit slightly different numerical results.
In Accelerator mode and in Rapid Accelerator mode, a build has historically resulted in the creation of generated code, respectfully, in the modelname_accel_rtw and the modelname_raccel_rtw folders in the current working folder. However, in order to be more consistent with other builds, in R2010a and future releases, these files will be created in the slprj/accel/modelname and the slprj/raccel/modelname folders.
For model efficiency, use the Icon & Ports pane to run MATLAB code and to define variables used by the mask icon drawing commands. In releases earlier than R2010a, you had to use the Initialization pane to define variables used for icon drawing.
Simulink executes the MATLAB code in the Icon & Ports pane only when the block icon needs to be drawn. If you include variables used by mask icon drawing commands in the Initialization pane, Simulink evaluates the variables as part of simulation and code generation.
For more information, see Defining a Mask Icon.
Compatibility Considerations. Starting in R2010a, you can execute any MATLAB function in the Ports & Icons pane of the Mask Editor. If a variable in the mask workspace has the same name as a function in the Ports & Icons pane, Simulink returns an error.
The For Each Subsystem block is very useful for modeling scenarios where you need to repeat the same algorithm on individual elements (or submatrices) of an input signal. The set of blocks within the subsystem represent the algorithm that is to be applied to a single element (or submatrix) of the original signal. You can configure the inputs of the subsystem to decompose the corresponding inputs into elements (or submatrices), and configure the outputs to suitably concatenate the processed results. Additionally, each block that has states inside this subsystem maintains separate sets of states for each element or submatrix it processes. Consequently, the operation of this subsystem is akin to copying the contents of the subsystem as many times as the number of elements in the original input signal, and then processing each element through its respective subsystem copy.
An additional benefit of this subsystem is that it may be utilized to improve code reuse in Real-Time Workshop generated code for certain models. Consider a model containing two reusable Atomic Subsystems with the same scalar algorithm applied to each element of the signal. If the input signal dimensions for these subsystems are different, you will find that two distinct functions are produced in the code generated by Real-Time Workshop for this model. Now, if you were to convert the two subsystems to For Each Subsystems such that the contents of each processes a single scalar element, then you will find that the two subsystems produce a single function in the code generated by Real-Time Workshop. This function is parameterized by the number of elements to be processed.
A new Function-Call Split block allows you to branch periodic and asynchronous function-call signals and connect them to multiple function-call subsystems (or models). These subsystems (or models) are guaranteed to execute in the order determined by their data dependencies. If a deterministic order cannot be computed, the model produces an error.
To test the validity of your function-call connections, use the Model Advisor diagnostic, Check usage of function-call connections. This diagnostic determines if:
Configurations > Diagnostics > Connectivity > Invalid function-call connection is set to error
Configuration Parameters > Diagnostics > Connectivity > Context-dependent inputs is set to Enable All
You can use trigger ports, which you define with a Trigger block, in new ways:
Place edge-based (rising, falling, or either), as well as function-call, trigger ports at the root level of a model. Before R2010a, to place a trigger port in a root-level model, you had to set the trigger type to function-call.
Place triggered ports in models referenced by a Model block. See Triggered Models.
Lock down the data type, port dimension, and trigger signal sample time. To specify these values, use the new Signal Attributes pane of the Block Parameters dialog box of the Trigger block. Specifying these attributes is useful for unit testing and running standalone simulation of a subsystem or referenced model that has an edge-based trigger port. See Triggered Models.
Compatibility Considerations. When you add a trigger port to a root-level model, if you use the File > Save As option to specify a release before R2010a, Simulink replaces the trigger port with an empty subsystem.
Select the new SupportModelReferenceSimTargetCustomCode model parameter to have SIM target Accelerator code generation include Stateflow and Embedded MATLAB custom code for a referenced model. The default setting for this parameter is off.
Embedded MATLAB Function blocks are now able to use global data within a Simulink model and across multiple models.
This feature provides these benefits:
Allows you to share data between Embedded MATLAB Function blocks and other Simulink blocks without introducing additional input and output wires in your model. This reduces unnecessary clutter and improves the readability of your model.
Provides a means of scoping the visibility of data within your model.
For more information, see Using Global Data with the MATLAB Function Block in the Simulink documentation.
Embedded MATLAB Function blocks now support logical indexing when variable sizing is enabled. Embedded MATLAB supports variable-size data by default for MEX and C/C++ code generation.
For more information about logical indexing, see Using Logicals in Array Indexing in the MATLAB documentation.
Embedded MATLAB Function blocks now support Simulink buses containing variable-size matrices as inputs and outputs.
Embedded MATLAB Function blocks now support tunable structure parameters. See Working with Structure Parameters in MATLAB Function Blocks.
In existing models, simulation and code generation for Embedded MATLAB Function blocks always behave as if the Treat as atomic unit check box in the Subsystem Parameters dialog box is selected. Starting in R2010a, this check box is always selected for consistency with existing behavior.
The new Simulink.findVars function returns information about workspace variables and their usage. For example, you can use Simulink.findVars, sometimes in conjunction with other Simulink functions, to:
Identify all workspace variables used by a model or block
Identify any workspace variables unused by a model or block
Search a model for all places where a specified variable is referenced
Subdivide a model, including only necessary variables with each model
See Simulink.findVars and the other Simulink functions referenced on that page for more information.
You can create a MATLAB structure that groups base workspace variables into a hierarchy, and dereference the structure fields to provide values in Simulink block parameter expressions. This technique reduces base workspace clutter and allows related workspace variables to be conveniently grouped. However, in previous releases you could not use a MATLAB structure as a masked subsystem or a model reference argument, and no value given by a MATLAB structure field could be tuned. These restrictions limited the usefulness of MATLAB structures for grouping variables used in block parameter expressions.
In R2010a, these restrictions no longer apply to MATLAB structures that contain only numeric data. You can use a numeric structure, or any substructure within it, as a masked subsystem or a model reference argument, thereby passing all values in the structure with a single argument. You can also control MATLAB structure tunability using the same techniques that control MATLAB variable tunability. In R2010a, all values in a given structure must be either tunable or nontunable. See Using Structure Parameters for more information.
The Simulink.saveVars function was added in R2009b but was incompletely documented. See New Function Exports Workspace Variables and Values for more information.
Custom floating-point types, float(TotalBits, ExpBits), are no longer supported.
Compatibility Considerations. If you have code that uses custom floating-point types, modify this code using one of these methods:
Replace calls to float(TotalBits, ExpBits) with calls to fixdt('double') or fixdt('single') as appropriate.
Create your own custom float replacement function.
Write a MATLAB function custom_float_user_replacement and place the file on your MATLAB path. This function must take TotalBits and ExpBits as input arguments and return a supported numerictype object, such as fixdt('double') or fixdt('single').
For example,
function DataType = custom_float_user_replacement( TotalBits, ExpBits )
if (TotalBits <= 32) && (ExpBits <= 8)
DataType = numerictype('single');
else
DataType = numerictype('double');
endIn R2010a and future releases, if the file custom_float_user_replacement.m is on your MATLAB path, calls to float(TotalBits, ExpBits) automatically call custom_float_user_replacement(TotalBits, ExpBits).
You can log the values of a local or global data store data variable for all the steps in a simulation. Data store logging is useful for:
Model debugging – view the order of all data store writes
Confirming a model modification – use the logged data to establish a baseline for comparing results to identify the impact of a model modification
To log a local data store that you create with a Data Store Memory block:
Use the new Logging pane of the Block Parameters dialog box for the Data Store Memory block.
Enable data store logging with the new Configuration Parameters > Data Import/Export > Data stores parameter.
To log a data store defined by a Simulink.Signal object, from the MATLAB command line, set DataLogging (which is a property of the LoggingInfo property of Simulink.Signal) to 1.
For details, see Logging Data Stores. To see an example of logging a global data store, run the sldemo_mdlref_dsm demo.
Simulink creates empty variables for state logging (xout) or final state logging (xfinal), if both of these conditions apply:
A model has no states.
In the Configuration Parameters > Data Import/Export pane, you enable the States, Final States, or both parameters (the default is off).
Compatibility Considerations. If you configure your model to return empty variables when it has no states, then a possible result is that Simulink creates more variables than it did in previous releases.
Using model variants, running different models in batch mode, tuning models, or reconfiguring models can produce unexpected results based on the state values. For example, if you simulate a model that produces a state value, and then run a model variant that produces no state, Simulink overwrites the state value with an empty variable. If your model depends on the first state value not being overwritten if no state is returned in a subsequent simulation (which was the case in previous releases), then you get unexpected results.
The To File block now supports:
Saving very large data sets that may be too large to fit in RAM
Saving logged data up until the point of a premature ending of simulation processing. Previously, if the simulation processing did not complete, then To File did not store any logged data for that simulation.
A new Save format parameter to control whether the block uses Timeseries or array format for data.
Use Timeseries format for writing multidimensional, real, or complex inputs, with different data types, (for example, built-in data types, including Boolean; enumerated (enum) data and fixed-point data with a word length of up to 32 bits.
Use Array format only for one-dimensional, double, noncomplex inputs. Time values are saved in the first row. Additional rows correspond to input elements.
Compatibility Considerations. For data saved using MAT file versions prior to 7.3, the From File block can only load two-dimensional arrays consisting of one-dimensional, double, noncomplex samples. To load data of any other type, complexity, or dimension, use a Timeseries object and save the file using MAT file version 7.3 or later. For example, use 'save file_name -v7.3 timeseries_object':
save file_name -v7.3 timeseries_object
The From File block now supports:
Incremental loading of very large data sets that may be too large to fit in RAM
Built-in data types, including Boolean
Fixed-point data with a word length of up to 32 bits
Complex data
Multidimensional data
You can now use a root (top-level) Inport block to supply fixed-point data that is contained in a structure.
In releases before R2010a, you had to use a Simulink.Timeseries object instead of a structure.
To improve model reliability and robustness, avoid mixing Mux blocks and bus signals. To help you use Mux blocks and bus signals properly, R2010a adds these enhancements:
When Simulink detects Mux block and bus signal mixtures, the Mux blocks used to create bus signals diagnostic now generates:
A warning when all the following conditions apply:
You load a model created in a release before R2010a.
The diagnostic is set to 'None'.
Simulink detects improper Mux block usage.
An error for new models
Two new diagnostics in the Configuration Parameters > Diagnostics > Connectivity pane:
The Non-bus signals treated as bus signals diagnostic detects when Simulink implicitly converts a non-bus signal to a bus signal to support connecting the signal to a Bus Assignment or Bus Selector block.
The Repair bus selections diagnostic repairs broken selections in the Bus Selector and Bus Assignment block parameters dialog boxes that are due to upstream bus hierarchy changes.
Compatibility Considerations. In R2010a, if you load a model created in a prior release, you might get warning messages that you did not get before. To avoid getting Mux block-related warnings for existing models that you want to load in R2010a, use the slreplace_mux function to substitute Bus Creator blocks for any Mux blocks used to create buses signals.
In releases before R2010a:
For virtual buses, you could specify a non-zero scalar or vector initial condition (IC) value that applies to all elements of the bus. You could use a vector value only if all bus elements use the same data type.
For nonvirtual buses, the only value you could specify was zero.
In R2010a, you can create a MATLAB structure for an IC. You can:
Specify ICs for all or a subset of the bus elements.
Use the new Simulink.Bus.createMATLABStruct helper method to create a full IC structure.
Use the new Model Advisor Simulink check, Check for partial structure parameter usage with bus signals, to detect when structure parameters are not consistent in shape with the associated bus signal.
Using IC structures helps you to:
Specify nonzero initial conditions
Specify initial conditions for mixed-dimension signals
Apply a different IC for each signal in the bus
Specify ICs for a subset of signals in a bus without specifying ICs for all the signals
Use the same ICs for multiple blocks, signals, or models
For information about creating and using initial condition structures, see Specifying Initial Conditions for Bus Signals.
The following S-functions provide a programmatic interface for working with buses:
S-function | Description |
|---|---|
Get the signal complexity for a bus element. | |
| ssGetBusElementDataType | Get the data type identifier for a bus element. |
Get the dimensions of a bus element. | |
Get the name of a bus element. | |
Get the number of dimensions for a bus element. | |
Get the offset from the start of the bus data type to a bus element. | |
Get the number of elements in a bus signal. | |
Get the value of a block parameter for an S-function block. | |
Determine whether a data type identifier represents a bus signal. | |
Register a data type that a parameter in the Simulink data type table specifies. | |
Specify whether to convert the input bus signal for an S-function from virtual to nonvirtual. | |
Specify whether the output bus signal from an S-function must be virtual or nonvirtual. | |
Specify the name of the bus object that defines the structure and type of the output bus signal. |
You can use two new signal property parameters to get information about the type and hierarchy of a signal programmatically:
CompiledBusType
Returns information about whether the signal connected to a port is a bus, and if so, whether it is a virtual or nonvirtual bus
SignalHierarchy
Returns the signal name of the signal. If the signal is a bus, the parameter also returns the hierarchy and names of the bus signal.
See Model Parameters and View Information about Buses.
The new SignalNameFromLabel port parameter supports signal name propagation for Bus Creator block input signals whenever you change the name of an input signal programmatically. You can set this parameter with the set_param command, specifying either a port or line handle and the signal name to propagate.
See Model Parameters.
You can use the new Sqrt block to perform square-root calculations. This block includes the following functions:
| Function | Icon |
|---|---|
| sqrt |
|
| signedSqrt |
|
| rSqrt |
|
Compatibility Considerations. The sqrt and 1/sqrt functions no longer appear in the Math Function block. For backward compatibility, models with a Math Function block that uses one of these two functions continue to work. However, consider running the slupdate function on your model. slupdate replaces any Math Function block that uses sqrt or 1/sqrt with an equivalent Sqrt block that ensures the same behavior.
You can use the new Second-Order Integrator block to model second-order systems that have bounds on their states. This block is useful for modeling physical systems, for example, systems that use Newton's Second Law and have constraints on their motion.
Benefits of using this block include:
Highly accurate results
Efficient detection of zero crossings
Prevention of direct feedthrough and algebraic loops
You can use the new Find block to locate all nonzero elements of an input signal. This block outputs the indices of nonzero elements in linear indexing or subscript form and provides these benefits:
| When you use the block to... | You can... |
|---|---|
Convert logical indexing to linear indexing | Use the linear indices you get from processing a logical indexing signal as the input to a Selector or Assignment block |
Extract subscripts of nonzero values | Use the subscript of matrices for 2-D or higher-dimensional signal arrays to aid with image processing |
Represent sparse signals | Use indices and values as a compact representation of sparse signals |
The new PauseFcn and ContinueFcn callbacks detect clicking of the Pause and Continue buttons during simulation. You can set these callbacks using the set_param command or the Callbacks tab of the Model Properties dialog box. Both the PauseFcn and ContinueFcn callbacks support Normal and Accelerator simulation modes.
The Gain block now supports the Parameter data type setting of Inherit: Inherit from 'Gain'. This enhancement provides the benefit of inheriting the parameter data type directly from the Gain parameter. For example:
| If you set Gain to... | The parameter data type inherits... |
|---|---|
| 2 | double |
| single(2) | single |
| int8(2) | int8 |
The Direct Lookup Table (n-D) block now supports:
Multidimensional signals for the table input port
Fixed-point data types for the table input port
Explicit specification of the table data type in the block dialog box
The icon for the Multiport Switch block now shows the values of indices on data port labels. This enhancement helps you identify the data inputs without having to open the block dialog box:
| Block Parameter Settings | Block Icon |
|---|---|
|
|
|
|
When you load existing models that contain the Multiport Switch block, the following parameter mapping occurs:
| Block Parameter Settings of a Model from R2009b or Earlier | Block Parameter Settings When You Load the Model in R2010a | ||
|---|---|---|---|
|
| ||
|
|
The following command-line parameter mapping applies:
| Old Prompt on Block Dialog Box | New Prompt on Block Dialog Box | Old Command-Line Parameter | New Command-Line Parameter |
|---|---|---|---|
| Number of inputs | Number of data ports | Inputs | Same |
| Use zero-based indexing | Data port order | zeroidx | DataPortOrder |
The parameter mapping in R2010a ensures that you get the same block behavior as in previous releases.
Compatibility Considerations. In R2010a, a warning appears at compile time when your model contains a Multiport Switch block with the following configuration:
The control port uses an enumerated data type.
The data port order is contiguous.
During edit time, the block icon cannot show the mapping of each data port to an enumerated value. This configuration can also lead to unused ports during simulation and unused code during Real-Time Workshop code generation.
Run the slupdate function on your model to replace each Multiport Switch block of this configuration with a block that explicitly specifies data port indices. Otherwise, your model might not work in a future release.
In R2010a, the following Multiport Switch block configuration also produces a warning at compile time:
The control port uses a fixed-point or built-in data type.
The data port order is contiguous.
At least one of the contiguous data port indices is not representable with the data type of the control port.
The warning alerts you to unused ports during simulation and unused code during Real-Time Workshop code generation.
When you select sin, cos, or sincos for the Trigonometric Function block, additional parameters are available.
| New Block Parameter | Purpose | Benefit |
|---|---|---|
| Approximation method | Specify the type of approximation the block uses to compute output: None or CORDIC. | Enables you to use a faster method of computing block output for fixed-point and HDL applications. |
| Number of iterations | For the CORDIC algorithm, specify how many iterations to use for computing block output. | Enables you to adjust the precision of your block output. |
This block now supports fixed-point data types when you select sin, cos, or sincos and set Approximation method to CORDIC.
The following Simulink blocks now support enumerated data types:
For more information, see Enumerations and Modeling in the Simulink User's Guide.
In R2010a, you can select the following data types directly for the Output data type parameter of the Lookup Table Dynamic block:
double
single
int8
uint8
int16
uint16
int32
uint32
boolean
Previously, you had to enter an expression for Output data type to specify a built-in data type.
If the input data type to a Compare To Zero or Wrap To Zero block cannot represent zero, detection of this parameter overflow occurs. In the Diagnostics > Data Validity pane of the Configuration Parameters dialog box, set Parameters > Detect overflow to warning or error.
The Data Type Duplicate block is now a built-in block. Previously, this block was a masked S-Function. The read-only BlockType parameter has changed from S-Function to DataTypeDuplicate.
Compatibility Considerations. In R2010a, signal propagation might behave differently from previous releases. As a result, your model might not compile under these conditions:
Your model contains a Data Type Duplicate block in a source loop.
Your model has underspecified signal data types.
If your model does not compile, set data types for signals that are not fully specified.
In a future release, the Lookup Table and Lookup Table (2-D) blocks will no longer appear in the Simulink Library Browser. Consider replacing instances of those two blocks by using 1-D and 2-D versions of the Lookup Table (n-D) block. Among other enhancements, the Lookup Table (n-D) block supports the following features that the other two blocks do not:
Specification of parameter data types different from input or output signal types
Reduced memory use and faster code execution for evenly spaced breakpoints that are nontunable
Fixed-point data types with word lengths up to 128 bits
Specification of index search method
Specification of action for out-of-range inputs
To upgrade your model:
| Step | Description | Reason |
|---|---|---|
| 1 | Run the Simulink Model Advisor check for Check model, local libraries, and referenced models for known upgrade issues. | Identify blocks that do not have compatible settings with the Lookup Table (n-D) block. |
| 2 | For each block that does not have compatible settings with the Lookup Table (n-D) block:
| Modify each Lookup Table or Lookup Table (2-D) block to make them compatible. |
| 3 | Repeat steps 1 and 2 until you are satisfied with the results of the Model Advisor check. | Ensure that block replacement works for the entire model. |
| 4 | Run the slupdate function on your model. | Perform block replacement with the Lookup Table (n-D) block. |
Compatibility Considerations. The Model Advisor check groups all Lookup Table and Lookup Table (2-D) blocks into three categories:
Blocks that have compatible settings with the Lookup Table (n-D) block
Blocks that have incompatible settings with the Lookup Table (n-D) block
Blocks that have repeated breakpoints
Blocks with Compatible Settings
When a block has compatible parameter settings with the Lookup Table (n-D) block, automatic block replacement can occur without backward incompatibilities.
| Lookup Method in the Lookup Table or Lookup Table (2-D) Block | Parameter Settings in the Lookup Table (n-D) Block After Block Replacement | |
|---|---|---|
| Interpolation | Extrapolation | |
| Interpolation-Extrapolation | Linear | Linear |
| Interpolation-Use End Values | Linear | None-Clip |
| Use Input Below | None-Flat | Not applicable |
Depending on breakpoint characteristics, the Lookup Table (n-D) block uses one of two index search methods.
| Breakpoint Characteristics in the Lookup Table or Lookup Table (2-D) Block | Index Search Method in the Lookup Table (n-D) Block After Block Replacement |
|---|---|
| Not evenly spaced | Binary search |
| Evenly spaced and tunable | A prompt appears, asking you to select Binary search or Evenly spaced points. |
| Evenly spaced and nontunable |
The Lookup Table (n-D) block also adopts other parameter settings from the Lookup Table or Lookup Table (2-D) block. For parameters that exist only in the Lookup Table (n-D) block, the following default settings apply after block replacement:
| Lookup Table (n-D) Block Parameter | Default Setting After Block Replacement |
|---|---|
| Breakpoint data type | Inherit: Same as corresponding input |
| Action for out-of-range input | None |
Blocks with Incompatible Settings
When a block has incompatible parameter settings with the Lookup Table (n-D) block, the Model Advisor shows a warning and a recommended action, if applicable.
If you perform the recommended action, you can avoid incompatibility during block replacement.
If you use automatic block replacement without performing the recommended action, you might see numerical differences in your results.
| Incompatibility Warning | Recommended Action | What Happens for Automatic Block Replacement |
|---|---|---|
The Lookup Method is Use Input Nearest or Use Input Above. The Lookup Table (n-D) block does not support these lookup methods. | Change the lookup method to one of the following:
| The Lookup Method changes to Interpolation - Use End Values. In the Lookup Table (n-D) block, this setting corresponds to:
You also see a message that explains possible numerical differences. |
The Lookup Method is Interpolation - Extrapolation, but the input and output are not the same floating-point type. The Lookup Table (n-D) block supports linear extrapolation only when all inputs and outputs are the same floating-point type. | Change the extrapolation method or the port data types of the block. | |
The block uses small fixed-point word lengths, so that interpolation uses only one rounding operation. The Lookup Table (n-D) block uses two rounding operations for interpolation. | None | You see a message that explains possible numerical differences. |
Blocks with Repeated Breakpoints
When a block has repeated breakpoints, the Model Advisor recommends that you change the breakpoint data and rerun the check. You cannot perform automatic block replacement for blocks with repeated breakpoints.
The Elementary Math block is now obsolete. You can replace any instance of this obsolete block in your model by using one of these blocks in the Math Operations library:
Compatibility Considerations. If you open a model that contains an Elementary Math block, a warning message appears. This message suggests running slupdate on your model to replace each instance of the obsolete block with an appropriate substitute.
If you try to start simulation or generate code for a model that contains this obsolete block, an error message appears.
In R2010a, when you add or modify a DocBlock block that uses Microsoft® RTF format and you save the model, Simulink compresses the RTF file. The saved RTF files with images are much smaller than in previous releases.
Compatibility Considerations. In R2010a, if you use slupdate or save a model that includes a DocBlock block that uses RTF format, you cannot run the model in an earlier version of Simulink.
To run a model that has a compressed RTF file in an earlier version of Simulink, use Save As to save the model in the format of the earlier release.
In R2010a, the PID Controller (with Approximate Derivative) and PID Controller blocks of the Simulink Extras library no longer appear in the Simulink Library Browser. For models created using R2009b or earlier, consider using the slupdate function to replace these blocks with the new PID Controller block of the Simulink/Continuous or Simulink/Discrete library. Among other enhancements, the new PID Controller block supports:
Continuous-time and discrete-time modeling
Ideal and Parallel controller forms
Automatic PID tuning (requires a Simulink Control Design™ license)
For more information, see the PID Controller and PID Controller (2 DOF) block reference pages.
Compatibility Considerations. For backward compatibility, simulation and code generation of models that contain the deprecated PID Controller (with Approximate Derivative) or PID Controller block continue to work.
The Model Explorer now supports column views, which specify sets of property columns to display in the Contents pane. The Model Explorer displays only the properties that are defined for the current column view. The Model Explorer does not add new properties dynamically as you add objects to the Contents pane. Using a defined subset of properties to display streamlines the task of exploring and editing model object properties and increases the density of the data displayed.
Model Explorer provides several standard column views with common property sets. You can:
Select the column view based on the task you are performing
Customize the standard column views
Create your own column views
Export and import column views saved in MAT-files, which you can share with other users
See The Model Explorer: Controlling Contents Using Views.
Compatibility Considerations. Column views replace the Customize Contents option provided in previous releases.
In R2010a, the Model Explorer provides a different interface for performing some of the tasks that you previously performed using View menu items. The following table summarizes differences between R2009b and R2010a.
| R2009b View Menu Item | R2010a Model Explorer Interface Change |
|---|---|
| Dialog View | Replaced by Show Dialog Pane |
| Customize Contents | Replaced by Column View > Show Details |
| Show Properties | Eliminated; select Column View > Show Details to specify properties to display |
| Mark Nonexistent Properties | Replaced by Show Nonexistent Properties as'-' |
| Library Browser | Eliminated (you can access the Library Browser from the Simulink Editor View menu) |
| List View Options | Replaced by Row Filter |
The Model Explorer now contains global options for specifying whether the Model Explorer displays the contents of library links and masked subsystems. These options also control whether the Model Hierarchy pane displays linked or masked subsystems. See Displaying Masked Subsystemsand Displaying Linked Library Subsystems.
Compatibility Considerations. In R2010a, when you select a masked subsystem node in the Model Hierarchy pane, the Contents pane displays the objects of the subsystem, reflecting the global setting to display masked subsystems. In prior releases, if you selected a masked subsystem node, you needed to right-click the node and select Look Under Mask to view the subsystem objects in the Contents pane.
In R2010a, the search results reflect the Show Library Links and Show Masked Subsystems settings. In previous releases, you specified the Look Inside Masked Subsystems and Look Inside Linked Subsystems options as part of the search options. R2010a does not include those search options.
The top-right section of the Contents pane displays a count of objects found for the currently selected nodes in the Model Hierarchy pane. The count indicates the number of objects displayed in the Contents pane, compared to the total number of objects in the currently selected nodes. The number of displayed objects is less than the total number of objects in scope when you filter some objects by using View > Row Filter options. See Object Count.
You can use the new for Variable Usage search type to search for blocks that use a variable that is defined in the base or model workspaces. See Search Bar Controls.
The Model Explorer Contents pane displays the following additional properties for signal lines:
Signal logging-related properties (such as DataLogging)
Storage class properties, including properties associated with custom storage classes for signals
Displaying these properties in the Contents pane enables batch editing. Prior to R2010a, you could edit these properties only in the Signal Properties dialog box.
In R2010a, right-clicking on a column heading in the Contents pane provides two new column insertion options:
Insert Path – adds the Path property column to the right of the selected column.
Insert Recently Hidden Columns – selects a property from a list of columns you recently hid, to add that property column to the right of the selected column
The Model Advisor 'By Task' folder now contains a Data Store Memory Blocks subfolder. This subfolder contains checks relating to Data Store Memory blocks that examine your model for:
Multitasking, strong typing, and shadowing issues
An enabled status of the read/write diagnostics
Read/write issues
A new –h command-line option allows you to print a summary of the available options for RSim executable targets.
The Simulink.SimulationOutput class now has a get method. After simulating your model, you can use this method to access simulation results from the Simulink.SimulationOutput object.
The Simulink.SimState.ModelSimState class has a new snapshotTime property. You can use this property to access the exact time at which Simulink took a "snapshot" of the simulation state (SimState) of your model.
The saveAs method is added to the Simulink.ConfigSet class to allow you to easily save the settings of configuration sets as MATLAB functions or scripts. Using the MATLAB function or script, you can share and archive model configuration sets. You can also compare the settings in different configuration sets by comparing the MATLAB functions or scripts of the configuration sets.
For details, see Save a Configuration Set in the Simulink User's Guide.
In an R2008b release note, MathWorks announced that support for Ada S-functions in Simulink would be removed in a future release and a migration strategy would be forthcoming.
In this release, the addition of Technical Note 1821 facilitates your incorporating Ada code into Simulink without using Ada S-function support. This note, "Developing and Building Ada S-Functions for Simulink", is available at Technical Note 1821 and demonstrates:
How to build a C MEX S-function from Ada code without using the mex –ada command
An example of an Ada wrapper around a C MEX S-Function API
A new S-function API, ssGetCallSystemNumFcnCallDestinations, allows you to determine the number of function-call blocks that your S-function calls. Based on this returned number, you can then deduce whether or not your S-function calls a branched function-call.
You can call this SimStruct function from mdlSetWorkWidths or later in your S-function.
To allow a C MEX S-function to reside inside of a For Each Subsystem block, you must call the new ssSupportsMultipleExecInstances API and set the flag to true in the mdlSetWorkWidths method.
As for M-file S-functions, you must set the new flag block.SupportsMultipleExecInstances to true in the Setup section.
The Legacy Code Tool has been enhanced to support
Enumerated data types for input, output, parameters, and work vectors
Structured tunable parameters
For more information about data types that the Legacy Code Tool supports, see Supported Data Types. For more information about the Legacy Code Tool, see
Integrating Existing C Functions into Simulink Models with the Legacy Code Tool in the Writing S-Functions documentation
legacy_code function reference page
Compatibility Considerations. For enumerated data type support:
If you upgrade from R2008b or later release, you can continue to compile the S-function source code and continue to use the compiled output from an earlier release without recompiling the code.
If you upgrade from R2008a or earlier release, you cannot use enumerated types; the Simulink engine will display an error during simulation.
You cannot use tunable structured parameters with Legacy Code Tool in a release prior to R2010a.
MathWorks intends the Modeling Guidelines for High-Integrity Systems document to be for engineers developing models and generating code for high-integrity systems using Model-Based Design with MathWorks products. This document describes creating Simulink models that are complete, unambiguous, statistically deterministic, robust, and verifiable. The document focus is on model settings, block usage, and block parameters that impact simulation behavior or code generated by the Real-Time Workshop Embedded Coder product.
These guidelines do not assume that you use a particular safety or certification standard. The guidelines reference some safety standards where applicable, including DO-178B, IEC 61508, and MISRA C®.
You can use the Model Advisor to support adhering to these guidelines. Each guideline lists the checks that are applicable to that guideline.
For more information, see Modeling Guidelines for High-Integrity Systems in the Simulink documentation.
MathWorks Automotive Advisory Board (MAAB) involves major automotive original equipment manufacturers (OEMs) and suppliers in the process of evolving MathWorks controls, simulation, and code generation products, including the Simulink, Stateflow, and Real-Time Workshop products. An important result of the MAAB has been the "MathWorks Automotive Advisory Board Control Algorithm Modeling Guidelines Using MATLAB, Simulink, and Stateflow." Help for the Simulink product now includes these guidelines. The MAAB guidelines link to relevant Model Advisor MAAB check help and MAAB check help links to relevant MAAB guidelines.
For more information, see MathWorks Automotive Advisory Board Control Algorithm Modeling Guidelines Using MATLAB, Simulink, and Stateflow in the Simulink documentation.
 | Version 7.6 (R2010b) Simulink Software | Version 7.4.1 (R2009bSP1) Simulink Software |  |
Learn more about Simulink through this collection of videos, articles, technical literature and the Getting Started with Simulink Guide.
| © 1984-2012- The MathWorks, Inc. - Site Help - Patents - Trademarks - Privacy Policy - Preventing Piracy - RSS |
