PID_Compact tunes itself well enough to create the illusion that loops need no thought. The loops that refuse the illusion are the ones we get called for.
Foundations before tuning
- Home the block in a cyclic OB and let its sample time match that OB — PID in OB1 inherits OB1’s jitter and the derivative term amplifies exactly that.
- Scale honestly: input in engineering units, output limits matching what the actuator truly does (a valve that meaningfully controls between 20–80 % wants those as limits, not 0–100).
- Respect actuator physics: thermal loops with minutes of lag get conservative gains and sample times to match; a flow loop through a fast valve is a different animal at 100 ms.
Then the built-in sequence: pretuning (needs a stable start and room to move), followed by fine tuning near operating point. Accept its result as the starting production parameter set, and archive it.
The refusal patterns
Oscillation with period ≈ 4× dead time: classic excess gain against transport delay — retune with the process at real load, not empty. Output sawing between limits: integrator windup against an undersized/saturating actuator — fix the sizing or enable the anti-windup behavior properly. Perfect in the morning, unstable at night: the process gain changed (product, temperature) — schedule gain sets per recipe rather than blaming ghosts. Never settles, wanders: measurement noise into the D term — filter the input or run PI.
FAQ
PID_Compact or PID_Temp for heaters? PID_Temp when heating/cooling asymmetry is real (two actuators, different dynamics) — it exists precisely for that.
Manual tuning still worth knowing? Yes: when autotune’s experiment is not permitted on the process, classic methods on a trace get you there — and understanding beats parameters.
Zone Otomasyon tunes loops with traces and writes the numbers into the machine dossier. Loops behaving since 2009.