Explanation of inputSpan and outputSpan

[TomPcz]

Could you please make the documentation of inputSpan and outputSpan more detailed? From this line of code

sTune/src/sTune.cpp

Line 194 in b0f9832

_Ku = fabs(((pvMax - pvStart) / _inputSpan) / ((_outputStep - _outputStart) / _outputSpan));

it seems that they both have an effect on Ku and thus kp. My input is a temperature in °C and output current in A (for Peltier). Assuming that I never saturate the output, why would kp change based on the range?

[Dlloydev]

Sure, I'll see what I can do to improve the documentation.

I'll also add a link to this reference where in the Tuning Procedure section, the process gain gp would be _Ku.

Another reference could be pages 14-15 here.

[TomPcz]

Thank you for the reply. I am still not convinced that the output of sTune is compatible with your QuickPID library (or PID_v1).

Let’s assume that the input is a temperature in °C and the output is a current in A (for driving a Peltier, for example). In your QuickPID code, the error variable would be in °C, peTerm in A (neither of those is normalized to the range of the controller in the code). Thus, kp must be in A/°C (that is, if I use pMode::pOnError , set kp=1, ki=kd=0, input is 20 °C and setpoint 21 °C, the output would be +1 A). sTune, however, does not return kp in A/°C. Instead, it is expressed in (% of output span)/(% of input span).

Additionally, sTune seems to return different kp values depending on the input and output span (I have not tested this, but that is what the line of the code seems to do). In QuickPID, on the other hand, the output is independent of the spans. That is, if I use the output of sTune for QuickPID, the behaviour of the controller would be different based on what the range of my temperature probe is.

I think that you are mixing two different (incompatible) approaches to express the constants (look at this comment). In QuickPID, the physical values are used. sTune, however, outputs the normalized values.

[Dlloydev]

The role of the tuner is just to return the pid control parameters (gains kp, ki, kd) which themselves are unitless. The method on how these are determined (if done correctly) should have no effect on being compatible with any given PID controller. How the PID controller is configured and if it works with normalized or raw values should be independent on how any given gain was determined (manually entered, trial and error, reaction curve test, step test oscillations or relay method, etc.

Yes, sTune will return different kp values depending on the input and output span. Note that the user could enter the full range of the sensor's input but I believe specifying the usable range would give better tuning results. Note that sTune uses a reaction curve method (open loop) and uses different formulas and values when compared to those used for a closed loop step test method.

Some additional references:
Pages 214-216 here
Pages 14-18 here
Controller Gain Is Dimensionless in Commercial Systems
Demystifying PID Tuning Coefficients

Regarding your Peltier example and sTune, the temperature sensor may have a range of -20°C to 200°C. If your current driver operates from 0 to 5A, and 5A can only provide -70°C cooling, and the max temperature in use (temp limit) is 100°C
Then the usable inputSpan would be 70 with a usable outputSpan of 5. I think this would produce more accurate PID gains than using an inputSpan of 220.