Operator setpoints and limits

The Core Idea

A setpoint is the target an operator asks the process to reach. A limit is a boundary that someone else — usually the engineer who knows the equipment — has decided that target may not cross. The program keeps the operator's requested setpoint separate from the active setpoint it actually uses, clamps the active value to the configured limits on every scan, and tells the operator when their entry was not used as typed.

Setpoints and limits are two halves of one design: the operator owns the target, the engineer owns the range, and the program enforces the range no matter where the request came from.

What you will learn

• Give an operator setpoint engineering units and keep the requested and active values separate.

• Clamp the active setpoint to a low and high limit, and treat those limits as configurable data rather than typed-in numbers.

• Signal the operator when a request was limited instead of clamping silently.

• Tell setpoint limits apart from instrument range, alarm limits, safety trips, output limits, and rate limits — and know who owns each one.

• See how a bounded setpoint becomes the SP input of a proportional-integral-derivative (PID) loop later in the course.

Why it matters

An editable human-machine interface (HMI) number becomes part of the control decision. If any value an operator can type goes straight into the logic, one slip — 800 instead of 80 — can command the process somewhere it was never designed to go. Limits turn "whatever was typed" into "a target inside the range this equipment is meant to run in", and they keep doing so when the request arrives from a recipe, a supervisory control and data acquisition (SCADA) write, or a second HMI that has no entry checks of its own.

Setpoints and limits: two halves of one job

Because the limits are tags rather than numbers typed into the rungs, an engineer can tighten or widen the range without editing logic, and the program and the HMI can both show the same values.

Not every limit is a setpoint limit

A real heater has several boundaries on the same temperature scale. They do different jobs, are owned by different people, and do different things when reached:

Read the table from top to bottom and the ranges nest: the setpoint range sits well inside what the instrument can read, below the alarm, which is below the trip. If a setpoint limit were above the alarm, a perfectly normal request would put the process into alarm. If the alarm were above the trip, the operator would get no warning before the shutdown.

Setpoint limits are not a safety function. They stop a valid-looking control request from being out of range; they do not protect against a failed sensor, a stuck relay, or a program error. That job belongs to independent protection.

The problem

An operator chooses a temperature target for a small heater. REQUESTED_SP_C is the operator's request in °C. SP_LO_LIM and SP_HI_LIM are the engineer's configured limits, starting at 20 °C and 80 °C. ACTIVE_SP_C is the setpoint the program uses after applying those limits. SP_LIMITED is TRUE whenever the active setpoint differs from the request. PV_C is the measured temperature. HEAT_REQUEST is TRUE while the measured temperature is below the active setpoint. The comparison is a simple illustration of using a setpoint; this example does not simulate a changing temperature.

The HMI has three rows:

• Operator row: the editable Operator setpoint, the read-only Active setpoint, and the Setpoint limited indicator.

• Process row: the read-only Measured temperature and the Heat request indicator. The sensor value is shown so the operator can read it, not change it.

• Engineering row: Engineer: SP low limit and Engineer: SP high limit. A real HMI would put these behind a login; here they are open so you can experiment.

In this simulator, the operator field deliberately accepts the transmitter's full 0–150 °C so that you can watch the program enforce the limits. On a production HMI you would also set the field's entry range from the same SP_LO_LIM/SP_HI_LIM tags, so an operator gets immediate feedback — while the program still clamps anything that arrives by another route.

You have already seen engineering units in Analog signals and how an analog limit affects a decision in Analog alarms and hysteresis.

Predict

The measured temperature stays at 55 °C and the limits are 20–80 °C.

1. The operator changes the request from 60 °C to 50 °C. What happens to the heat request? To the measured value?

2. The operator types 95 °C. What is the active setpoint, and what does the Setpoint limited indicator show?

3. With the request still at 95 °C, the engineer lowers the high limit to 70 °C. What changes — and did the operator have to do anything?

Try it

Work through the three predictions in order:

1. Change Operator setpoint from 60 °C to 50 °C, then to 70 °C. Watch Active setpoint follow exactly and Heat request switch.

2. Type 95 °C, then 5 °C. The active setpoint stops at 80 °C and 20 °C, and Setpoint limited lights.

3. Set the request back to 75 °C. Lower Engineer: SP high limit to 70 °C. The active setpoint drops to 70 °C on the next scan with no operator action. Raise it back to 80 °C and the 75 °C request is honored again.

