A Robust Control Toolbox™ license is no longer required to
use the systune
or looptune
commands
or to use Control System Tuner. You can now:
Tune control systems modeled in MATLAB^{®} (tunable genss
models)
with a Control System Toolbox™ license.
Tune control systems modeled in Simulink^{®} with a Simulink Control Design™ license.
The following still requires a Robust Control Toolbox license:
hinfstruct
command
Robust tuning of control systems with parameter uncertainty
using systune
, looptune
,
or Control System Tuner
Functionality  Result  Use This Instead  Compatibility Considerations 

a , b , c , d ,
and e properties of uss models.  Still works  A , B , C , D ,
and E respectively.  If your code uses any of these properties, consider modifying your code to use the new property names. 
cpmargin  Still works  ncfmargin  If your code uses cpmargin , modify it
to use ncfmargin instead. 
systune
Command or Control System Tuner App: Automatically tune controllers to maximize performance
over a range of parameter values Control System Tuner and the systune
command
now tune control systems for robustness against real parameter uncertainty
in the plant. You represent parameter uncertainty in your control
system model using uncertain real parameters ureal
or uss
.
The software automatically finds the worst combinations of parameter
values and tunes the controller to maximize performance over the parameter
uncertainty range.
In MATLAB, build a generalized statespace (genss
)
model of your control system using ureal
or uss
blocks
to represent real parameter uncertainty in the plant. You can tune
the model with systune
or in Control System Tuner
exactly as you would for a tunable control system model without uncertainty.
For a detailed example, see Robust
Tuning of Positioning System.
In Simulink, use linearization with block substitution
to replace one more blocks in the model with uncertain values represented
by ureal
or uss
objects.
(Requires Simulink Control Design software.) See Robust
Tuning of MassSpringDamper System.
In both cases, when you tune the model, the software automatically adjusts the tunable components to achieve the specified performance as well as possible throughout the uncertainty range. Analysis plots automatically display random samples of the uncertain system to give you a visual sense of the performance variation.
For more information about robust tuning generally, see Robust Tuning Approaches.
Previously, when you used systune
to tune
a model that had uncertainties, the software would set the uncertain
blocks to their nominal values before tuning the system. Now, systune
tunes
the model for robustness against those uncertainties. To recover the
old behavior, i.e., to tune a controller for the nominal system only,
use getNominal
to obtain the nominal value. For
example:
[CL,fSoft,GHard,info] = systune(getNominal(CL0),SoftReqs,HardReqs);
In this example, CL0
is a genss
model
containing uncertain blocks.
systune
and slTuner
: Automatically tune the Lookup Table and Interpolation blocks used
to model gainscheduled controllers in SimulinkYou can now use the slTuner
interface to
automatically tune control systems modeled in Simulink in which
plant dynamics change with operating conditions or time. (Requires Simulink Control Design software.)
In such gainscheduled control systems, the controller gains
vary as a function of one or more scheduling variables. In the Simulink model,
use the Lookup Table or Interpolation blocks
to implement the variable controller gains. You then use the new tunableSurface
command
to parameterize the dependency of these gains on the scheduling variables.
The software automatically tunes the coefficients of that parameterization
so that the control system meets the tuning requirements you specify
over the entire grid of schedulingvariable values. The software also
writes the tuned coefficients back to the Lookup Table or Interpolation blocks.
In previous releases, you could not parameterize Lookup
Table or Interpolation blocks in terms of the
functional form of its dependence on the scheduling variable. As a
result, you could not automatically tune a gainscheduled control
element and write the tuned coefficients back to the Simulink model.
Using systune
to tune and implement gainscheduled
controllers required a complex process of manually extracting coefficient
values and inserting them in the blocks.
For more details, see Set Up Simulink Models for Gain Scheduling.
For examples showing how to use tunableSurface
to
tune gainscheduled controllers implemented with Lookup Table blocks,
see:
tunableSurface
Object: Parameterize and tune gainscheduled controllers using improved workflow The new tunableSurface
object lets you
express gain in terms of tunable parameters for tuning gainscheduled
controllers with systune
. In such gainscheduled
control systems, the controller gains vary as a function of one or
more scheduling variables. You parameterize the dependency of controller
gains on the scheduling variables. The software automatically tunes
the coefficients of that parameterization so that the control system
meets the tuning requirements you specify over the entire grid of
schedulingvariable values. tunableSurface
replaces
the gainsurf
command.
In previous releases, you could use the gainsurf
command
to represent tunable surfaces for control system tuning. With that
command, you had to explicitly supply the values of the gain surface
calculated over the grid of design points. tunableSurface
simplifies
that workflow by allowing you to specify the gain surface in terms
of functions of the scheduling variables, such as the basis functions
of a polynomial expansion.
For more details about creating tunable gain surfaces, see:
tunableSurface
reference
page
tunableSurface
replaces gainsurf
,
which was used in previous releases to parameterize controller gains
as functions of scheduling variables. gainsurf
still
works, but might be removed in a future release. If you have scripts
or functions that use gainsurf
, consider updating
them to use tunableSurface
instead.
getNominal
command for extracting nominal value of uncertain modelUse getNominal
to replace the uncertain
elements of a generalized model with their nominal values. All other
control design blocks in the generalized model are unchanged. For
example, suppose that M
is a generalized statespace
(genss
) model that has both uncertain blocks
and tunable blocks. The command getNominal(M)
returns
a genss
model having the same tunable blocks
as M
.
For more information, see the getNominal
reference
page.
usample
samples uncertain blocks and preserves other control design blocks The usample
command now preserves
any nonuncertain control design blocks when you use it to sample
the uncertain elements of a generalized model. For example, suppose
that M
is a generalized statespace (genss
)
model that has both uncertain blocks and tunable blocks. The command usample(M,N)
samples
the uncertain blocks, and returns an array of genss
models
having the same tunable blocks as M
.
Previously, when applied to models having tunable control design
blocks, usample
used the current (nominal) value
of those blocks, and returned an array of numeric models. To recover
the previous behavior, use getValue
.
For example, the following command randomly samples the uncertain
blocks of M
, replaces the tunable blocks of M
with
their current values, and returns an array of numeric statespace
models.
Msamp = getValue(usample(M,N));
ultidyn
Use the SampleMaxFrequency
property of ultidyn
to
limit the natural frequency of dynamics when you take random samples
of ultidyn
blocks. For example, the following
command creates SISO uncertain dynamics.
dH = ultidyn('dH',[1 1],'SampleMaxFrequency',1);
When you take random samples of dH
, such
as with usample
, the dynamics of the
samples are no faster than 1 rad/s. The default value of SampleMaxFrequency
is Inf
(no
limit).
Also, the SampleStateDim
property of ultidyn
is
changed to SampleStateDimension
.
The property name SampleStateDim
still works,
but might be removed in a later release. If you have scripts or functions
that use SampleStateDim
, consider updating them
to use SampleStateDimension
instead.
Functionality  Result  Use This Instead  Compatibility Considerations 

