4.4.15. PID Controller

Aria provides a classical parallel PID (Proportional-Integral-Derivative) for a number of source and BC commands, commonly used to recreate similar controllers used in experiment. The controller aims to maintain a desired output level by minimizing the difference between a measured process variable and a desired setpoint. This implementation involves three parallel components:

Proportional (P)

This part of the controller reacts to the current error, which is the difference between the setpoint and the process variable.
The proportional gain $K_p$ determines the magnitude of the response to the error. A higher $K_p$ results in a larger output response, which can reduce the rise time but may increase overshoot and system instability.

Integral (I)

This component addresses the accumulated error over time, effectively eliminating the steady-state error that can occur with a P-only controller.
The integral gain $K_i$ determines how aggressively the controller reacts to the accumulated error. By integrating the error over time, this component helps in achieving zero steady-state error, but too high a $K_i$ can lead to overshoot and oscillations.
Optional anti-windup is provided here to saturate the integrated error, minimizing overshoot when the error is large over a long period of time. This is enable by setting enable_clamping=true in the PID line command.

Derivative (D)

The derivative part predicts future errors by calculating the rate of change of the process error.
The derivative gain $K_d$ influences the controller’s response to the rate at which the error is changing. This component can improve system stability and reduce overshoot by “damping” the response, especially in systems with a fast-changing process variable.
The derivative action acts on a filtered value of the error, avoiding spikes in command caused by a noisy process variable (e.g. those coming from sensor data). The time constant of this filter is controlled by specifying Filter_Tau or Filter_Number (where $\tau_f = 1/N_f$ ) in the PID line command.

In the parallel PID implementation used here, the outputs of these three components are summed to generate the control action to the process

$u(t) = K_p e(t) + K_i \int_0^t e(\tau) d\tau + K_d \frac{\partial e_f(t)}{\partial t}$

For example to apply a PID controller heat flux on a surface to recreate a heater used in experiment, one would use the following

Begin Definition for Function target_temp
    Type is Piecewise Linear
    Column Titles Time Temperature
    Begin Values
      0 300
      1 305
      ...
    End
End
...

postprocess average of expression temperature on heater_surface as avg_heater_surf_temp
BC Flux for Energy on heater_surface = PID_Controlled \$
  P=1e-3 I=1e-5 D=0.0 \$
  Max_Output=1e6 \$
  Filter_Tau=60.0 \$
  Setpoint_Function_Name=target_temp \$
  Control_Variable=avg_heater_surf_temp

4.4.15.1. Note on Labview Controller

Unfortunately, a bug was uncovered in the implementation of the built in Labview PID controller that causes a deviation of the controller from classical PID theory when an integral and/or derivative term is included. To work around this bug, one must explicitly set a sampling dt in labview, use their built in conversion tool from Labview gains to parallel gains (also with the dt wired in), and still must then scale the gains by dt. Reference TF-3293 and/or Labview Request #: 02780637 for more context on this.

This workaround can be quite an unclear and burdensome process. Furthermore, it does not help for existing results generated with the broken controller. To help in this case, a helper script is provided to solve for the appropriate gains that best match the labview curves. The tool is available with the sierra module e.g.

module load sierra
labviewPID2aria --help

Note

This tool is provided as is. While we are not aware of any issues, we make no guarantees of correctness.

Consider the following CSV output from an experiment run in Labview controlling temperature to match set_point by changing heater_cmd over time

time, foo, temperature, heater_cmd, set_point, ...
0   , 1.0, 0          , 1         , 1        , ...
0.1 , 1.0, 0.1        , 1         , 1        , ...
...

To solve for the appropriate Aria gains, one needs only to feed in the initial guess generated by Labview and clarify the mapping of data e.g.

labviewPID2aria \
  --csv-data /path/to/data.csv \
  --time-key time \
  --response-key temperature \
  --cmd-key heater_cmd \
  --setpoint-key set_point \
  --const-P 20.0 \
  --solve-I 10.0 \
  --solve-D 1.0 \
  --clamping 100.0

Some notable optional capabilities include:

--const-*: Provide a constant value for a given gain, do not solve for it.
--solve-*: Provide an initial guess for a given gain, include it in the solve.
--figure-out: Optionally write a figure demonstrating the resulting match. Since a perfect match cannot always be found, it is suggested to use this and confirm that the match is acceptable.
--aprepro-out: Optionally write the results to an aprepro file to include in a run.
--clamping: Enable clamping with specified command bounds.

See labviewPID2aria --help for a complete set of options. To handle this same data stored in an Excel spreadsheet, one needs only to change the data specification type to e.g.

labviewPID2aria --xlsx-data /path/to/data.xlsx:my_sheet_name ...

Note

The xlsx-data switch expects a <path>:<sheet name> tuple as argument. If the :<sheet name> is omitted, the first sheet in the file is selected instead.