PID Simulator

A PID controller looks at the error, which is the setpoint minus the process value, and builds its output from three parts. The proportional part (Kp) gives a push in proportion to the error right now: a big error gets a big push. The integral part (Ki) adds up the error over time, so a small error that lasts still produces a growing push until it is gone. The derivative part (Kd) reacts to how fast the error is changing, which can calm a loop that is about to overshoot.

In plain terms: P reacts to the present, I corrects the past and D anticipates the future. Tuning is the job of choosing how strongly each one acts so that the loop reaches the setpoint quickly, without overshooting wildly, and without cycling.

This is the same order most technicians use on a real loop, written for the simulator. Change one gain at a time and rerun, so you can tell which change did what.

1. Set Ki and Kd to zero and start with a modest Kp.
2. Raise Kp until the loop responds promptly. Stop before the response starts to overshoot and swing.
3. Notice the offset. With proportional action alone the loop settles short of the setpoint.
4. Add Ki slowly until the offset disappears in an acceptable time. If you hear yourself wanting more, check for overshoot first.
5. Add Kd only if there is overshoot or ringing that the other two cannot fix, and keep it small.
6. Test the result with a disturbance, not only a setpoint change. The simulator's second challenge adds a load disturbance halfway through the run.
7. Write down the gains and the results. A tuning without a record cannot be compared or repeated.

The lab process is a temperature loop with an 8 second time constant and a 2 second transport delay, held at a 60 degree setpoint. The six runs below use the same process and only change the gains. Every figure comes from running the same model the lab uses.

First, proportional action alone. For this process the loop settles where the output just balances the error. With Kp 1.8 that is 38.6 degrees, an offset of 21.4. You can predict it: the final value is the setpoint times Kp divided by one plus Kp, which is 60 x 1.8 / 2.8 = 38.6. Raising Kp to 5 shrinks the offset to 10.0 degrees, but it never reaches zero, and a higher gain brings other problems.

Adding Ki 0.25 removes the offset. The loop settles in 23.2 s with no overshoot. Pushing the integral to 1.2 does the opposite of what you might hope: the loop overshoots by 17.8 percent and is still 6.7 degrees away from the setpoint at the end of the minute, because the integral keeps pushing after the process value has passed the setpoint.

Read the table by symptom. The two P-only runs have a large final error, which is the signature of missing integral action. The heavy-integral run has overshoot and an unfinished swing, the signature of too much integral. The aggressive run has high gain with a process delay and cannot settle, the signature of a loop that is too aggressive for its dead time.

The lab's first challenge accepts several tunings, so the exact gains matter less than being able to explain why a run behaved as it did. The graded run is scored on stability, overshoot, final error, integrated absolute error and settling time.

A trend usually tells you which gain to change. Use this table as a starting point, then change one gain at a time.

You will meet several formal methods. Ziegler-Nichols in its closed-loop form has you raise Kp with Ki and Kd off until the loop cycles steadily, note that ultimate gain Ku and the cycle period Pu, and then compute gains from them. For example, its classic PID rule uses Kp = 0.6 x Ku, an integral time of Pu / 2 and a derivative time of Pu / 8. It is quick to state but tends to give a lively response with noticeable overshoot, and pushing a real process into sustained oscillation is not acceptable on many plants.

Other methods work from a recorded step response instead, so the loop never has to cycle. Cohen-Coon and the internal model control or lambda approaches fit a simple model to the process and derive gains from it. Many controllers also offer an autotune that runs a controlled test and proposes gains. All of them give a starting point that you then check against the real process with the same symptoms table.

Real tuning needs more than gains. It needs the process identified, output limits and alarm limits agreed, a safe operating condition, a way back if the new tuning is worse, and often a controller whose structure (series or parallel form, derivative on error or on measurement, units of integral time) you have read from its manual. Gains from this simulator must not be copied to a real plant. The lab is for learning the trade-offs and a repeatable method in a place where a mistake costs nothing.