What Happens When Two Controls Want Different Things

Why this matters

Any system old enough to have been modified has more than one thing telling it what to do, and nobody wrote down what happens when they disagree. Sometimes the machine obeys the most restrictive of them, cleanly. Sometimes there is no answer at all and it obeys whichever device happened to speak most recently, which changes by the second. The difference is not visible from either device's screen, and a tech who adjusts a setting on the wrong one of the two gets no response and concludes the device is broken.

The useful question is never "which controller is right." It is "what mechanism resolves the disagreement," because the mechanism determines whether adjusting anything will do what you expect.

One gate: where does the last physical decision get made, and can more than one device reach it?

Follow the path from both controllers toward the equipment and find the last point where a single physical thing decides whether energy flows or how far something opens. A contactor coil. An actuator's input terminal. A valve stem.

If both devices reach that point through a physical arrangement - contacts in a string, a relay that breaks another circuit - the arrangement itself resolves the disagreement, deterministically, every time.

If both devices write a value to that point independently - two controllers driving the same output, two systems commanding the same networked point - nothing resolves it, and the result is decided by whose turn came last.

Those outcomes are so different they barely count as the same problem, and the gate separates them in about five minutes of tracing.

Case one: two devices, one energy path, and the wiring arbitrates

Two heating thermostats, both closing their contacts on falling temperature, both feeding one contactor coil. Thermostat A is set to 68.0 F, thermostat B to 72.0 F.

Wired in series, both contacts must be closed for the coil to pull in. B closes below 72.0 F and A closes below 68.0 F, so the pair only completes below 68.0 F. The effective setpoint of the system is 68.0 F, the lower of the two, and B has no effect on anything above that.

Wired in parallel, either contact completes the circuit. The pair is closed below 72.0 F. The effective setpoint is 72.0 F, the higher of the two, and now A is the one with no effect.

Same two devices, same two settings, same space, and a 4.0 F difference in where the room lands, decided entirely by how two wires were landed. Both arrangements are working correctly and neither device is faulty in either case.

The failure mode is specific and common. A tech asked to warm the space up finds thermostat B, moves it from 72.0 F to 74.0 F, and nothing happens, because the series arrangement never let B govern. He moves it to 76.0 F. Still nothing. On the second visit he replaces B, which changes nothing, and now there is a new part in a string that was never the problem. The tell he skipped was one continuity trace: in a series string the device that governs is whichever one is currently open, and it is not necessarily the same device on the next call.

Case two: two devices, one commanded value, and the scan clock arbitrates

Now take an analog case: two controllers both writing a position command to one modulating actuator, either by two outputs landed on one input or by two systems writing the same networked point.

There is no arrangement to resolve this. Each controller writes on its own schedule, the actuator obeys whatever arrived most recently, and the pattern repeats on the least common multiple of the two scan intervals. The symptom is not that one controller wins. It is that neither does, continuously.

Separate this from an ordinary unstable loop, because the corrective actions are opposite. A loop that hunts from its own tuning responds to tuning; a loop that alternates because two writers contest it does not respond to tuning at either controller, and every hour spent slowing one of them makes the other's contribution more visible rather than less.

The mechanisms, and which of them are deterministic

The bottom three are not designs, they are what you get when nobody made a decision, and the last one is the most expensive: two systems working against each other on the same process both run continuously, each fully loaded, and the measured result looks stable because the capacities balance. A stable reading is not evidence that there is no conflict.

The traps inside the mechanisms that are deterministic

Deterministic does not mean safe from surprises. Four of the five have a characteristic way of going wrong that is not a failure of the mechanism; parallel contacts are the one that behaves exactly as it reads.

A series string hides its members. With five contacts in a string, four closed and one open, every meter reading says the same thing, and the string tells you nothing about which member is governing except at the terminals of the open one.

A lowest-wins or highest-wins select is dragged by its worst input. One extreme request governs by design, so a single failed input reporting an extreme value takes the whole system regardless of how many healthy inputs disagree. The mitigation is a plausibility limit on each contributing request, stated in the same engineering units as the request, not a change to the select.

A priority-level scheme holds a stale entry forever. A writer that claims a high slot and stops writing without releasing it leaves that slot occupied. Everything below it is permanently ignored, and nothing about the display says so. This is the single most common cause of "the schedule stopped working."

Hardwired priority survives every software change. A relay contact that breaks another circuit keeps doing that after the controller above it has been replaced, reprogrammed or removed, and it is the one mechanism that appears on no screen anywhere.