systune(CL0,...) where CL0 contains
uncertain blocks  Tunes robustly against real parameter uncertainty in CL0  systune(getNominal(CLO),...)  Previously, systune used the nominal value
of all uncertain blocks in the tuned model. Now, use getNominal
explicitly to tune for the nominal system only. See Robust Tuning with systune Command or Control
System Tuner App: Automatically tune controllers to maximize performance
over a range of parameter values. 
gainsurf  Still works  tunableSurface  If you have scripts or functions that use gainsurf ,
consider updating them to use tunableSurface instead.
See tunableSurface Object: Parameterize and
tune gainscheduled controllers using improved workflow 
usample(M,N)  Samples uncertain control design blocks of M ,
and preserves other control design blocks  getValue(usample(M,N))  Previously, usample used the current value
of nonuncertain control design blocks. See usample samples uncertain blocks and preserves
other control design blocks 
SampleStateDim property of ultidyn  Still works  SampleStateDimension  Consider replacing SampleStateDim with SampleStateDimension . 
When you use Control System Tuner to tune a Simulink model of a control system, you can now generate multiple plant models by varying model parameters. You can then tune the control system to satisfy your specified tuning goals for all the resulting models.
Tuning to multiple models is useful to help ensure that the tuned control system is robust against parameter variations or changes in operating conditions. For example, if a parameter in your Simulink model represents a process temperature, you can generate multiple models spanning the range of expected temperature variations, and tune your control system to meet your design requirements for all those models at once.
For more information about tuning control systems for multiple models in Control System Tuner, see Robust Tuning Using Multiple Plant Models in Control System Tuner. For an example showing how to specify parameter variations for tuning with Control System Tuner, see Tuning Control System with Multiple Valued Plant Parameters using Control System Tuner.
Use the new syntax controlSystemTuner(sessionfile)
to
open Control System Tuner and load data from a saved session. When
you use Control System Tuner, you can click
Save Session to
save session data to disk such as tuning goals you have created, response
I/Os you have defined, operating points, and stored designs. The string sessionfile
is
the name of a session data file saved in the current working directory
or on the MATLAB path. The software also opens the Simulink model
associated with the saved session.
Quick Loop Tuning lets you use a loopshaping approach to tune SISO or MIMO feedback loops in Control System Tuner. You can use Quick Loop Tuning to tune control systems modeled in MATLAB or Simulink. With Quick Loop Tuning you can tune your system to meet target gain crossover and margin requirements without explicitly creating tuning goals that capture these requirements. You specify feedback loops to tune by selecting the control signals and measurement signals in a block diagram of your control system. Control System Tuner adjusts the tunable parameters of your system such that the openloop gain crossover falls within the desired frequency range with the gain and phase margins you specify.
For more information about using Quick Loop Tuning, see Quick Loop Tuning of Feedback Loops in Control System Tuner.
New tuning goals let you explicitly specify a target transient
response or a minimum disturbance rejection in a tuned control system.
These tuning goals are available both in Control System Tuner and
at the command line when tuning with systune
.
The transient response goal lets you shape how the closedloop system responds to a specific input signal. You specify the desired transient response as a reference model. The target transient response is the response of the reference model to an impulse, step, ramp, or custom input signal. To use the transient response goal:
In Control System Tuner, in the Tuning tab,
in the New Goal menu, select Transient
Response Matching
.
At the command line, specify the design requirement
using TuningGoal.Transient
.
The step rejection goal lets you specify a minimum standard for rejecting disturbances. You specify characteristics such as the maximum amplitude and settling time of the response at some point in your control system to a step disturbance injected at another point in the system. Alternatively, specify a reference system whose response to step input is the target response. To use the step rejection goal:
In Control System Tuner, in the Tuning tab,
in the New Goal menu, select Rejection
of Step Disturbances
.
At the command line, specify the design requirement
using TuningGoal.StepRejection
.
You can now generate a MATLAB script for control system tuning from Control System Tuner. Generated MATLAB scripts are useful when you want to programmatically reproduce a result you obtained interactively. You can also use generated code to perform multiple tuning operations with systematic variations in tuning configurations such as model operating point or tuning goals.
For more information, see Generate MATLAB Code from Control System Tuner for CommandLine Tuning.
New functionality gives you more flexibility when specifying
constraints on controller dynamics for control system tuning. The
following new features are available in both Control System Tuner
using Controller Poles Goal and when tuning at
the command line using TuningGoal.ControllerPoles
(formerly TuningGoal.StableController
).
You can now specify a minimum damping constant for the poles of a tunable block. Previously, the damping constant of controller poles could take any value between zero and 1.
You can now specify a negative value for the minimum decay rate of controller poles, allowing for unstable controllers. Previously, the minimum decay rate had to be positive, and therefore always enforced the stability of the constrained block.
Fixed integrators in the constrained tunable block are no longer considered when evaluating the constraint. In other words, the tuning goal now constrains locations of all poles in the block except fixed integrators, such as the I term in a PID controller.
For more information about these features, see:
Controller Poles Goal, for tuning in Control System Tuner.
The TuningGoal.ControllerPoles
reference
page, for tuning at the command line.
TuningGoal.StableController
has been renamed
to TuningGoal.ControllerPoles
. Scripts and functions
that use TuningGoal.StableController
do not generate
errors. However, TuningGoal.StableController
will
not be maintained in future releases. You should replace instances
of TuningGoal.StableController
in your code with TuningGoal.ControllerPoles
.
When you use TuningGoal.Poles
to constrain
the dynamics of a tuned control system, you can now directly specify
the minimum decay rate, minimum damping, and maximum natural frequency
when you create the tuning goal. To do so, use the following syntaxes:
R = TuningGoal.Poles(MinDecay,MinDamping,MaxFreq); R = TuningGoal.Poles(Location,MinDecay,MinDamping,MaxFreq);
Previously, to specify such constraints on controller dynamics,
you had to first create the tuning goal, and then modify its MinDecay
, MinDamping
,
and MaxFrequency
properties.
For more information, enter see the TuningGoal.Poles
reference
page.
The tuning requirement TuningGoal.StepResp
is
now called TuningGoal.StepTracking
.
Scripts and functions that use TuningGoal.StepResp
do
not generate errors. However, TuningGoal.StepResp
will
not be maintained in future releases. You should replace instances
of TuningGoal.StepResp
in your code with TuningGoal.StepTracking
.
The DisturbanceInput
property of the tuning
requirement TuningGoal.Rejection
is now called Location
,
to unify the names of similar properties of several tuning requirements.
If Req
is a TuningGoal.Rejection
requirement,
you can access this property using Req.Location
.
Scripts and functions that use the DisturbanceInput
property
do not generate errors. However, the DisturbanceInput
property
will not be maintained in future releases. You should replace instances
of DisturbanceInput
in your code with Location
.
Functionality  What Happens When You Use This Functionality?  Use This Instead  Compatibility Considerations 

