automatically tune pid gains based on plant frequency responses estimated from closed-凯发k8网页登录

insert the block into your system such that this port accepts a control signal from a source. typically, this port accepts the signal from the pid controller in your system.

data types: single | double

connect this port to the plant output.

data types: single | double

to start and stop the autotuning process, provide a signal at the start/stop port. when the value of the signal changes from:

when the experiment is not running, the block passes signals unchanged from u to u δu. in this state, the block has no impact on plant or controller behavior.

typically, you can use a signal that changes from 0 to 1 to start the experiment, and from 1 to 0 to stop it. some points to consider when configuring the start/stop signal include:

you can configure any logic appropriate for your application to control the start and stop times of the experiment.

data types: single | double

supply a value for the target bandwidth (rad/sec) parameter. see that parameter for details.

dependencies

to enable this port, in the tuning tab, next to target bandwidth (rad/sec), select use external source.

data types: single | double

supply a value for the target phase margin (degrees) parameter. see that parameter for details.

dependencies

to enable this port, in the tuning tab, next to target phase margin (degrees), select use external source.

data types: single | double

supply a value for the sine amplitudes parameter. see that parameter for details.

dependencies

to enable this port, in the experiment tab, next to sine amplitudes, select use external source.

data types: single | double

insert the block into your system such that this port feeds the input signal to your plant.

dependencies

to enable this port, in output signal configuration, select control perturbation.

data types: single | double

the block generates a perturbation signal at this port. typically, you inject the perturbation from this port via a sum block, as shown in the following diagram.

dependencies

to enable this port, in output signal configuration, select perturbation only.

data types: single | double

when the experiment is running (start/stop positive), the block injects test signals into the plant and measures the plant response at y. it uses these signals to estimate the frequency response of the plant at several frequencies around the target bandwidth for tuning. % conv indicates how close to completion the estimation of the plant frequency response is. typically, this value quickly rises to about 90% after the experiment begins, and then gradually converges to a higher value. stop the experiment when it levels off near 100%.

data types: single | double

this 4-element bus signal contains the tuned pid gains p, i, d, and the filter coefficient n. these values correspond to the p, i, d, and n parameters in the expressions given in the form parameter. initially, the values are 0, 0, 0, and 100, respectively. the block updates the values when the experiment ends. this bus signal always has four elements, even if you are not tuning a pidf controller.

if you have a pid controller associated with the block, you can update that controller with these values after the experiment ends. to do so, in the block tab, click update pid block.

data types: single | double

this port outputs the estimated phase margin achieved by the tuned controller, in degrees. the block updates this value when the tuning experiment ends. the estimated phase margin is calculated from the angle of g(jω_c)c(jω_c), where g is the estimated plant, c is the tuned controller, and ω_c is the crossover frequency (bandwidth). the estimated phase margin might differ from the target phase margin specified by the target phase margin (degrees) parameter. it is an indicator of the robustness and stability achieved by the tuned system.

dependencies

to enable this port, in the tuning tab, select output estimated phase margin achieved by tuned controller.

this port outputs the frequency-response data estimated by the experiment. initially, the value at frd is [0, 0, 0, 0, 0]. during the experiment, the block injects signals at frequencies [1/10, 1/3, 1, 3, 10]ω_c, where ω_c is the target bandwidth. at each sample time during the experiment, the block updates frd with a vector containing the complex frequency response at each of these frequencies, respectively. you can use the progress of the response as an alternative to % conv to examine the convergence of the estimation. when the experiment stops, the block updates frd with the final estimated frequency response used for computing the pid gains.

dependencies

to enable this port, in the experiment tab, select plant frequency responses near bandwidth.

this port outputs a vector containing the plant input (u δu) and plant output (y) when the experiment begins. these values are the plant input and output at the nominal operating point at which the block performs the experiment.

dependencies

to enable this port, in the experiment tab, select plant nominal input and output.

specify the type of the pid controller in your system. the controller type indicates what actions are present in the controller. the following controller types are available for pid autotuning:

when you update a pid controller block or custom pid controller with tuned parameter values, make sure the controller type matches.

tunable: yes

programmatic use

specify the controller form. the controller form determines the interpretation of the pid coefficients p, i, d, and n.

when you update a pid controller block or custom pid controller with tuned parameter values, make sure the controller form matches.

tunable: yes

programmatic use

specify whether your pid controller is a discrete-time or continuous-time controller.

programmatic use

specify the sample time of your pid controller in seconds. this value also sets the sample time for the experiment performed by the block.

