To use the PID autotuning algorithm in a standalone application for real-time tuning against your physical plant, you must deploy the PID autotuner block into your own system. To do so, you create a Simulink® model for deployment. You can configure this model with the experiment and tuning parameters. Or, you can configure it to supply such parameters externally from elsewhere in your system. Once deployed to your own system, the autotuner model injects signals into your plant and receives the plant response, without using Simulink to control the tuning process. Deploying the PID autotuning algorithm requires a code-generation product such as Simulink Coder™.
As an alternative, you can tune in real time against your physical plant while using Simulink to control the experiment. For more information, see Control Real-Time PID Autotuning in Simulink.
In overview, the workflow for deploying a PID autotuning algorithm for real-time tuning is:
Create a Simulink model for deploying a PID autotuner block into your system.
Configure the start/stop signal that controls when the tuning experiment begins and ends. After deployment, you can use this signal to initiate the PID autotuning process at any time.
Specify controller parameters such as controller type and the target bandwidth for tuning.
Configure experiment parameters such as the amplitudes of the perturbations injected during the frequency-response experiment.
Deploy the model to your system, and initiate the autotuning process against your physical plant. You can validate closed-loop performance in real time.
In practice, for real-time tuning, you might want to specify some parameters at run time, such as the target bandwidth or perturbation amplitudes. For information about specifying parameters in your deployed application, see Access Autotuning Parameters After Deployment.
Using a PID autotuner block for real-time tuning requires creating a Simulink model for deployment. There are several ways to do so.
In the most basic form, a model for deploying real-time PID autotuning resembles the following illustration, using either the Closed-Loop PID Autotuner or the Open-Loop PID Autotuner block. An advantage of this approach is that it lets you switch between and tune different PID controllers at run time.
Here, the blocks connected to the inputs and outputs of the PID autotuner
block represent hardware interfaces that read or write real-time data for your
system. For example, the
Read PID controller output block can
be an interface for receiving serial data, a UDP Receive block
for receiving UDP packets, or an interface for receiving other signals via
wireless network. Similarly the blocks for writing data, such as
plant input, can be interfaces for serial, UDP, or other
interfaces for writing data to hardware.
The default ports of the autotuner block are:
u — Receives the control signal.
y — Receives the plant output.
start/stop — Receives the signal that begins and
ends the tuning process.
u+Δu — Outputs the signal to feed to the plant
input. When the experiment is not running,
outputs the control signal as input at
u. When the
experiment is running the block and injects the test signals at
u+Δu. For open-loop tuning only, the block breaks
the loop between
the duration of the experiment. When the experiment ends, the block
restores the connection between
% conv — Outputs a numeric indicator of the
progress of the frequency-response estimation experiment.
pid gains — Outputs the tuned PID gains when the
tuning process stops.
In this configuration, the PID controller itself exists in another module of
your system. When tuning is complete, you use your own logic to write the tuned
PID gains from the
pid gains port of the autotuning block to
your PID controller.
Alternatively, you can deploy a module that includes both the PID controller and the PID autotuning algorithm, such as shown in the following illustration. An advantage of this approach is that it facilitates retuning a specific controller in an individual system.
In this illustration, the PID controller is implemented as a Simulink PID Controller block. Because the PID gains of that block are tunable, you can configure your system to write the tuned gains to the deployed controller. Alternatively, you can also use your own custom PID controller subsystem in the model that you deploy.
You can implement any logic appropriate to your application to determine
whether and how to update the PID controller with the tuned gains. In the
illustrated system, the
PID update logic subsystem represents
such a module. The
External data block represents whatever
other information your logic requires to determine whether to update the
When you are using the Closed-Loop PID Autotuner block,
pid gains outputs directly into the PID
Controller gain inputs can introduce an algebraic loop that prevents code
generation. To avoid this problem, you can introduce a state in your PID
update logic that breaks the algebraic loop. For example, you can try one of
the following approaches:
Unit Delay block to keep the controller
output one time step ahead of the controller inputs.
Use a Data Store Memory block, as illustrated in Tune PID Controller in Real Time Using Closed-Loop PID Autotuner Block.
When you use the Open-Loop PID Autotuner, if your controller includes integrator action, consider implementing signal tracking to avoid integrator windup during the tuning experiment. Signal tracking enables the PID controller to continue to track the real plant input while it is out of the loop. Without it, your system can experience a bump when the control loop is closed at the end of the tuning process.
If your PID controller is a Simulink PID Controller block, you can use the Enable tracking mode parameter of the controller block to avoid this bump. The following diagram illustrates a module containing an Open-Loop PID Autotuner block and a PID Controller block with tracking mode configured. The plant input feeds into the tracking input of the controller block.
To start and stop the autotuning process, use a signal at the
start/stop port. When the experiment is not running, the
block passes signals unchanged from
In this state, the block has no impact on plant or controller behavior.
The frequency-response estimation experiment begins and ends with a rising or
falling signal at the
start/stop port, respectively. Thus, after
deployment, to begin the autotuning process, use a rising signal at the
start/stop port. After an appropriate time, or after the
% conv signal settles near 100, use a falling signal to end
the experiment. When the experiment ends, the algorithm generates the tuned PID
gains and returns them at the
pid gains port. A conservative
estimate for the experiment time is 200/ωc
for closed-loop tuning or 100/ωc for
open-loop tuning, where ωc is your target
bandwidth. For more detailed information about how to configure the start-stop
signal, see the Closed-Loop
PID Autotuner or Open-Loop PID
Autotuner block reference pages.
To specify the configuration of the PID controller in your system, use the following parameters of the autotuner block:
Controller sample time (sec)
Then, specify the target bandwidth and phase margin for tuning with the Target bandwidth (rad/sec) and Target phase margin (degrees) parameters, respectively.
The target bandwidth is the target value for the 0-dB gain crossover frequency of the tuned open-loop response CP, where P is the plant response, and C is the controller response. This crossover frequency roughly sets the control bandwidth. For a rise-time τ, a good guess for the target bandwidth is 2/τ.
The target phase margin sets the robustness of the tuned system. Typically, choose a value in the range of about 45°– 60°. In general, higher phase margin improves overshoot, but can limit response speed. The default value, 60°, tends to balance performance and robustness, yielding about 5-10% overshoot, depending on the characteristics of your plant.
You can set most tuning parameters in your own application after deployment, instead of fixing them in the PID autotuner block before deployment. See Access Autotuning Parameters After Deployment.
The frequency-response estimation experiment injects sinusoidal signals at frequencies around the target bandwidth ωc:
[1/3, 1, 3, 10]ωc for the Open-Loop PID Autotuner block
[1/10,1/3, 1, 3, 10]ωc for the Closed-Loop PID Autotuner block
Use the Sine Amplitudes parameter of the blocks to specify the amplitudes of these signals.
If your plant is asymptotically stable, the Open-Loop PID Autotuner block can estimate the plant DC gain with a step perturbation. Specify the amplitude of this perturbation with the Step Amplitude parameter. If your plant has a single integrator, clear the Estimate DC gain with step signal parameter.
Do not use either closed-loop or open-loop PID autotuning with an unstable plant.
Do not use open-loop PID autotuning with a plant that has more than one integrator. You can use closed-loop PID autotuning with a multiple-integrator plant.
All the perturbation amplitudes must be:
Large enough that the perturbation overcomes any deadband in the plant actuator and generates a response above the noise level.
Small enough to keep the plant running within the approximately linear region near the nominal operating point, and to avoid saturating the plant input or output.
After you deploy the autotuner module to your system, use a rising
start/stop signal to begin the autotuning process. The
deployed module injects the test signals into your physical plant in real time.
After an appropriate time, or when the
% conv signal stabilizes
near 100%, use a falling
start/stop signal to end the experiment.
A conservative estimate for the experiment time is
200/ωc for closed-loop tuning or
100/ωc for open-loop tuning, where
ωcc is your target bandwidth. When
the experiment stops, the module computes new PID gains based on the estimated
frequency response at the system and your specified tuning goals. You can examine
the tuned PID gains using the
pid gains signal.
When you examine these gains and transfer them to your own controller, be aware of the meaning of these gains in the PID autotuner blocks. In discrete time, the blocks assume the following PID controller transfer function:
in parallel form, or in ideal form,
Fi(z) and Fd(z) depend on the values you specify for the Integrator method and Filter method formulas, respectively. For more details, see the Closed-Loop PID Autotuner or Open-Loop PID Autotuner block reference pages.
After you transfer the tuned gains to your PID controller, you can observe and validate the continued performance of your system with the new gains.
Some of the parameters that you set to configure the autotuner are tunable, such that you can access them in the generated code. For the parameters that are not tunable, you must configure them in the block before deployment.
The following parameters of the PID autotuner blocks are tunable after deployment. For more information about all these parameters, see the Closed-Loop PID Autotuner or Open-Loop PID Autotuner block reference pages.
|Target bandwidth (rad/sec)||Target crossover frequency of open-loop response|
|Target phase margin (degrees)||Target minimum phase margin of open-loop response|
|Sine Amplitudes||Amplitude of sinusoidal perturbations|
|Estimate DC gain with step signal||Inject step signal into plant|
|Step Amplitude||Amplitude of step perturbation|
|Type||PID controller type (such as PI, PD, or PID)|
|Form||PID controller form|
|Integrator method||Discrete integration formula for integrator term|
|Filter method||Discrete integration formula for derivative filter term|
The following parameters of the PID autotuner blocks are not tunable after deployment. You must specify them in the block before code generation, and their values remain fixed in your application. For more information about all these parameters, see the Closed-Loop PID Autotuner or Open-Loop PID Autotuner block reference pages.
|Time Domain||PID controller time domain|
|Controller sample time (sec)||Sample time of PID controller (see Modify Sample Times After Deployment)|
|Reduce memory and avoid task overrun (external mode only)||Deploy tuning algorithm only|
|Data Type||Floating-point precision|
The Controller sample time (sec) parameter is not tunable. As a consequence, you cannot access it directly in generated code when you deploy the block. To change the controller sample time in the deployed block at run time:
Set Controller sample time (sec) to –1.
Put the autotuner block in a Triggered Subsystem.
Trigger the subsystem at the desired sample time.