TuningGoal.StableController  Still works  TuningGoal.ControllerPoles  Consider replacing TuningGoal.StableController with TuningGoal.ControllerPoles . 
TuningGoal.StepResp  Still works  TuningGoal.StepTracking  Consider replacing TuningGoal.StepResp with TuningGoal.StepTracking . 
DisturbanceInput property of TuningGoal.Rejection  Still works  Location property  Consider replacing DisturbanceInput with Location . 
The new Control System Tuner lets you interactively tune SISO or MIMO control systems modeled in MATLAB or Simulink. Control System Tuner tunes the control system parameters to meet design requirements you specify, such as reference tracking, disturbance rejection, stability margins, loops shapes, and sensitivity. You can examine multiple system responses in both the time and frequency domains to evaluate performance of the tuned control system.
If you have Simulink Control Design software, you can tune
a control system represented by a Simulink model. Control System
Tuner can tune most blocks used to create a control system in Simulink.
These blocks include Gain
, PID Controller
, Transfer
Fcn
, StateSpace
, ZeroPole
, Discrete
Filter
, and the LTI System
block. Any
controller architecture created using these blocks can be tuned. To
access Control System Tuner for tuning a Simulink model, select Analysis > Control Design > Control System Tuner.
Control System Tuner can also tune a control system represented
by a tunable genss
model. Any control architecture
constructed with Control Design Blocks such as ltiblock.pid
, ltiblock.tf
,
or realp
blocks can be tuned. To open Control System
Tuner for tuning a control system modeled in MATLAB, use the controlSystemTuner
command.
For more information about using Control System Tuner, see:
systune
and looptune
commandsNew TuningGoal
requirement objects allow
you to specify tuning objectives for automated tuning of control systems
with systune
and looptune
.
TuningGoal.StepResp
— Requires
that the step response between specified locations in the control
system match the step response of a specified reference system. For
details about this requirement, see the TuningGoal.StepResp
reference
page.
TuningGoal.LQG
— Specifies
a linearquadraticgaussian (LQG) goal for control system tuning.
This requirement lets you quantify control performance as an LQG cost.
For details about this requirement, see the TuningGoal.LQG
reference
page.
TuningGoal
requirements for control system tuning This release introduces a variety of improvements to TuningGoal
requirement
objects for automated tuning of fixedstructure control systems with systune
and looptune
.
TuningGoal.StableController
and TuningGoal.Poles
now
impose implicit stability constraints on controller or system dynamics.
This allows you to require poles of the controller or the closedloop
control system to be stable, without necessarily limiting the minimum
decay or maximum frequency of those poles. Previously, you had to
specify finite values for minimum decay and maximum frequency when
using these tuning goals.
The default values of the MinDecay
and MaxFrequency
properties
of these requirements have changed. If you have scripts that use TuningGoal.StableController
or TuningGoal.Poles
requirements
with default values, update those scripts to explicitly set the finite
values you want.
Property  Previous Default Value  New Default Value 

 1e6  0 
 1e6  Inf 
 1e6  0 