to perform pid tuning, the block measures frequency-response information up to a frequency of 10 times the target bandwidth. to ensure that this frequency is less than the nyquist frequency, the target bandwidth, ω_c, must satisfy ω_ct_s ≤ 0.3, where t_s ω_c is the controller sample time that you specify with the controller sample time (sec) parameter.

when you update a pid controller block or custom pid controller with tuned parameter values, make sure the controller sample time matches.

tips

if you want to run the deployed block with different sample times in your application, set this parameter to –1 and put the block in a . then, trigger the subsystem at the desired sample time. if you do not plan to change the sample time after deployment, specify a fixed and finite sample time.

dependencies

to enable this parameter, set time domain to discrete-time.

programmatic use

enable this parameter to run tuning at a sample rate that is different from the sample rate of the pid controller you are tuning and the frequency response estimation experiment performed by the block. the pid gain tuning algorithm is computationally intensive, and when you want to deploy the block to hardware and tune a controller with a fast sample time, some hardware might not complete the pid gain calculation in a single time step. to reduce the hardware throughput requirements, specify a tuning sample time slower than the controller sample time using the tuning sample time (sec) parameter.

dependencies

to enable this parameter, set time domain to discrete-time.

programmatic use

specify the sample time of the tuning algorithm in seconds.

if you intend to deploy the block on hardware with limited processing power and want to tune a controller with a fast sample time, specify a sample time such that the tuning algorithm runs at a slower rate than the pid controller you are tuning.

dependencies

to enable this parameter, set time domain to discrete-time and select tune at different sample time.

programmatic use

even when you tune a continuous-time controller, you must specify a sample time for the experiment performed by the block. in general, continuous-time controller tuning is not recommended for pid autotuning against a physical plant. if you want to tune in continuous time against a simulink model of the plant, use a fast experiment sample time, such as 0.02/ω_c.

dependencies

this parameter is enabled when the time domain is continuous-time.

programmatic use

specify the discrete integration formula for the integrator term in your controller. in discrete time, the pid controller transfer function assumed by the block is:

in parallel form, or in ideal form,

for a controller sample time t_s, the integrator method parameter determines the formula f_i as follows:

for more information about the relative advantages of each method, see the block reference page.

when you update a pid controller block or custom pid controller with tuned parameter values, make sure the integrator method matches.

tunable: yes

dependencies

this parameter is enabled when the time domain is discrete-time and the controller includes integral action.

programmatic use

specify the discrete integration formula for the derivative filter term in your controller. in discrete time, the pid controller transfer function assumed by the block is:

in parallel form, or in ideal form,

for a controller sample time t_s, the filter method parameter determines the formula f_d as follows:

for more information about the relative advantages of each method, see the block reference page.

when you update a pid controller block or custom pid controller with tuned parameter values, make sure the filter method matches.

tunable: yes

dependencies

this parameter is enabled when the time domain is discrete-time and the controller includes a derivative filter term.

programmatic use

the target bandwidth, specified in rad/sec, 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 τ seconds, a good guess for the target bandwidth is 2/τ rad/sec.

to perform pid tuning, the autotuner block measures frequency-response information up to a frequency of 10 times the target bandwidth. to ensure that this frequency is less than the nyquist frequency, the target bandwidth, ω_c, must satisfy ω_ct_s ≤ 0.3, where t_s is the controller sample time that you specify with the controller sample time (sec) parameter. because of this condition, the fastest rise time you can enforce for tuning is about 6.67t_s. if this rise time does not meet your design goals, consider reducing t_s.

for best results with closed-loop tuning, use a target bandwidth that is within about a factor of 10 of the bandwidth with the initial pid controller. to tune a controller for a larger change in bandwidth, tune incrementally using smaller changes.

to provide the target bandwidth via an input port, select use external source.

programmatic use

specify a target minimum phase margin for the tuned open-loop response at the crossover frequency. the target phase margin reflects desired 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.

to provide the target phase margin via an input port, select use external source.

tunable: yes

programmatic use

specify whether the perturbation at each frequency is applied sequentially (sinestream) or simultaneously (superposition).

sinestream mode can be more accurate and can also be less intrusive, because the total size of the perturbation is never bigger than the values specified by the sine amplitudes parameter. however, due to the sequential nature of the sinestream perturbation, each frequency point you add increases the recommended experiment time (see the start/stop input port for details). thus, the estimation experiment is typically much faster in superposition mode with satisfactory results.

sinestream signals reduce the execution time compared to superposition input signals, but also take longer to estimate the frequency response. frequency response estimation using sinestream signals is useful when you have limited processing power and you want to reduce the execution time.

