Why feedback — not the presence of a controller — is the thing that separates a system that corrects itself from one that just runs a script.
Ask an engineer what makes a control system "closed-loop" and a common wrong answer is: it has a controller, and the controller has a setpoint. Plenty of open-loop systems have both. A sprinkler timer has a setpoint — 20 minutes — and a controller that runs on that schedule. What it doesn't have is any idea whether the soil actually got wet enough. That single missing piece, a measurement of the real output fed back for comparison, is the entire difference between open-loop and closed-loop control.
The defining move in closed-loop control is the summing junction: setpoint minus measured value equals error, e = setpoint − measured. The controller never asks "how much time has passed" — it asks "how far off am I right now," and drives that number toward zero. Because the error is recomputed from a live sensor reading every scan cycle, the loop automatically compensates for anything that changes the process — a cold draft, a door left open, a valve that's slowly clogging — none of which the person who designed the system had to predict in advance. Open-loop control can only ever be as good as the assumptions baked in at design time. Closed-loop control keeps correcting itself against reality, for as long as the feedback path stays intact.
No — a controller and a setpoint are present in both diagrams above. The irrigation timer has a controller (the timer logic board) and a setpoint (20 minutes), and it is still purely open-loop, because nothing in that system ever measures the thing it's trying to control. "Closed-loop" is not a statement about how sophisticated the controller's internal logic is — a controller can run an elaborate multi-stage program and still be open-loop if it never checks its own result. Closed-loop specifically requires a measurement of the actual process variable, fed back and compared against the setpoint. Without that feedback path — a sensor, a transmitter, something reporting what really happened — the loop is not closed, no matter how many rules, timers, or setpoints the controller has.
Explains the real distinguishing feature between open-loop and closed-loop control — not the presence of a controller or setpoint, but whether the actual process output is measured and fed back for comparison — using a side-by-side comparison of a timer-based irrigation valve (open-loop) and a thermostat (closed-loop).
Engineers new to controls often equate "has a controller" or "has a setpoint" with "closed-loop." Both terms describe automation, but automation alone says nothing about feedback. A PLC running a fixed sequence with timers and preset values is automating a process, yet if nothing in that sequence reads back the actual state of the process it is controlling, it is open-loop — however many rungs of ladder logic are involved. The determining question is always the same: is there a sensor measuring the controlled variable, and does that measurement change what the controller does next?
Open-loop control computes its output purely from the setpoint and a fixed model or schedule: output = f(setpoint, time). It has no error signal because it never compares against a measured result — disturbances (a hotter day, a partially clogged emitter, a heavier load) go entirely uncorrected.
Closed-loop control introduces a summing junction that continuously computes error, e = setpoint − measured value, from a live feedback signal. The controller (P, PI, or PID logic, or simple on/off relay logic in a thermostat) acts on that error, not on elapsed time or a static assumption. Because the measurement updates every scan or sample, the loop keeps re-correcting itself against whatever is actually happening in the process — including disturbances the original designer never modeled.
Almost every PID loop, level control valve, VFD speed loop, and pressure control loop in a SCADA/DCS system is closed-loop by design — the entire point of instrumenting a process with 4–20 mA transmitters and analog inputs is to close that loop. Purely open-loop logic still shows up deliberately, though: timed backwash cycles, fixed-duration purge sequences, and batch step timers are often intentionally open-loop because measuring the variable would be impractical, unnecessary, or the process itself is well enough characterized that time alone is an adequate proxy. Recognizing which category a given control strategy falls into is essential for correctly diagnosing "the process drifted and nothing corrected it" failures — the fix is almost always adding real feedback, not tuning a controller that was never closing a loop in the first place.
Not in the strict control-theory sense for a single control variable — a given loop either measures its controlled variable and feeds it back, or it doesn't. But a larger system can mix strategies: a batch process might run open-loop timed steps for some stages (like a fixed-duration rinse) while running fully closed-loop PID control on temperature or pressure within that same batch.
No. Open-loop control is simpler, cheaper, and perfectly adequate when the process is well characterized and disturbances are minor or irrelevant — a fixed-duration conveyor indexing step, for example. Closed-loop control adds cost (a sensor, wiring, calibration, tuning) and is only worth that cost when disturbance rejection or accuracy actually matters to the outcome.
No. A PID block is just a computation. It only forms a closed loop if its process variable (PV) input actually comes from a live sensor measuring the real process, and its output actually drives an actuator affecting that same process. A misconfigured PID block reading a fixed or stale value, or one whose output doesn't reach the real actuator, is not functioning as a closed loop even though the algorithm is technically "PID."
The loop effectively degrades toward open-loop or worse — the controller keeps acting on a stale, frozen, or fault-value reading instead of reality, and can drive the actuator to a dangerous extreme trying to correct an error that no longer reflects the actual process. This is why SCADA/DCS systems implement sensor fault detection (rate-of-change alarms, out-of-range checks, redundant transmitters) and fail-safe fallback modes for exactly this failure case.
Not usually — in modern SCADA/PLC/DCS systems the "summing junction" is just a subtraction operation inside the controller's software (error = setpoint − PV), computed every scan cycle. In older pneumatic or analog electronic controllers it could be an actual physical comparator circuit, but the concept — computing error from setpoint and measured value — is identical either way.
Try our SCADA Studio
More calculators, simulators, and guides for this discipline.