A new syntax for creating the TuningGoal.Poles
requirement
allows you to constrain only the poles of the sensitivity function
measured at a specified location. Use this syntax to narrow the scope
of the requirement to a particular feedback loop.
For example, suppose you have a cascadedloop control system
in which the inner and outer loops contain loopopening locations 'InnerLoop'
and 'OuterLoop'
,
respectively. The following command uses the new syntax to constrain
the poles of the inner loop sensitivity function:
Req = TuningGoal.Poles('InnerLoop'); Req.MinDamping = 0.5; Req.Openings = 'OuterLoop';
Req
imposes a minimum damping on the poles
of the inner loop sensitivity function measured with the outer loop
open. The dynamics of blocks that do not participate to the inner
loop are ignored.
For more information about using this constraint, see the TuningGoal.Poles
reference
page.
TuningGoal.Tracking
allows specification of peak errorA new syntax for creating the TuningGoal.Tracking
requirement
allows you to specify a maximum tracking error for a particular inputoutput
pair in terms of a response time, a relative DC error, and a peak
relative error across all frequencies. These parameters are converted
to the following expression for the maximum tracking error:
$$\text{MaxError}=\frac{\left(\text{PeakError}\right)s+{\omega}_{c}\left(\text{DCError}\right)}{s+{\omega}_{c}}.$$
For more information about how to specify tracking error requirements,
see the TuningGoal.Tracking
reference
page.
New properties in several closedloop Tuning Goals allow you to specify the relative amplitudes of multiple input and output signals in the loops constrained by the requirements. Use these properties to reduce crosscoupling in tuned systems when the choice of units results in a mix of small and large signals.
TuningGoal.Tracking
and TuningGoal.Overshoot
now
have an InputScaling
property. This information
is used to scale the offdiagonal terms in the transfer function from
reference to tracking error. This scaling ensures that crosscouplings
are measured relative to the amplitude of each reference signal.
TuningGoal.Gain
and TuningGoal.Variance
now
have InputScaling
and OutputScaling
properties.
The values you set for these properties are used to scale the closedloop
transfer function T(s) on which
you impose the tuning requirement. The requirement is evaluated for
the scaled transfer function D_{o}^{–1}T(s)D_{i}. D_{o} and D_{i} are
diagonal matrices formed from the OutputScaling
and InputScaling
property,
respectively.
For more information on how to interpret and use these properties, see the reference pages for the Tuning Goals.
The new Stabilize
property of loopshaping
and gainlimiting Tuning Goals allows you turn off the implicit closedloop
stability constraint. If stability for the specified loop is not
required or cannot be achieved, set Stabilize
to false
to
relax the stability constraint.
This property is available for the following Tuning Goals:
For more information on how to use the Stabilize
property,
see the reference pages for the Tuning Goals.
ScalingOrder
property added to TuningGoal.Margins
The TuningGoal.Margins
tuning
goal has a new property, ScalingOrder
. This property
controls the number of states in the diagonal scalings involved in
computing MIMO stability margins. Increasing the order may improve
results at the expense of increased computations.
Previously, this scaling order was set as a tuning option in systuneOptions
.
If you have scripts that use the ScalingOrder
option
of systuneOptions
, set the ScalingOrder
property
of TuningGoal.Margins
instead.
systune
or looptune
functions using slTuner
interface (with Simulink Control Design) Use the new slTuner
interface
for tuning control systems in Simulink models. This interface
replaces slTunable
. The slTuner
interface
allows you to:
Tune model blocks and subsystems to meet tuning goals
using the systune
and looptune
functions.
Perform robust tuning of a controller against a set
of plant models using systune
. You can configure
an slTuner
interface to vary model parameter
values and operating points. When you call systune
for
the interface, the software returns a control system that satisfies
the tuning goals for all the specified model variations.
Validate the controller design by examining the transfer
function for relevant I/O sets using the getIOTransfer
, getLoopTransfer
, getSensitivity
,
and getCompSensitivity
functions.
slTuner
, similar in design to slLinearizer
,
simplifies I/O management in the controller tuning and validation
workflow. You specify signals of interest as analysis points.
You can use these analysis points to configure design requirements
and specify linearization inputs/outputs when you extract transfer
functions.
For more information on commandline tuning of Simulink models
with slTuner
, see:
The slTunable
interface will continue to
work for backward compatibility. However, only the slTuner
interface
will be supported and enhanced in future releases. Therefore, adoption
of the slTuner
interface is strongly recommended.
For documentation of the slTunable
interface,
see slTunable
in
the R2013b documentation.
systune
and looptune
commandsYou can now use systune
and looptune
to
automatically tune control systems in which plant dynamics change
with operating conditions or time. In such gainscheduled control
systems, the controller gains vary as a function of one or more scheduling
variables. You parameterize the dependency of controller gains on
the scheduling variables. The software automatically tunes the coefficients
of that parameterization so that the control system meets the tuning
requirements you specify over the entire range of plant operating
conditions. The new gainsurf
command
helps you parameterize your controller gains as functions of scheduling
variables.
Several new examples illustrating the workflow for gainscheduled tuning, including:
For additional information about tuning gainscheduled controllers, see GainScheduled Controllers.
systune
and looptune
commandsYou can now use systune
and looptune
for
automatic tuning of discretetime control systems. This capability
includes both:
Control systems represented by discretetime generalized
LTI models (genss
models with Ts
property
not equal to zero).
Control systems represented by an slTunable
interface
to a Simulink mode. Set the Ts
property of
the slTunable
interface to the sampling time at
which you want to linearize the model.
To tune a discretetime control system, use the same procedure and command syntax and you use to tune a continuoustime control system. For examples of discretetime tuning, see:
looptune
and systune
New TuningGoal
requirement objects allow
you to specify a variety of tuning objectives for automated tuning
of fixedstructure control systems with systune
and looptune
.
New tuning requirements include:
TuningGoal.Sensitivity
—
Constraint on sensitivity to disturbance
TuningGoal.Overshoot
—
Constraint on overshoot in step response
TuningGoal.MinLoopGain
—
Minimum loop gain constraint
TuningGoal.MaxLoopGain
—
Maximum loop gain constraint
Additionally, TuningGoal.LoopShape
has
two new syntaxes. These syntaxes allow you to specify a target crossover
frequency or range of crossover frequencies for an openloop response
in your control system.
For more information about these TuningGoal
requirement
objects see the reference pages for each requirement object, and:
looptuneSetup
command for switching from looptune
to systune
to use additional systune
functionalityThe new looptuneSetup
command provides
a bridge between the tuning commands looptune
and systune
. looptuneSetup
takes
the argument list for looptune
and constructs
an equivalent argument list for systune
. The looptuneSetup
command
is valid for systems represented in either MATLAB or Simulink.
You can use this command to switch from looptune
to systune
to
take advantage of the additional flexibility and functionality of systune
.
For example, looptune
requires that you tune
all channels of a MIMO feedback loop to the same target bandwidth.
Converting to systune
allows you to specify different
crossover frequencies and loop shapes for each loop in your control
system. Also, looptune
treats all tuning requirements
as soft requirements, optimizing them but not requiring that any constraint
be exactly met. Converting to systune
allows you
to enforce some tuning requirements as hard constraints, while treating
others as soft requirements.
You can also use looptuneSetup
to probe
into the tuning requirements that looptune
implicitly
imposes. When you use looptune
, you specify a
target loop bandwidth and stability margins. looptune
expresses
these as hard and soft tuning constraints, specified as TuningGoal
objects.
You can use looptuneSetup
to examine these constraints.
After examining the constraints, you can then alter them and pass
them to systune
for further tuning.
For more information, see the following reference pages:
hinfnorm
command for computing H_{∞} normThe new hinfnorm
command computes the H_{∞} norm
of SISO or MIMO systems. For SISO systems, the H_{∞} norm
is defined as the largest value of the frequency response magnitude.
For MIMO systems, H_{∞} norm
is the largest singular value across frequencies.
For more information, see the hinfnorm
reference
page.
TuningGoal
requirements renamed The following properties of TuningGoal
requirement
objects are renamed to better reflect their purpose and uses:
Object  Previous Property Name  New Property Name 