Worked example: the actuator that never stopped moving

A modulating actuator receives commands from two controllers. Controller X writes 40 percent every 15 seconds. Controller Y writes 70 percent every 20 seconds. The actuator's full-stroke travel time is 90 seconds. All of these are read off the devices on site.

Lay the writes on a one-minute timeline. Starting from Y's command in force, X writes at 15, 30 and 45 seconds, and Y writes at 20 and 40 seconds. The commanded value is 70 percent from 0 to 15, 40 from 15 to 20, 70 from 20 to 30, 40 from 30 to 40, 70 from 40 to 45, and 40 from 45 to 60. That is six segments summing to 60 seconds, and five reversals of direction inside the minute.

Time-weighted, the commanded value is 70 percent for 30 seconds and 40 percent for 30 seconds, so the average command is 55 percent. That it lands on the midpoint of the two is a coincidence of these particular intervals rather than a rule, and it is exactly the number a slow-updating trend will show. A trend reading a steady 55 percent while an actuator is physically thrashing is one of the more misleading pictures in controls.

Now check what the actuator can actually do with those segments. A 30 percentage point move on a 90 second full stroke takes 27 seconds. The longest segment is 15 seconds, in which the actuator covers 15 divided by 90, about 16.7 percentage points. The shortest is 5 seconds, worth about 5.6 points. So the actuator never reaches either commanded position. It wanders inside a band well short of both endpoints, permanently in motion, and neither controller's feedback ever matches its own command.

What each tech sees. Standing at controller X: a stable command of 40 percent and a feedback that never arrives, which reads as a failed actuator. Standing at controller Y: a stable command of 70 percent and the same never-arriving feedback, which reads as the same failed actuator. Two independent techs at two panels reach the same wrong conclusion from consistent evidence, and neither one is being careless.

The wear this creates. Five direction reversals per minute is 7,200 per day, against the few dozen a modulating actuator on an ordinary loop might see, so the duty is on the order of a hundred times what the device was selected for. It will fail early, it will be replaced, and the replacement will do the same thing.

The tell that separates this from a tuning problem. Isolate one controller's command - lift it at the terminals with the circuit isolated and proved dead first - and the actuator immediately drives to the other controller's value and stays there. A loop that is unstable from its own tuning does not become stable when you remove a second device that was supposedly not involved. That one test takes minutes and settles it. Keep hands and tools clear of the linkage while the actuator is powered; before touching any part of the drive train, isolate the actuator's supply, lock and tag it under 29 CFR 1910.333(b)(2), and relieve spring or linkage tension under 29 CFR 1910.147.

What would change the answer. Were the two scan intervals nearly equal rather than 15 and 20 seconds, the beat period would stretch to minutes, and the actuator would sit at one value long enough to look settled, then move for no visible reason. Same fault, completely different symptom, far harder to catch, because now the trend shows two distinct plateaus and everyone starts hunting for what changed in the building at those moments.

When one of the two is not a control at all

Before resolving any of this by removing a device from a series string, establish what that device is. A limit, a pressure switch, a flow proving switch or an interlock in that string is not a second opinion about the setpoint. It is a protective device whose whole purpose is to be the most restrictive member, and the arrangement letting it govern is working as designed.

If a protective device is the one holding the string open, the work is to establish why it opened, by measuring the quantity it watches against its stated trip point while the machine runs. Replacing a device that operated correctly puts you at the same end state as jumpering it, one step slower and with a part number on the invoice.

Confirming which mechanism you have before you change a setting

Count the writers, not the controllers. A single controller can hold two writers if a schedule and a manual entry both address the same point. The question is how many things write, not how many boxes are on the wall.

Change one setting by a known amount and predict the result first. In a series string, moving the non-governing device's setpoint produces exactly no change; in a parallel arrangement it produces a change immediately. Predicting before adjusting turns a settings change into a test.

Where the mechanism turns out to be last-write-wins, the fix is to remove a writer, not to tune one. Which one to remove is a design conversation with whoever owns each system, and it is the point at which the arbitration should be written down so the next retrofit does not recreate it.

References

• 29 CFR 1910.333(b)(2) - lockout and tagging for work on electric circuits and equipment
• 29 CFR 1910.147 - control of hazardous energy for mechanical isolation and stored energy
• Manufacturer documentation for each controller's scan or write interval, its priority or select behavior, and the actuator's full-stroke travel time
• See related: Interlocks and Why They Are Not Control; How to Find Which Controller Is Actually in Charge; The Two Systems That Were Fighting Through One Sensor