When a control system first becomes closed loop, the first problem is often not “it does not move.” It is “it keeps moving back and forth.”
Temperature overshoots and undershoots. Motor speed swings around the target. Liquid level control keeps opening and closing a valve. Pressure rises too high, then falls too low. Smaller parameters make the response too slow. Larger parameters make it oscillate.
It is easy to summarize this as: the PID is not tuned well.
But closed-loop oscillation is usually not caused by one parameter alone. It comes from the whole loop:
setpoint
-> controller
-> actuator
-> plant
-> sensor
-> sampling, filtering, communication, and scheduling
-> back to controller
If this loop contains delay, inertia, noise, saturation, or deadband, the controller may act at the wrong time or with the wrong magnitude.
The Loop Is What Gets Controlled
Open-loop control sends commands without checking the result. Closed-loop control keeps correcting commands based on output feedback.
That creates a benefit: feedback can correct disturbances, load changes, and model error.
It also creates a risk: every control action affects the next measurement through the plant. If the action is too strong, the feedback is late, or the measurement is noisy, the correction itself becomes a new disturbance.
A real loop contains at least:
- Plant: temperature, speed, position, liquid level, pressure, or another physical quantity
- Actuator: heater, motor, pump, valve, fan, servo, and so on
- Sensor: measuring output directly or indirectly, with delay and noise
- Controller: computing the next output from error
- Timing path: sampling period, filtering, communication, scheduling, and actuator response
If you only look at the control algorithm, many oscillations are hard to explain.
Late Feedback Becomes Over-Correction
Delay is one of the most common causes of oscillation.
The controller sees error and sends an action, but the plant does not change instantly. The sensor does not see the change instantly either. There may be thermal inertia, mechanical inertia, fluid lag, filter delay, communication delay, and task scheduling delay.
If feedback is late, the controller keeps pushing based on old information.
For temperature control:
temperature below target
-> heater power increases
-> heat takes time to reach the sensor
-> controller still sees low temperature
-> heater keeps pushing
-> temperature eventually overshoots
After overshoot, the reverse correction is late too. The system swings around the target.
The controller is not failing to work. It is acting on stale information.
High Gain Amplifies Error And Noise
Increasing proportional gain makes the controller react harder to error. That can improve response speed, but it also reduces stability margin.
If the plant has inertia or delay, high gain makes overshoot more likely.
If the sensor reading has noise, high gain turns measurement noise into actuator movement:
small measurement jitter
-> error jitter
-> control output jitter
-> actuator jitter
-> real physical disturbance
So “faster response” is not free. Higher gain makes the system more sensitive, and it can turn sensor noise, sampling jitter, and small disturbances into real motion.
Filtering Reduces Noise And Adds Phase Lag
When sensor noise is large, filtering is a common fix.
Filtering makes the measurement steadier, but it also makes feedback later. That delay matters in closed-loop control.
Low-pass filters, moving averages, and long confirmation windows all give the controller a smoother but older state. If the controller continues to act on that older state, oscillation risk increases.
That is why the same sensor data can be heavily filtered for display but must be handled carefully for control.
stronger filtering
-> steadier measurement
-> later feedback
-> higher risk of over-correction
Filtering is not wrong. It must be counted as part of loop timing.
Sampling Period Changes Control Behavior
Discrete control does not watch the system continuously. It samples, computes, and outputs at intervals.
If the sampling period is too long, the controller sees the system in coarse steps. The system may have changed before the next control action arrives. If the sampling period is unstable, the interval between control actions is also unstable.
Common symptoms include:
- Control output changes in visible steps
- Output swings around the target
- The same PID parameters behave differently under different task load
- Adding logging, communication, or another task makes the loop worse
- A low-power strategy changes sampling period and the loop starts oscillating
PID parameters and sampling period belong together. If sampling period changes but parameters and filters are not revisited, loop behavior can change completely.
Actuators Do Not Instantly Become The Command
The controller outputs a command. The actuator produces physical effect. Those are not the same thing.
Common actuator limits include:
- Maximum output
- Minimum action
- Deadband or static friction
- Response delay
- Limited output slew rate
- Protection logic, soft start, or output limiting
If the controller assumes the actuator has already followed the command, while the physical output has not caught up, feedback still shows error and the controller may keep increasing output.
When the actuator and plant finally respond, too much action has accumulated, creating overshoot and oscillation.
Motors, valves, pumps, heaters, and fans can all behave this way. Closed-loop debugging must check what the actuator actually does, not only the control output variable.
Saturation Distorts Controller State
Actuators have maximum output. The controller may calculate an output beyond that limit, while the real actuator stays at its maximum.
If the controller keeps accumulating error internally, especially with an integral term, integral windup appears.
error remains
-> integral keeps accumulating
-> command grows
-> actuator is already saturated
-> system passes the target
-> integral is still large
-> output keeps pushing into overshoot
This kind of oscillation is not solved only by reducing proportional gain. You must check output limits, anti-windup, output ramping, setpoint rate limits, and actuator capability.
Deadband Makes Small Errors Bounce
Some actuators do not move for small commands.
A valve may have mechanical play. A motor may have static friction. A pump may need minimum power to start. A servo may have deadband. When the controller sends a small correction, nothing happens. When the error grows large enough, the actuator suddenly moves and may go too far.
That creates small oscillation around the target.
If the sensor also has quantization noise, threshold logic, or filter delay, the behavior becomes more visible. It looks like PID tuning trouble, but the real issue is discontinuous small-signal actuator behavior.
Deadband issues often need deadband compensation, minimum output, hysteresis, segmented control, or mechanical changes, not just continuous PID parameter tuning.
Debug By Opening The Loop First
When a loop oscillates, do not start by randomly tuning PID.
A better order is:
- Verify the sensor in open loop: is the reading trustworthy, and how much noise and delay does it have?
- Verify the actuator in open loop: does the command match real action, and are there deadband, saturation, or delay?
- Confirm sampling period, filter window, communication, and scheduling stability.
- Close the loop with small gain and observe response speed, overshoot, and oscillation frequency.
- Check whether output saturates and whether integral keeps accumulating.
- Separate oscillation caused by high gain, late feedback, actuator limits, or measurement noise.
- Then decide whether to change proportional gain, integral action, filtering, sampling period, limiting, or actuator strategy.
Closed-loop oscillation is not a small error in a PID table. It means the timing, magnitude, and nonlinear behavior of the whole feedback loop are not working together.
Look at sensor, actuator, sampling, filtering, limits, and plant together. Then “it oscillates no matter how I tune it” becomes a problem you can locate.