TuningGoal.LoopShape  LoopTransfer  Location 
TuningGoal.Margins  LoopTransfer  Location 
TuningGoal.Tracking  ReferenceInput  Input 
TuningGoal.Tracking  TrackingOutput  Output 
If you have scripts or functions that use any of these properties, consider updating your code to use the new property names instead. Using the previous property names does not generate an error in this release, but the names might be removed in a future release.
mussv
A new 'p'
option to the mussv
command
allows you to specify a power iteration method for computing the lower
bound on structured singular values (μ values).
This method is recommended for cases of complex uncertainty. When
at least one of the uncertain blocks specified in the block diagonal
matrix structure is complex, mussv
now uses the
power iteration method by default.
For pure real uncertainty, mussv
uses a gainbased
lower bound algorithm by default.
For more information, see the mussv
reference
page.
Previously, mussv
used a gainbased lower
bound algorithm for both pure real and mixed uncertainty. Therefore,
you might now obtain different results for the lower bounds with mixed
uncertainty.
ncfmargin
The ncfmargin
command includes a new input
argument that lets you specify the sign of the feedback interconnection
assumed for the margin calculation. Use the syntax [marg,freq]
= ncfmargin(P,C,sign)
or [marg,freq] = ncfmargin(P,C,sign,tol)
to
specify a negative or positive feedback interconnection. For more
information, see the ncfmargin
reference
page.
Previously, the relative accuracy tol
was
the third input argument to ncfmargin
. If you
have scripts or functions that use the syntax [marg,freq]
= ncfmargin(P,C,tol)
, update them to use [marg,freq]
= ncfmargin(P,C,1,tol)
instead.
TuningGoal.Poles
objectYou can now specify the minimum damping ratio of closedloop
poles for automated tuning of fixedstructure control systems with systune
or looptune
.
To do so, create a TuningGoal.Poles
object and
set its MinDamping
property to the minimum damping
ratio you want to specify. Additionally, you can now use the Focus
property
to limit enforcement of the TuningGoal.Poles
requirements
to poles within a specified frequency range.
For more information about the TuningGoal.Poles
requirement,
see the TuningGoal.Poles
reference
page. For more information about using requirement objects to tune
control systems, see Using
Design Requirement Objects.
TuningGoal.Rejection
object for specifying disturbance rejection requirementYou can now specify a disturbance rejection requirement for
automated tuning of fixedstructure control systems with systune
or looptune
.
The new TuningGoal.Rejection
object allows you
to specify a frequencydependent attenuation factor for a disturbance
injected at a specified location in the control system.
For more information about the TuningGoal.Rejection
requirement,
see the TuningGoal.Rejection
reference
page. For an example, see PID
Tuning for Setpoint Tracking vs. Disturbance Rejection.
For more information about using requirement objects to tune control systems generally, see Using Design Requirement Objects.
looptune
returns detailed results from multiple random starts The info
output of looptune
now
includes detailed results from each optimization run. When you use
the RandomStart
option of looptuneOptions
to
perform multiple optimization runs, the field info.Runs
of
the info
output now contains a struct
array.
Each entry in the struct
array includes results
from the corresponding optimization run such as minimum constraint
values and tuned block values. You can optionally use this information
to analyze independent optimization results.
See the looptune
reference
page for more information.
The Extra
field of info
is
now renamed to Runs
. If you use info.Extra
in
a script, update your code to use info.Runs
instead.
systune
command for multiobjective tuning with soft and hard constraintsThe new systune
command
allows automated tuning of fixedstructure control systems to highlevel
tuning objectives.
To use systune
, you specify tuning objectives
such as reference tracking, disturbance rejection, or stability margins.
You can specify both soft requirements (objectives) and hard requirements
(constraints). systune
automatically tunes the
parameters of your control system to meet the requirements.
You can use systune
to tune control systems
modeled in either MATLAB or Simulink.
For more information, see:
New TuningGoal
requirement objects allow
you to specify a variety of tuning objectives for automated tuning
of fixedstructure control systems with systune
and looptune
.
New tuning requirements include:
TuningGoal.Margins
—
Tune to stability margin requirements by specifying minimum gain and
phase margins for any feedback loop in your control system.
TuningGoal.Poles
—
Constrain closedloop dynamics of your control system.
TuningGoal.StableController
—
Constrain dynamics or ensure stability of tunable elements.
TuningGoal.WeightedGain
—
Limit on frequencyweighted gain from specified inputs to specified
outputs in your control system.
TuningGoal.Variance
and TuningGoal.WeightedVariance
—
Tune to H_{2} performance requirements by minimizing
or constraining variance amplification. TuningGoal.Variance
specifies
the maximum output variance for a unitvariance input signal from
a specified input to a specified output in your control system. TuningGoal.WeightedVariance
imposes
a frequencyweighted variance amplification limit.
For more information about these TuningGoal
requirement
objects see the reference pages for each requirement object, and:
The new systune
command can simultaneously
tune the parameters of multiple models or control configurations.
This feature allows you, for example, to tune a single controller
against a range of plant models, to help ensure that the tuned control
system is robust against parameter variations. As another example,
you can tune for reliable control by simultaneously to multiple plant
configurations that represent different failure modes of a system.
In either case, systune
finds values for tunable
parameters that best satisfy the specified tuning objectives for all
models.
For more information, see Tune Controller Against Set of Plant Models.
You can now optionally impose lower and upper bounds on tunable
parameters when tuning fixedstructure control systems using systune
, looptune
,
or hinfstruct
. For example, you can constrain a
gain to always be positive, or impose a maximum value on a filter
time constant.
To impose bounds on tunable parameters, set the Maximum
and Minimum
properties
of the parameter in the corresponding Control Design Block. For example,
create a scalar gain block and constrain the gain to be positive:
gainblock = ltiblock.gain('gainblock',1,1);
gainblock.Gain.Minimum = 0;
Then, use gainblock
as a component in a tunable genss
model
of the control system. When you tune the control system, the tuning
command enforces the constraint.
Additionally, you can limit the range of frequencies in which
almost any TuningGoal
requirement is enforced for
fixedstructure control system tuning with systune
or looptune
.
The only exceptions are TuningGoal.Variance
and TuningGoal.WeightedVariance
.
For example, you can enforce a stability margin requirement in a frequency band extending for one decade on each side of the target gain crossover frequency.
To limit the range of frequencies in which a requirement is
enforced, use the Focus
property of the TuningGoal
requirement
object. For example, create a requirement that limits the gain from
an input du
to an output u
to
10. Limit enforcement of the requirement to the frequency range 10–1000
rad/s.
Req = TuningGoal.Gain('du','u',10); Req.Focus = [10 1000];
ltiblock.pid2
and loopswitch
objects for tuning twodegreeoffreedom PID controllers and marking loop
opening sites for openloop requirementsNew Control Design Blocks in Control System Toolbox allow you to specify more control structures and more types of constraints for fixedstructure control system tuning in MATLAB:
ltiblock.pid2
— Tunable
twodegreeoffreedom PID controller
loopswitch
— Control Design
Block for specifying feedback loop opening locations in a tunable genss
model
of a control system
For more information, see the ltiblock.pid2
and loopswitch
reference
pages.
TuningGoal.MaxGain
and GainLimit
property renamed The tuning requirement TuningGoal.MaxGain
is
now called TuningGoal.Gain
. Additionally, the GainLimit
property
of that tuning requirement is now called MaxGain
.
For more information, see the TuningGoal.Gain
reference
page.
Replace instances of TuningGoal.MaxGain
in
your code with TuningGoal.Gain
. Replace references
to the GainLimit
property with MaxGain
.
hinfstructOptions
and looptuneOptions
renamed or removed The following options in hinfstructOptions
and looptuneOptions
are
changed:
SpecRadius
is now called MaxFrequency
.
Additionally, NaN
is no longer a supported value
for this option. For an unconstrained MaxFrequency
value,
use Inf
.
StableOffset
is now called MinDecay
.
StableRadius
option has no effect.
StableExclude
option of hinfstructOptions
has
no effect. hinfstruct
now automatically excludes
from stability tests Control Design Blocks such as weighting functions
or multipliers. These blocks do not affect the closedloop stability
of the actual control system to tune.
For more information about these options, see the hinfstructOptions
and looptuneOptions
reference
pages.
If you use any of the affected options in your code, update your code to reflect the current names and supported values.
If you have Parallel Computing Toolbox™ software installed,
you can use parallel computing to speed up tuning of fixedstructure
control systems with the looptune
or hinfstruct
commands.
When you run multiple randomized looptune
or hinfstruct
optimization
starts, parallel computing speeds up tuning by distributing the optimization
runs among MATLAB workers.
For more information about using parallel computing to speed
up looptune
or hinfstruct
tuning,
see:
Speed Up Tuning with Parallel Computing Toolbox Software in the Robust Control Toolbox documentation.
The Robust Control Toolbox demo Using Parallel Computing to Accelerate the Tuning Process.
For more information about tuning fixedstructure control systems
with looptune
or hinfstruct
,
see Tuning
Fixed Control Architectures in the Robust Control Toolbox documentation.
H_{∞} norm calculations
now use the SLICOT library of numerical algorithms. These algorithms
improve the speed and accuracy of functions such as hinfstruct
and looptune
.
For more information about the SLICOT library, see http://slicot.org.
Use looptune
to
tune fixedstructure control systems to meet your requirements. To
use looptune
, specify design requirements such
as loop bandwidth, stability margin, setpoint tracking, or target
loop shape. looptune
automatically tunes the
parameters of your controller to meet the specified requirements.
The requirements objects TuningGoal.MaxGain
, TuningGoal.Tracking
,
and TuningGoal.LoopShape
let
you express your design requirements directly. You do not have to
first convert them to weighting functions or mathematical constraints
on an optimization problem.
You can use loopview
to
validate the performance the performance of the tuned control structure
against your specified design requirements.
For more information, see Tuning Fixed
Control Architectures and the looptune
and loopview
reference
pages.
If you have Simulink Control Design software, you can use
tuning commands, such as slTunable.looptune
and hinfstruct
,
to tune control systems modeled in Simulink. The slTunable
object
provides an interface between your Simulink model and these commands.
Use slTunable
to specify information about
your control structure and parametrization. slTunable
also
automates tasks such as linearizing the Simulink model, parametrizing
the tunable blocks of your system, and applying tuned parameter values
to the model. After you create and configure an slTunable
object
for your control architecture, you can tune the control system using slTunable.looptune
or hinfstruct
.
For more information, see Tuning Fixed Control Architectures and the following demos:
wcgainplot
plots the nominal, sampled,
and worstcase gains of uncertain systems as a function of frequency.
Use wcgainplot
for visual analysis of uncertain
systems.
For more information, see the wcgainplot
reference
page.
Functionality  What Happens When You Use This Functionality?  Use This Instead  Compatibility Considerations 

