|
|
|
| R2012a Documentation → Simulink | |
Learn more about Simulink |
|
| Contents | Index |
This table summarizes what's new in V7.7 (R2011a):
| 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:
Simulink 7.7 supports the restoring of a SimState from a MAT file saved in a previous version of Simulink. During this operation, Simulink restores as much of the SimState object as possible and automatically resets the simulation start time to the stop time of the SimState object.
You can choose to receive a warning or an error by setting a new diagnostic, SimState object from earlier release, on the Diagnostic Pane of the Configuration Parameters dialog.
The processing of the absolute tolerance parameter in the Solver configuration pane, and of the absolute tolerance parameters for continuous blocks and S-functions with continuous states, has been enhanced. As a result, these parameters provide a more robust and consistent behavior. These error tolerances are used by variable-step solvers to control integration error for continuous states in a model.
A new SimStruct function ssSetStateAbsTol has been introduced to allow for setting the absolute tolerances for the S-Function continuous states in models using a variable-step solver. Use of ssGetAbsTol to either get or set absolute tolerances is not recommended. Instead, use ssGetStateAbsTol and ssSetStateAbsTol to get and set tolerances, respectively.
You can refresh linked blocks and Model blocks in a library or model using the Simulink Editor. Select the Edit > Links and Model Blocks > Refresh.
Refreshing the linked blocks updates the linked blocks to reflect any changes to the original library block. In releases before R2011a, to update linked blocks, you had to take one of the following actions:
Close and reopen the library that contains the linked blocks that you want to refresh.
Update the diagram (Edit > Links and Update Diagram or Ctrl+D).
You can update a specific Model block by right-clicking the Model block and selecting Refresh.
Compatibility Considerations. The new menu option, Edit > Links and Model Blocks > Refresh menu item replaces Edit > Model Blocks > Refresh Model Blocks. Both the old and new options update Model blocks in the same way.
The Model Variants block now displays model names for all variant choices, making it easier to select and configure available variants.
See Setting Up Model Variants.
You can protect a model using the Simulink Editor. Right-click the Model block that references the model for which you want to generate protected model code. In the context menu, select Code Generation > Generate Protected Model. For details, see Creating a Protected Model.
In earlier releases, you had to use the Simulink.ModelReference.protect command to create a protected model.
In R2011a, Embedded MATLAB Function blocks were renamed as MATLAB Function blocks in Simulink models. The block also has a new look:
Compatibility Consideration. If you have scripts that refer to Embedded MATLAB library blocks by path, you need to update the script to reflect the new block name. For example, if your script refers to simulink/User-Defined Functions/Embedded MATLAB Function or eml_lib/Embedded MATLAB Function, change Embedded MATLAB Function to MATLAB Function.
MATLAB Function blocks now support buses as shared data in Data Store Memory blocks.
The Signal Logging Selector is a new centralized signal logging tool for:
Reviewing all signals in a model hierarchy that are configured for logging (set with the Signal Properties dialog box)
Overriding signal logging settings for specific signals
Controlling signal logging throughout a model reference hierarchy in a more streamlined way than in previous releases
You can use the Signal Logging Selector with Simulink and Stateflow signals.
To open the Signal Logging Selector, in the Configuration Parameters > Data Import/Export pane, select the Signal Logging Selector button. For a Model block, you can right-click the block and select the Log Referenced Signals menu item. (The Signal Logging Selector replaces the Model Reference Signal Logging dialog box.)
See Overriding Signal Logging Settings and Using the Signal Logging Selector to View the Signal Logging Configuration.
You can now select a format for signal logging data. Use the Configuration Parameters > Data Import/Export > Signal logging format parameter to select the format:
ModelDataLogs — Simulink.ModelDataLogs format (default; before R2011a, this format was the only one supported)
Dataset — Simulink.SimulationData.Dataset format
The Dataset format:
Uses MATLAB timeseries objects to store logged data (rather than Simulink.Timeseries and Simulink.TsArray objects). MATLAB timeseries objects allow you to work with logging data in MATLAB without a Simulink license.
Supports logging multiple data values for a given time step, which can be important for Iterator subsystem and Stateflow signal logging.
Provides an easy-to-analyze format for logged signal data for models with deep hierarchies, bus signals, and signals with duplicate or invalid names.
Supports the Simulation Data Inspector.
Avoids the limitations of the ModelDataLogs format. For example, for a virtual bus, ModelDataLogs format logs only one of multiple signals that share the same source block. For a description of ModelDataLogs format limitations, see Bug Report 495436.
To convert a model that contains referenced models to use the Dataset format throughout the model reference hierarchy, use the Simulink.SimulationData.updateDatasetFormatLogging function.
If you have logged signal data in the ModelDataLogs format, you can use the Simulink.ModelDataLogs.convertToDataset function to convert the ModelDataLogs data to Dataset format.
To work with Dataset format data, you can use properties and methods of the following classes:
For information about the signal logging format, see Specifying the Signal Logging Data Format
The From File block allows you to specify zero-crossing detection.
You can now define the type of output to use on the Signal Builder block now outputs signals. With this release, the Signal Builder block has two options:
Ports
Sends individual signals from the block. An output port named Signal N appears for each signal N. This option is the default setting. In previous releases, the block uses this type of signal output.
Bus
Sends single, virtual, nonhierarchical bus of signals from the block. An output port named Bus appears. This Bus option enables you to change your model layout without having to reroute Signal Builder block signals. You cannot use this option to create a bus of non-virtual signals.
For more information, see Defining Signal Output in the Simulink User's Guide
The Signal Builder block now shows the currently active group on its block mask.
The signalbuilder function has a new command, 'annotategroup'. This command enables the display of the current group name on the Signal Builder block mask.
The logic that Simulink uses to check whether design minimum and maximum values are within the specified data type range is now consistent with the logic that it uses to calculate best-precision scaling.
Simulink now checks both real-world values and quantized values for a block parameter, Simulink.Parameter object, or Simulink.Signal object against design minimum and maximum values. Prior to R2011a, Simulink checked only real-world values against design minimum and maximum values.
When Simulink checks the design minimum and maximum values for a Simulink.Signal object against the data type minimum and maximum values, it obtains the data type range in one of the following ways.
If the data type for a Simulink.Signal object is set, Simulink uses the range defined in the specification of that data type
If the data type for a Simulink.Signal object is set to auto, Simulink uses the range for the data type inferred from the initial value of the signal's fi object
Prior to R2011a, Simulink only used the data type range defined in the specification of that data type.
Simulink now checks the run-time parameter value of an S-function against the design minimum and maximum values when the parameter is updated at run-time and during compilation. Prior to R2011a, Simulink checked run-time parameter values of an S-function against the design minimum and maximum only at run-time.
For more information about block parameter range checking, see Checking Parameter Values.
An error is generated if the quantized value of a block parameter, Simulink.Parameter object, or Simulink.Signal object in your model is different from the real-world value and if this difference causes the quantized value to lie outside the design minimum and maximum range.
An error is generated if the initial value of a Simulink.Signal object in your model is a fi object and if this initial value is outside the range associated with that fi object.
An error is generated at compile time if the run-time parameter value of an S-function in your model is outside the design minimum and maximum range.
In this release, the Data Object Wizard is enhanced to suggest parameter objects for variables with the following data types:
Boolean
Enumerations
Structures
For information, see Working with Data Objects and Data Object Wizard.
Prior to this release, Simulink generated an error when the output of a Ground block was a signal object with an initial value, but did not do the same for such signal objects back propagated to the output port of a Ground block. As of R2011a, Simulink generates an error under both conditions.
You can no longer set the RTWInfo or CustomAttributes property of a Simulink data object from the MATLAB Command Window or a MATLAB script. Attempts to set these properties generate an error.
Although you cannot set RTWInfo or CustomAttributes, you can still set subproperties of RTWInfo and CustomAttributes.
Compatibility Considerations. Operations from the MATLAB Command Window or a MATLAB script, which set the data object property RTWInfo or CustomAttributes, generate an error.
For example, a MATLAB script might set these properties by copying a data object as shown below:
a = Simulink.Parameter; b = Simulink.Parameter; b.RTWInfo = a.RTWInfo; b.RTWInfo.CustomAttributes = a.RTWInfo.CustomAttributes; . . .
To copy a data object, use the object's deepCopy method.
a = Simulink.Parameter; b = a.deepCopy; . . .
Simulink now uses the Dimensions attribute of a source signal object to determine whether to register a global data store as a vector (1-D) or matrix (2-D). For example, if the Dimensions attribute of a source signal object is set to [1 N] or [N 1], Simulink registers the global data store as a matrix. Prior to R2011a, Simulink treated all global data stores as vectors.
The following table lists possible signal object dimension settings with what Simulink registers for a corresponding global data store:
| Source Signal Object Dimensions | Registered for Global Data Store |
|---|---|
| –1 | Get dimensions from InitialValue and interpret vectors as 1-D |
| N | Vector with N elements |
| [1 N] | 1xN matrix |
| [N 1] | Nx1 matrix |
Compatibility Considerations. If you specify the dimensions of the source signal object for a global data store as [1 N] or [N 1], Simulink now registers the data store as a matrix. Although this change has no impact on numeric results of simulation or execution of generated code, the change can affect the following:
Propagation of dimensions (for example, signals might propagate as [1 N] or [N 1] instead of N).
Signal and state logging
Vectors are logged as 2D matrices – [nTimeSteps width]
2-D matrices are logged as 3-D matrices – [M N nTimeSteps]
You can no longer use trigger signals that are defined as enumerations. A trigger signal represents an external input that initiates execution of a triggered subsystem. Prior to R2011a, Simulink supported enumerated trigger signals for simulation, but produced an error during code generation. This change clarifies triggered subsystem modeling semantics by making them consistent across simulation and code generation.
Compatibility Considerations. Use of enumerated trigger signals during simulation now generates an error. To work around this change, compare enumeration values, as appropriate, and apply the resulting Boolean or integer signal value as the subsystem trigger.
If you specify the DataType field of a Simulink.Parameter object as a bus, you must specify Value as a numeric structure. Prior to R2011a, Simulink would convert the data types of all fields of that structure to the data types of corresponding bus elements. As of R2011a, Simulink converts the data type of structure fields of type double only. If the data type of a field of the structure does not match the data type of the corresponding bus element and is not double, an error occurs.
This change does not affect the InitialValue field of Simulink.Signal objects. Data types of fields of a numeric structure for an initial condition must match data types of corresponding bus elements.
Compatibility Considerations. If the data type of a field of a numeric structure that you specify for Simulink.Parameter does not match the data type of the corresponding bus element and is not double, an error occurs. To correct the condition, set the data types of all fields of the structure to match the data types of all bus elements or set them to type double.
For more information, see Simulink.Parameter.
In a future release, data classes Simulink.CustomParameter and Simulink.CustomSignal will no longer be supported because they are equivalent to Simulink.Parameter and Simulink.Signal.
Compatibility Considerations. If you use the data class Simulink.CustomParameter or Simulink.CustomSignal, Simulink posts a warning that identifies the class and describes one or more techniques for eliminating it. You can ignore these warnings in R2011a, but consider making the described changes now because the classes will be removed in a future release.
Simulink has been generating warnings for usage of the following data class infrastructure features for several releases. As of R2011a, the features are no longer supported.
Custom storage classes not captured in the custom storage class registration file (csc_registration) – warning displayed since R14SP2
Built-in custom data class attributes BitFieldName and FileName+IncludeDelimiter – warning displayed since R2008b
| Instead of... | Use... |
|---|---|
| BitFieldName | StructName |
| FileName+IncludeDelimiter | HeaderFile |
Initial value of MPT data objects inside mpt.CustomRTWInfoSignal – warning displayed since R2006a
When you use a removed feature, Simulink now generates an error.
When loading a MAT-file that uses an unsupported feature, the load operation suppresses the generated error such that it is not visible. In addition, MATLAB silently deletes data that had been associated with the unsupported feature. To prevent loss of data when loading a MAT-file, load and resave the file with R2010b or earlier.
The following blocks support the use of bus and array of buses signals with data stores:
Benefits of using buses and arrays of buses with data stores include:
Simplifying the model layout by associating multiple signals with a single data store
Producing generated code that represents the data store data as structures that reflect the bus hierarchy
Writing to and reading from data stores without creating data copies, resulting in more efficient data access
For details, see Using Data Stores with Buses and Arrays of Buses.
Compatibility Considerations. Pre-R2011a models that use data stores work in R2011a without any modifications.
To save a model that uses buses with data stores to a pre-R2011a version, you need to restructure that model to not rely on using buses with data stores.
You can select specific bus or matrix elements to read from or write to a data store. To do so, use the Element Selection pane of the Data Store Read block and the Element Assignment pane of the Data Store Write block. Selecting bus or matrix elements offers the following benefits:
Reducing the number of blocks in the model. For example, you can eliminate a Data Store Read and Bus Selector block pair or a Data Store Write and Bus Assignment block pair for each specific bus element that you want to access.
Faster simulation of models with large buses and arrays of buses.
See Accessing Data Stores with Simulink Blocks.
The following blocks now support the use of an array of buses as an input signal:
For details about arrays of buses, see Combining Buses into an Array of Buses.
You can use the Bus Editor to:
Define or edit a Simulink.Parameter object with a bus object for its data type. In the Bus Editor, select the parameter and use one of these approaches:
Select the File > Create/Edit a Simulink.Parameter object menu item.
Click the Create/Edit a Simulink.Parameter
object icon (
) from the toolbar.
You can then edit the Simulink.Parameter object in the MATLAB Editor.
Invoke the Simulink.Bus.createMATLABStruct function for a bus object for which you want to create a full MATLAB structure. In the Bus Editor, select the bus object and use one of these approaches:
Select the File > Create a MATLAB structure menu item.
Click the Create a MATLAB structure icon
(
) from the toolbar.
You can then edit the MATLAB structure in the MATLAB Editor.
In R2011a, the following lookup table blocks have been replaced with newer versions, which differ from the previous versions as follows:
| Block | Enhancements to the Previous Version | Other Changes |
|---|---|---|
Lookup Table |
|
|
Lookup Table (2-D) |
|
|
Lookup Table (n-D) |
|
|
When you load models from earlier versions of Simulink that contain the Lookup Table, Lookup Table (2-D), and Lookup Table (n-D) blocks, those versions of the blocks appear. In R2011a, the new versions of the lookup table blocks appear only when you drag the blocks from the Simulink Library Browser into new models.
When you use the add_block function to programmatically add the Lookup Table, Lookup Table (2-D), or Lookup Table (n-D) blocks to a model, those versions of the blocks appear. If you want to add the new versions of the blocks to your model, change the source block path for add_block as follows:
| Block | Old Block Path | New Block Path |
|---|---|---|
| Lookup Table | simulink/Lookup Tables/Lookup Table | simulink/Lookup Tables/1-D Lookup Table |
| Lookup Table (2-D) | simulink/Lookup Tables/Lookup Table (2-D) | simulink/Lookup Tables/2-D Lookup Table |
| Lookup Table (n-D) | simulink/Lookup Tables/Lookup Table (n-D) | simulink/Lookup Tables/n-D Lookup Table |
To upgrade your model to use new versions of the Lookup Table and Lookup Table (2-D) blocks, follow these steps:
| Step | Description | Reason |
|---|---|---|
| 1 | Run the Simulink Model Advisor check for Check model, local libraries, and referenced models for known upgrade issues requiring compile time information. | Identify blocks that do not have compatible settings with the new 1-D Lookup Table and 2-D Lookup Table blocks. |
| 2 | For each block that does not have compatible settings:
| Modify each Lookup Table or Lookup Table (2-D) block to make them compatible with the new versions. |
| 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 1-D Lookup Table and 2-D Lookup Table blocks. |
Note that after block replacement, the block names that appear in the model remain the same. However, the block icons match the new ones for the 1-D Lookup Table and 2-D Lookup Table blocks.
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 new 1-D Lookup Table and 2-D Lookup Table blocks
Blocks that have incompatible settings with the new 1-D Lookup Table and 2-D Lookup Table blocks
Blocks that have repeated breakpoints
Blocks with Compatible Settings
When a block has compatible parameter settings with the new 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 New Block After Automatic Block Replacement | |
|---|---|---|
| Interpolation | Extrapolation | |
| Interpolation-Extrapolation | Linear | Linear |
| Interpolation-Use End Values | Linear | Clip |
| Use Input Below | Flat | Not applicable |
Depending on breakpoint characteristics, the new 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 New Block After Automatic 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 not tunable |
The new block also adopts other parameter settings from the Lookup Table or Lookup Table (2-D) block. For parameters that exist only in the new block, the following default settings apply after block replacement:
| Parameter in the New Block | Default Setting After Block Replacement |
|---|---|
| Breakpoint data type | Inherit: Same as corresponding input |
| Diagnostic for out-of-range input | None |
Blocks with Incompatible Settings
When a block has incompatible parameter settings with the new 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 new 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 new 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 new 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 new 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 Magnitude-Angle to Complex block now supports the following parameters:
The benefits of the new block parameters are as follows:
| 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. |
| Scale output by reciprocal of gain factor | For the CORDIC algorithm, specify whether or not to scale the real and imaginary parts of the complex output. | Provides a more accurate numerical result for the CORDIC approximation. |
This block now accepts and outputs fixed-point signals when you set Approximation method to CORDIC.
The Trigonometric Function block now supports complex exponential output: cos + jsin. This function works with the CORDIC algorithm.
This block also accepts inputs with unsigned fixed-point data types when you use the CORDIC approximation. In previous releases, only signed fixed-point inputs were supported.
The Shift Arithmetic block now supports specification of bit shift values from an input port. Previously, you could specify bit shift values only on the dialog box. This enhancement enables you to change bit shift values without stopping a simulation.
The block now also supports the following functionality:
| Enhancement | Benefit |
|---|---|
Specification of diagnostic for out-of-range bit shift values | Flags out-of-range bit shift values during simulation |
Option to check for out-of-range bit shift values in the generated code | Enables you to control the efficiency of the generated code |
The following parameter changes apply to the Shift Arithmetic block. 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 |
|---|---|---|---|
| Number of bits to shift right | Bits to shift: Number | nBitShiftRight | BitShiftNumber |
| Number of places by which binary point shifts right | Binary points to shift: Number | nBinPtShiftRight | BinPtShiftNumber |
The read-only BlockType property has also changed from SubSystem to ArithShift.
When the breakpoint input to a Prelookup, 1-D Lookup Table, 2-D Lookup Table, or n-D Lookup Table block falls within the range of valid breakpoint values, you can disable range checking in the generated code. By selecting Remove protection against out-of-range input in generated code on the block dialog box, your code can be more efficient.
Similarly, when the index input to an Interpolation Using Prelookup block falls within the range of valid index values, you can disable range checking in the generated code. By selecting Remove protection against out-of-range index in generated code on the block dialog box, your code can be more efficient.
The Remove protection against out-of-range index in generated code check box replaces the Check index in generated code check box from previous releases. When you load models with the Interpolation Using Prelookup block from previous releases, the following parameter mapping applies:
| Parameter Setting from Previous Releases | Parameter Setting for R2011a |
|---|---|
| Check index in generated code is selected. | Remove protection against out-of-range index in generated code is not selected. |
| Check index in generated code is not selected. | Remove protection against out-of-range index in generated code is selected. |
For backward compatibility, the command-line parameter CheckIndexInCode continues to work.
In R2011a, the dialog boxes for the Prelookup and Interpolation Using Prelookup blocks consolidate parameters related to data type attributes on a single tab named Data Types. This enhancement enables you to specify data type attributes more quickly on the block dialog box.
For the Prelookup block, you can now specify breakpoint, index, and fraction attributes on a single tab.
For the Interpolation Using Prelookup block, you can now specify table, intermediate results, and output attributes on a single tab.
In previous releases, the Product of Elements block used two different algorithms for handling element-wise complex division. For example, for a matrix input with four elements (u1, u2, u3, and u4), the following behavior would apply:
For inputs with built-in integer and floating-point data types, the order of operations was 1/(u1*u2*u3*u4).
For inputs with fixed-point data types, the order of operations was ((((1/u1)/u2)/u3)/u4).
Starting in R2011a, the Product of Elements block uses a single algorithm for handling element-wise complex division. For inputs of integer, floating-point, or fixed-point type, the order of operations is always (((((1/u1)/u2)/u3)/u4)…/uN).
The Sign block now supports complex inputs of type double or single. The block output matches the MATLAB result for complex floating-point inputs.
When the input u is a complex scalar, the block output is:
sign(u) = u./ abs(u)
When an element of a vector or matrix input is complex, the block uses the same formula that applies to scalar input.
In R2011a, the MATLAB Fcn block has been renamed to Interpreted MATLAB Function block. The icon has also changed to match the new block name. However, all functionality and block parameters remain the same. The read-only BlockType property is also unchanged.
Existing scripts that use the add_block function to programmatically add the MATLAB Fcn block to models do not require any changes.
When you load existing models that contain the MATLAB Fcn block, the block name that appears in the model remains unchanged. However, the block icon matches the new one for the Interpreted MATLAB Function block.
In R2011a, the Environment Controller block has renamed the RTW port to Coder. This enhancement better reflects the purpose of that input port, which designates signals to pass through the block when code generation occurs for a model.
In R2011a, the block parameters Real-Time Workshop storage class and Real-Time Workshop storage type qualifier have been renamed to Code generation storage class and Code generation storage type qualifier, respectively. These two parameters appear on the State Attributes tab of the following block dialog boxes:
Discrete Filter
Discrete PID Controller
Discrete PID Controller (2DOF)
Discrete State-Space
Discrete Transfer Fcn
Discrete Zero-Pole
Discrete-Time Integrator
Memory
Unit Delay
In R2011a, the Action for out-of-range input parameter has been renamed as Diagnostic for out-of-range input for the following blocks:
Also, the Process out-of-range input parameter has been renamed as Extrapolation method for the Prelookup block.
For lookup table blocks that provide Interpolation method or Extrapolation method parameters, the following changes apply:
| Parameter Value from Previous Releases | Parameter Value in R2011a |
|---|---|
| None - Flat | Flat |
| None - Clip | Clip |
In R2011a, single-precision computations for elementary math operations are faster. This enhancement applies to the following simulation modes:
Normal
Accelerator
In R2011a, the Dead Zone block expands the region of zero output, or the dead zone, to include inputs (U) that equal the lower limit (LL) or upper limit (UL):
| Input | Output |
|---|---|
| U >= LL and U <= UL | Zero |
| U > UL | U – UL |
| U < LL | U – LL |
In previous releases, the dead zone excluded inputs that equal the lower or upper limit.
The PID Controller and PID Controller (2 DOF) blocks now display the current compensator formula in the block dialog box. This display reflects the current settings for controller type, controller form, and time domain.
In R2011a, the sample time of the Ground block is now constant (inf) regardless of the setting for Inline parameters in the Configuration Parameters dialog box.
Compatibility Considerations. Previously, if Inline parameters was off, the sample time of the Ground block depended on sample-time propagation. Now, the following conditions hold true:
Function-call subsystem blocks that have an unconnected function-call port now have the correct sample time of constant (inf) regardless of the setting for Inline parameters.
Function-call subsystem blocks that have a function-call port connected to a Ground block now have the correct sample time of constant (inf) regardless of the setting for Inline parameters.
Function-call subsystem blocks that have the Sample time type set to periodic now correctly error out when they are connected to a Ground block or unconnected.
The Function-Call Feedback Latch block allows you to break a feedback loop involving data signals between function-call signals. You can use this block for two specific scenarios:
If a loop involves parent and child function-call blocks (that is, the initiator of the child function-call block is inside the parent function-call block), then place this block on the feedback signal from the child to the parent. You can thus ensure that the value of the signal does not change during execution of the child.
If a loop involves function-call blocks connected to branches of the same function-call signal, then this block latches the signal at the input of the destination function-call block, and thereby allows it to execute prior to the source function-call block.
In either case, the latching results in the destination block reading a delayed signal from the previous execution of the source function-call block.
If an Outport block of a conditionally executed subsystem directly drives a Merge block, then the Outport block no longer requires the specification of an Initial Condition (IC) in simplified initialization mode. Simulink still expects the Merge block to specify an IC. This enhancement applies only when the Outport and Merge blocks are in the same model.
The Discrete Filter, Discrete FIR Filter, and Discrete Transfer Fcn blocks now have an Input processing parameter. This parameter enables you to specify whether the block performs sample- or frame-based processing on the input. To perform frame-based processing, you must have a DSP System Toolbox license.
The GetSet custom storage class can now be used for the inports and outports of Model blocks. To assign a GetSet custom storage class to the inport or outport of a referenced model block, use one of the following methods.
Assign the GetSet custom storage class to the root-level inport or outport of the referenced model.
Assign the GetSet custom storage class to scalar signals entering an inport of the referenced model block in the parent model, provided one of the following conditions is met.
The referenced model uses function prototype control to specify that the inport should be passed by value instead of being passed by pointer to the Model block's step function.
The inport to which the GetSet custom storage class is assigned should be passed by value.
Assign the GetSet custom storage class to a scalar signal leaving one of the outports of the referenced model block in the parent model. In this case, the referenced model must use function prototype control to specify that the outport should be the returned value of the function.
By default, the property column that you use for grouping (the group column) appears in the property table. That property also appears in the top row for each group.
To hide the group column, use one of the following approaches:
From the View menu, clear the Show Group Column check box.
Within the property table, right-click a column heading and clear the Show Group Column check box.
Multiple Plots in a View. The Simulation Data Inspector tool now supports the configuration of multiple plots into one view. On the Inspect Signals pane, on the View toolbar, select Show Details to display the View Details table.
You can create multiple views by clicking the New view from current button. In each view, you can:
Modify the number of plots by clicking the Layout column to display the plot matrix.
Name, save, and reload the view using the corresponding buttons.
Replace signal data for a run with the corresponding signal data of another run by clicking the Replace runs button.
For more information, see Visual Inspection of Signal Data in the Simulation Data Inspector Tool.
Display Run Properties. In R2011a, you can view the properties of a run. In the Signal Browser table, right-click a run name to view a list of options. To open the Run Properties dialog box, from the options list, select Properties.
New Toolbar Icons. The Simulation Data Inspector toolbar includes a new icon
for zooming out a section
of a plot. The previous zoom out icon
now performs a fit to
view operation, which enlarges a plot to fill the graph. To perform
either operation, select the icon, and click on a plot.
In R2011a, the Model Advisor tool now includes easier control of the By Product and By Task folders. In the Model Advisor, select View > Show By Product Folder or Show By Task Folder to show or hide each folder. These settings are persistent across MATLAB sessions.
In the By Task folder, there are two new subfolders:
Modeling and Simulation
Code Generation Efficiency
For more information on the Model Advisor GUI, see Consulting the Model Advisor.
The Configuration Parameters dialog box layout is improved to better support your workflows. The Optimization pane is reorganized into three panes:
General
Signals and Parameters
Stateflow
These panes make it easier to find parameters.
In R2011a, all tree nodes are collapsed by default. For details, see Configuration Parameters Dialog Box.
Due to an infrastructure change, if you have generated an S-function with a call to legacy_code that defines the S-function option singleCPPMexFile, you must regenerate the S-function to use it with this release of Simulink.
For more information, see the description of legacy_code and Integrating Existing C Functions into Simulink Models with the Legacy Code Tool.
Compatibility Considerations. If you have generated an S-function with a call to legacy_code that defines the S-function option singleCPPMexFile, regenerate the S-function to use it with this release of Simulink.
 | Version 7.8 (R2011b) Simulink Software | Version 7.6.1 (R2010bSP1) 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 |