programmatic use

specify whether the plant is stable or integrating. if the plant has one or more integrators, select integrating.

programmatic use

specify whether the plant is positive or negative. if a positive change in the plant input at the nominal operating point results in a positive change in the plant output, specify positive. otherwise, specify negative. for stable plants, the sign of the plant is the sign of the plant dc gain.

programmatic use

during the experiment, the block injects a sinusoidal signal into the plant at the frequencies [1/10, 1/3, 1, 3, 10]ω_c , where ω_c is the target bandwidth for tuning. use sine amplitudes to specify the amplitude of each of these injected signals. specify a:

in a typical plant with typical target bandwidth, the magnitudes of the plant responses at the experiment frequencies do not vary widely. in such cases, you can use a scalar value to apply the same magnitude perturbation at all frequencies. however, if you know that the response decays sharply over the frequency range, consider decreasing the amplitude of the lower-frequency inputs and increasing the amplitude of the higher-frequency inputs. it is numerically better for the estimation experiment when all the plant responses have comparable magnitudes.

the perturbation amplitudes must be:

when experiment mode is superposition, the sinusoidal signals are superimposed. thus, the perturbation can be at least as large as the sum of all amplitudes. make sure that the largest possible perturbation is within the range of your plant actuator. saturating the actuator can introduce errors into the estimated frequency response.

to provide the sine amplitudes via an input port, select use external source.

tunable: yes

programmatic use

the block contains two modules, one that performs the real-time frequency-response estimation, and one that uses the resulting estimated response to tune the pid gains. when you run a simulink model containing the block in the external simulation mode, by default both modules are deployed. you can save memory on the target hardware by deploying the estimation module only (see ). in this case, the tuning algorithm runs on the simulink host computer instead of the target hardware. when this option is selected, the deployed algorithm uses about a third as much memory as when the option is cleared.

the pid gain calculation demands more computational load than the frequency-response estimation. for fast controller sample times, some hardware might not finish the gain calculation within one execution cycle. therefore, when using hardware with limited computing power, selecting this option lets you tune a pid controller with a fast sample time.

additionally, when you enable this option, there can be a delay of several sampling periods between when the tuning experiment ends and when the new pid gains arrive at the pid gains output port. before pushing gains to the controller, first confirm the change at the pid gains output port instead of using start/stop signal as the trigger for the update.

if you intend to deploy the block and perform pid tuning without using external simulation mode, do not select this option.

programmatic use

select this parameter if you are using simulink plc coder to generate code for the autotuner block. clear the parameter for code generation with any other mathworks^® code-generation product.

selecting this parameter affects internal block configuration only, for compatibility with simulink plc coder. the parameter has no operative effect on generated code.

by default, the block takes a control signal as input and provides the control signal plus the experiment perturbation at the port u δu. you then feed this signal into the plant input, as shown in the following diagram.

this default configuration requires inserting the block between the controller and the plant. if you want to add the perturbation signal to the control signal yourself, select perturbation only. in this configuration, the block output contains the perturbation signal only, at the port δu. you inject this perturbation signal into the plant using, for example, a sum block, as in the following diagram.

in this configuration, you can optionally comment out the closed-loop pid autotuner block without disrupting the model.

specify the floating-point precision based on simulation environment or hardware requirements.

programmatic use

under some conditions, the autotuner block can write tuned gains to a standard or custom pid controller block. to indicate that the target pid controller is the block connected to the u port of the autotuner block, select this option. to specify a pid controller that is not connected to u, clear this option.

to write tuned gains from the autotuner block to a pid controller anywhere in the model, the target block must be either:

under some conditions, the autotuner block can write tuned gains to a standard or custom pid controller block. use this parameter to specify the path of the target pid controller.

to write tuned gains from the autotuner block to a pid controller anywhere in the model, the target block must be either:

dependencies

this parameter is enabled when clicking "update pid block" writes tuned gains to the pid block connected to "u" port is selected.

the block does not automatically push the tuned gains to the target pid block. if your pid controller block meets the criteria described in the specify pid block path parameter description, after tuning, click this button to transfer the tuned gains to the block.

you can update the pid block while the simulation is running, including when running in external mode. doing so is useful for immediately validating tuned pid gains. at any time during simulation, you can change parameters, start the experiment again, and push the new tuned gains to the pid block. you can then continue to run the model and observe the behavior of your plant.

when you click this button, the block creates a structure in the matlab^® workspace containing the experiment and tuning results. this structure, onlinepidtuningresult, contains the following fields:

you can export to the matlab workspace while the simulation is running, including when running in external mode.