Check your prediction

1. At a 50 °C target, 55 °C is not below the active setpoint, so the heat request turns off. The measured value remains 55 °C — changing an operator target never edits the sensor reading.

2. A 95 °C request gives an active setpoint of 80 °C, and Setpoint limited turns on so the operator knows the program did not accept the entry as typed.

3. The active setpoint becomes 70 °C immediately. The limits are evaluated every scan, so a changed limit takes effect even though the operator's request did not change. The request itself is kept, so if the limit is raised again the original target comes back.

Look closer

Step one scan after each change and read the five rungs in order:

1. Copy REQUESTED_SP_C to ACTIVE_SP_C.

2. Low limit: if the request is below SP_LO_LIM, move SP_LO_LIM into ACTIVE_SP_C.

3. High limit: if the request is above SP_HI_LIM, move SP_HI_LIM into ACTIVE_SP_C.

4. Limited flag: if REQUESTED_SP_C is not equal to ACTIVE_SP_C, the request was clamped, so turn on SP_LIMITED.

5. Use it: compare PV_C with ACTIVE_SP_C to drive HEAT_REQUEST.

The order matters. Rungs 2 and 3 overwrite the copy only when needed, so by the time rung 4 runs, ACTIVE_SP_C already holds the final value for this scan. Notice that the comparisons and the moved values both use the limit tags — no rung contains the number 20 or 80. Notice too that no rung writes to PV_C or to the request: the program never "corrects" what the operator typed, it only decides what to use.

Exactly at a limit is valid: a 20 °C or 80 °C request is used as entered, and because the active value equals the request, Setpoint limited stays off. Deriving the flag from the final result (rung 4) rather than from the limit comparisons keeps it honest even if someone later rewrites rungs 2 and 3.

In Structured Text, IEC 61131-3 (the international standard for programmable controller languages) provides the clamp as one standard function:

ACTIVE_SP_C := LIMIT(SP_LO_LIM, REQUESTED_SP_C, SP_HI_LIM);   (* LIMIT(MN, IN, MX) *)
SP_LIMITED  := ACTIVE_SP_C <> REQUESTED_SP_C;
HEAT_REQUEST := PV_C < ACTIVE_SP_C;

LIMIT assumes the low bound is not greater than the high bound. That is why the engineering fields in this HMI cannot cross: the low limit can be set from 0 to 50 °C and the high limit from 50 to 85 °C.

Change it

The guided program has a hard-coded high limit: its upper-limit rung compares against a typed-in 80 and moves a typed-in 80. With the default limits it looks correct. Set Engineer: SP high limit to 70 °C and request 75 °C. The active setpoint stays at 75 °C — the engineer's limit is being ignored.

Replace both literals in the upper-limit rung with the SP_HI_LIM tag. Run the checks, then repeat the 70 °C / 75 °C test.

Check yourself

The challenge keeps the copy rung and the heat comparison but leaves the low-limit, high-limit, and limited-flag rungs empty. Build all three so that:

• the active setpoint always stays within SP_LO_LIM…SP_HI_LIM, using the tags;

• exact endpoints are accepted as entered;

• SP_LIMITED is TRUE only when the request was replaced.

Visible checks cover the normal case, both exact endpoints, and a lowered high limit. Hidden checks send out-of-range requests straight to the program, raise the low limit, change the request over successive scans, and change a limit while the program is running. Retry as often as you need.

Hint 1: What must stay bounded?Which tag does the heat comparison use, and which tag is only allowed to hold the operator's request?

Hint 2: Compare with what?Each limit rung needs the limit twice: once in the comparison and once as the value to move. Both should be the tag, so a changed limit takes effect without editing the program.

Hint 3: Detecting a clampAfter rungs 2 and 3, the active setpoint equals the request unless one of them replaced it. One not-equal comparison is enough.

Show a worked solution

• Low-limit rung: REQUESTED_SP_C LT (less than) SP_LO_LIM → MOVE SP_LO_LIM to ACTIVE_SP_C.

• High-limit rung: REQUESTED_SP_C GT (greater than) SP_HI_LIM → MOVE SP_HI_LIM to ACTIVE_SP_C.

• Limited-flag rung: REQUESTED_SP_C NE (not equal) ACTIVE_SP_C → output coil SP_LIMITED.

For example, a direct request of 90 °C yields an active setpoint of 80 °C with SP_LIMITED on; at a measured 85 °C the heat request is off. If the engineer raises SP_LO_LIM to 30 °C, a 25 °C request becomes 30 °C.

What happened and why

The program separates three things that are easy to blur on a screen: what the operator asked for (REQUESTED_SP_C), what the engineer allows (SP_LO_LIM, SP_HI_LIM), and what the control logic actually uses (ACTIVE_SP_C). Clamping happens in the controller on every scan, so the active setpoint is correct regardless of where the request came from or when a limit was changed. The Setpoint limited indicator closes the loop with the operator: an entry that was not honored is visible rather than silently changed. The measured value remains a read-only display; it comes from the sensor input, not from any operator or engineer control.

The HMI's own entry range and the program's clamp are two layers of the same rule. The HMI gives the operator fast, friendly feedback; the program is the authority, because it is the only layer every request has to pass through.

Where this goes next: PID

In this lesson ACTIVE_SP_C drives a bare on/off comparison. In the PID lessons the same bounded value becomes the SP input of a controller, and each idea here carries forward:

• SP, process variable (PV), and controller output (CV). SP, PV, CV, and the feedback loop names the three signals. ACTIVE_SP_C is the SP, PV_C is the PV, and HEAT_REQUEST is a crude on/off CV. The rule from this lesson still holds: wire the limited setpoint into the controller, never the raw request.

• On/off control needs a deadband. A bare PV < SP comparison chatters when PV sits near SP. On/off control with a deadband fixes that with the hysteresis idea you already know from alarms.

• Setpoint limits vs output limits. A PID loop has a second pair of limits: output low and high limits bound the output in % rather than the target in °C. They are configured separately and do different jobs. Limits, unreachable targets, and windup shows what happens when a setpoint asks for more than the output can deliver: CV sits at its limit and the integral term winds up. Sensible setpoint limits keep targets reachable, which is one reason they exist — but they do not replace anti-windup.

• Setpoint changes are disturbances you choose. A large step in SP gives a large step in error, and the controller reacts to it. Setpoint tracking versus load recovery compares that with a load change. A rate limit (ramp) on the active setpoint is the usual way to soften big operator changes.

• Manual and auto. When a loop moves between manual and automatic, the active setpoint and output must be consistent at the moment of transfer. Manual/auto and a smooth handover covers that; the limits from this lesson still apply to whatever setpoint auto starts from.

• The whole chain in a program. A PID loop inside a PLC program scales the input, limits the setpoint, runs the controller, and scales the output — this lesson is the "limit the setpoint" step.

Common mistakes

• No lower or upper limit. A request outside the range becomes the active setpoint. Each end needs its own comparison and replacement; the HMI field's entry range does not cover recipes, SCADA writes, or other screens.

• Hard-coded limit values. Typing 20 and 80 into the rungs works until the engineer changes the configured limit. Use the limit tags in both the comparison and the move.

• Clamping silently. The operator types 95, sees 80 somewhere else, and has no idea why. Provide a limited indication next to the entry.

• Comparing against the request. An out-of-range request can drive the decision even when the displayed active setpoint looks correct. Use ACTIVE_SP_C everywhere downstream.

• Overwriting the request. Writing the clamped value back into REQUESTED_SP_C loses what the operator asked for, so a later limit change cannot restore it — and it fights the HMI that also writes the tag.

• Letting limits cross or exceed the next layer. A low limit above the high limit, or a high limit above the alarm, makes the range meaningless. Bound the limit entries themselves.

• Treating setpoint limits as protection. They keep requests sensible; an independent trip protects the equipment.

Platform notes

HMI products may reject, clamp, or flag an out-of-range entry; many can take the entry minimum and maximum from controller tags so the screen always matches the program. Decide and document which behavior the operator sees, and keep the displayed units consistent with the controller tags.

Many controller PID blocks include their own setpoint high/low limits and output high/low limits as parameters, and some add setpoint ramping. When they do, configure them to match — or replace — the clamp you write yourself, so there is exactly one documented source for each limit.

The bounds in this lesson are illustrative. They do not determine real equipment operating limits or replace the controls required for a real heater.

Enable JavaScript to run the embedded simulator and complete the interactive exercises.