umat object
can no longer contain ultidyn or udyn uncertainty.  Expect a model type of uss or ufrd instead
of umat when working with udyn or ultidyn uncertain
elements.  Update code to work with uss or ufrd instead
of umat when udyn or ultidyn elements
are present.  
uss(sys_frd) , where sys_frd is
a frd model
object no longer converts sys_frd to ufrd .  Errors.  ufrd(sys_frd) .  Replace uss(sys_frd) with ufrd(sys_frd) . 
ufrd(udat,freq,...) no longer constructs
an uncertain frd model from the umat object udat .  Converts udat to a ufrd object
with frequencies freq .  Use frd(udat,freq,...) to construct an uncertain frd model
from the umat object udat .  Replace ufrd(udat,freq,...) with frd(udat,freq,...) . 
frd(sys_uss,w) where sys_uss is
a uss model.  Warns; returns frd model containing data
based on nominal response of sys_uss .  ufrd(sys_uss,w) to obtain a ufrd model.  Replace frd(sys_uss,w) with ufrd(sys_uss,w) . 
Nominal value of ultidyn object.  Nominal value is ss model
object.  None.  Update code to work with ss model objects
when working nominal value of ultidyn . 
usubs .  Applied to array of uncertain models, default substitution
is 'once' .  Use 'batch' to perform batch substitution
on uncertain model arrays.  Replace usubs(...) with usubs(...,'batch') . 
usubs(M,{a1;a2;...}, returns
error.  usubs(M,a1,v1,a2, .  Replace usubs(M,{a1;a2;...}, with usubs(M,a1,v1,a2, .  
usample(sys,'a',na, where
uncertain element b does not exist in sys .  Returns na bynb array
with constant values across nb dimension, instead
of na by1 array.  None.  Update code to reflect correct dimensionality. 
wcgopt .  Still runs.  wcgainOptions or wcmarginOptions .  Replace wcgopt with wcgainOptions or wcmarginOptions . 
robuststab and robustperf .  For ufrd models, BadUncertainValues field
of Info output returns Nf by1
struct array, where Nf is the number of frequency
points.  None.  Update code to work with Nf by1 struct
array for BadUncertainValues instead of Nf by1
cell array. 
For nominally unstable models, performance margin is zero (instead of a negative value).  None.  Update code to reflect correct performance margin .  
robopt .  Still runs.  robuststabOptions or robustperfOptions .  Replace robopt with robuststabOptions or robustperfOptions . 
actual2normalized .  First output argument is normalized uncertain block value. The second output argument is normalized distance between block value and nominal value.  [NV,ndist] = actual2normalized( .  Use second output argument ndist for normalized
distance. 
reshape(unc_sys,S) .  S does not include the I/O size of the models
in the array unc_sys . For example, if unc_sys is
a 6by1 array of 2output, 4input models, reshape(unc_sys,[2
3]) converts unc_sys to a 2by3 array.  None.  Remove I/O size dimensions from reshape on
uncertain model arrays. 
diag(uss_sys) where uss_sys is
a uss model.  Errors.  None.  Remove diag(uss_sys) . 
New Generalized
LTI models in Control System Toolbox allow you to model
control systems with tunable parameters. Using these models simplifies
controller tuning with hinfstruct
.
You can model a closedloop transfer function, including tunable parameters,
as a generalized statespace (genss
)
model and directly tune the parameters to minimize the closedloop
gain. The hinfstruct
command can tune any fixedstructure
SISO or MIMO control system using H_{∞} synthesis
techniques.
Additionally, new realp
and genmat
objects
let you create parametric expressions. You can use such expressions
to create custom tunable components. For example, you can define a
lowpass filter parametrized by its cutoff frequency, or an observerbased
controller parametrized by the statefeedback and observer gains.
For more information about creating tunable Generalized LTI models, see Models with Tunable Coefficients in the Control System Toolbox User's Guide.
For more information about H_{∞} tuning
with hinfstruct
, see Tuning Fixed
Control Architectures in the Robust Control Toolbox Getting
Started Guide.
For examples of designing controllers for several different
architectures using hinfstruct
, see the following
updated and new demos:
New commands in this release allow you to tune fixedstructure SISO and MIMO control systems using the techniques of H_{∞} synthesis.
The new hinfstruct
command
lets you use the frequencydomain methods of H_{∞} synthesis
to tune control systems with a broad range of architectures and controller
structures. For example, you can tune:
Fixedorder, fixedstructure controllers, such as pure gains, PID controllers, or fixedorder transfer function or statespace models
Single feedbackloop architectures with multiple tunable elements, such as a PID controller plus a filter
Multiple feedbackloop architectures with multiple tunable elements
Specify the tunable elements of your system using the new parametrized
Control Design blocks ltiblock.gain
, ltiblock.pid
, ltiblock.tf
,
and ltiblock.ss
.
For examples of designing controllers for several different
architectures using hinfstruct
, see the following
new demos:
For more information, see Tuning Fixed Control Architectures in the Robust Control Toolbox Getting Started Guide.
You can now improve robust performance by accounting for real
uncertain parameters when designing controllers using µsynthesis.
The userdefined options you use in the dksyn
command
now includes a new option MixedMU
. Set this option
to 'on'
to account for real uncertain parameters
in your system. For more information, see the dkitopt
,
and dksyn
reference
pages.
If you have Simulink Control Design software installed, you
can take model uncertainty into account when linearizing a Simulink model.
You can then use the resulting uncertain linearized model (uss
object)
to perform linear analysis and robust control design.
If your model already contains Uncertain State Space blocks,
use the new ulinearize
command to obtain an uss
model.
If you want to account for uncertainty in your linear analysis without
using Uncertain State Space blocks, you can specify individual Simulink blocks
to linearize to an uncertain variable. For more information, see "Computing
Uncertain StateSpace Models from Simulink Models" in the Robust
Control Toolbox User's Guide.
This version of the product provides a new interface to simulate the effects of uncertainty in Simulink models. The interface includes the following:
Uncertain State Space block to specify uncertain system
in Simulink. You should replace USS System blocks in your existing
models with the Uncertain State Space block. To do so, run the slupdate
command
on your models.
ufind
command
to extract all uncertain variables from a Simulink model.
usample
command
to generate random values of these uncertain variables.
For more information on simulating the effects of uncertainty using the new interface, see "Simulating Effects of Uncertainty" in the Robust Control Toolbox User's Guide.
This version of the product includes a new ucover
command
that lets you model a family of LTI responses as one uncertain system.
For more information, see the ucover
reference
page.
The following new and updated demos illustrate use of the new features:
"Control
of SpringMassDamper Using Mixed muSynthesis" shows use
of the new MixedMU
option and dksyn
command
for mixedmu synthesis.
"Linearization
of Simulink Models with Uncertainty" shows how to compute
uncertain statespace models using ulinearize
and Simulink Control Design software.
"Robustness Analysis in Simulink" uses the new interface for simulating effects of uncertainty in Simulink models.
"Simultaneous
Stabilization Using Robust Control" and "Modeling a Family of Responses
as an Uncertain System" show use of the ucover
command.
"FirstCut
Robust Design" shows use of the usample
, ucover
and dksyn
commands.
To access the demos, type
demo('toolbox','robust control')
Function, Property or Block Name  What Happens When You Use Function or Property?  Use This Instead  Compatibility Considerations 

 Still runs 
 See New Interface for Simulating Effects of Uncertainty in Simulink Models. 
 Still runs 
 See New Interface for Simulating Effects of Uncertainty in Simulink Models. 
 Still runs 
 See New Interface for Simulating Effects of Uncertainty in Simulink Models. 
USS System block  Still runs  Uncertain State Space  See New Interface for Simulating Effects of Uncertainty in Simulink Models. 
 Still runs  ucover  See New Command to Model Multiple LTI Responses as One Uncertain System. 
This version of Robust Control Toolbox software lets you analyze the robustness of nonlinear Simulink models using the LOOPMARGIN command.
If you have the Simulink Control Design product installed, you can perform stability margin analysis of a Simulink model by passing the model name and a point within that model to the LOOPMARGIN command.
This Robust Control Toolbox version introduces a new function, ltiarray2uss
.
This function constructs an uncertain statespace model from an LTI
array.
This Robust Control Toolbox version introduced two new functions:
actual2normalized
—
Calculate normalized distance between nominal value and given value
for uncertain atom.
normalized2actual
—
Convert value for atom in normalized coordinates to corresponding
actual value.
Release  Features or Changes with Compatibility Considerations 

R2016a  Functionality being removed or changed 
R2015b 

R2015a  None 
R2014b  
R2014a  
R2013b  
R2013a  looptune returns detailed results from multiple
random starts 
R2012b  
R2012a  None 
R2011b  Functionality Being Removed or Changed 
R2011a  None 
R2010b  None 
R2010a  None 
R2009b  Functions, Properties and Blocks Being Removed 
R2009a  None 
R2008b  None 
R2008a  None 
R2007b  None 
R2007a  None 
R2006b  None 
R2006a  None 
R14SP3  None 
R14SP2  None 
You clicked a link that corresponds to this MATLAB command:
Run the command by entering it in the MATLAB Command Window. Web browsers do not support MATLAB commands.
You can also select a location from the following list: