Control troubleshooting: the capstone calls

In the last week of Theo's controls block, Dana gave him four calls and a rule: before touching anything, he had to say out loud what the control was trying to do, what it thought it was seeing and what the equipment was actually doing. "Control problems are almost never mysteries," she said. "They're disagreements. The control believes one thing and the world is doing another. Find the disagreement and you've found the fault." Raj would ride along on two of the calls, and Theo would write up all four.

This capstone lesson brings together the course: control loops and differentials, sensors, operating and safety controls, defrost, case controllers, communicating equipment, economizers and building automation. It begins with a method for control troubleshooting and then works through four calls, each with a different kind of fault.

A method for control calls

The method extends the systematic approach from RAC-130 and RAC-220 to controls. It works for a walk-in thermostat and for a chiller plant on a BAS.

• 1. Get the complaint and the history: what happens, when, since when and what has changed, such as a renovation, a power failure or a new part.
• 2. Read before you reset: fault codes, histories, alarm logs and trends.
• 3. Know the intent: the sequence of operation or the manufacturer's description of what the control should be doing now.
• 4. Check what the control sees: compare each relevant sensor reading with a calibrated instrument at the same place.
• 5. Check what the control commands and what the device does: command against status, signal against position, output against the device's actual state.
• 6. Check the settings: setpoints, differentials, delays, schedules, overrides, changeover and lockout values.
• 7. Fix the cause, test the whole sequence, release any overrides you placed and record what you found and changed.

Call 1: the brewery's glycol chiller hunts

Priya reported that the glycol chiller serving the fermentation tanks, installed new in RAC-110, had started cycling its compressor speed up and down every few minutes, and the tank temperatures were wandering. The chiller's controller trend showed the leaving glycol temperature swinging about 3 °F above and below setpoint with a period of about seven minutes, and the compressor output swinging between minimum and maximum with it. The PI settings matched the commissioning record. Theo compared the controller's leaving glycol reading with a probe in a spare test well beside it: the controller lagged the probe by more than two minutes after every change.

Following the sensor, he found it had been pulled out of its thermowell during a pump repair the month before and pushed back in only halfway, without heat-transfer paste, leaving it measuring mostly the air in the well. The extra lag in the measurement was enough to destabilize a loop that had been tuned for a fast sensor.

# The same PI loop with a fast sensor and with a slow, poorly seated sensor (illustrative chiller model)
def run(sensor_tau, kp=11.1, ti=3.0, minutes=60, dt=0.02):
    sp, temp, meas, integral = 25.0, 25.0 + 1.8, 25.0 + 1.8, 0.0
    tau, dead, gain, load = 4.0, 1.0, 0.288, 43.0
    hist = [60.0] * int(dead / dt)
    lo, hi = 1e9, -1e9
    for k in range(int(minutes / dt)):
        meas += (temp - meas) / sensor_tau * dt        # the sensor lags the glycol
        err = meas - sp
        integral += err * dt
        out = max(0.0, min(100.0, kp * err + kp / ti * integral))
        hist.append(out); applied = hist.pop(0)
        temp += (load - gain * applied - temp) / tau * dt
        if k * dt > 30: lo, hi = min(lo, temp), max(hi, temp)
    return lo, hi

for name, st in (("sensor seated with paste", 0.1), ("sensor half out of its well", 1.8)):
    lo, hi = run(st)
    print(f"{name:28s}: glycol swings {lo:6.2f} to {hi:6.2f} F in the last 30 minutes (band {hi - lo:.2f} F)")

sensor seated with paste    : glycol swings  25.00 to  25.00 F in the last 30 minutes (band 0.00 F)
sensor half out of its well : glycol swings  22.23 to  27.55 F in the last 30 minutes (band 5.32 F)

Theo cleaned the well, packed it with heat-transfer paste, seated the sensor fully, secured its gland and insulated over it. Within twenty minutes, the trend settled to within a few tenths of a degree of setpoint and the compressor speed smoothed out. He did not touch the PI settings: the tuning was right for the system as designed, and changing it to suit a bad sensor would only have left a slow loop for the next technician to find.

Call 2: Rosa's walk-in starts every few minutes at night

Rosa's kitchen walk-in, set up for pump-down in lesson 3, had started making short runs all night, each lasting under a minute. The digital thermostat showed the box satisfied, and its liquid line solenoid output was off. That combination, a compressor starting while the thermostat is satisfied, pointed to the pump-down control, so Theo put gauges on and watched an off cycle. The suction pressure rose steadily from the pump-down cut-out and reached the cut-in in about six minutes, and the compressor ran just long enough to pump it back down. Lesson 3 described what this means: refrigerant was leaking into the low side, either through the solenoid or back through the compressor.

To separate the two, Theo closed the liquid line service valve at the receiver during an off cycle. With the solenoid isolated, the suction pressure stayed flat, so the compressor valves were tight and the solenoid was leaking. With the system pumped down and isolated, Raj opened the solenoid and found a fleck of brazing scale under its seat, left from a coil repair upstream. He replaced the seat and plunger kit, installed a new filter-drier, evacuated the short isolated section, and Theo confirmed over the next hour that the low side held steady between calls. He noted in the record that recycling pump-down had done its job as a diagnostic: in single pump-down, the same leak would have gone unnoticed.

Call 3: the clinic's rooftop unit will not cool on a hot day

On the first hot day in June, the dental clinic reported warm operatories, and its rooftop unit's compressors were not running at all, although the supply fan was. The economizer controller showed an alarm, and its outdoor air temperature read −40 °F. The unit's sequence included a low ambient compressor lockout: below a set outdoor temperature, the compressors are locked out and the economizer does the cooling, to protect them from running at very low head pressure. With the sensor reading −40 °F, the controller believed it was the coldest day of the year and was trying to cool the clinic with outdoor air at 88 °F.

# Low ambient compressor lockout with a failed outdoor air sensor (values illustrative)
LOCKOUT = 50.0          # compressors locked out below this outdoor temperature
SENSOR_MIN, SENSOR_MAX = -40.0, 140.0   # readings at or beyond the ends of the range indicate an open or short circuit

def decide(oat_reading, cooling_call):
    if oat_reading <= SENSOR_MIN or oat_reading >= SENSOR_MAX:
        return "sensor fault: alarm, use the fallback strategy in the sequence"
    if cooling_call and oat_reading < LOCKOUT:
        return "compressors locked out, economizer cooling only"
    return "compressors allowed" if cooling_call else "no cooling call"

for reading in (88.0, 39.0, -40.0):
    print(f"outdoor reading {reading:6.1f} F -> {decide(reading, True)}")
print("without a range check, the open sensor would read as a very cold day and lock out the compressors")

outdoor reading   88.0 F -> compressors allowed
outdoor reading   39.0 F -> compressors locked out, economizer cooling only
outdoor reading  -40.0 F -> sensor fault: alarm, use the fallback strategy in the sequence
without a range check, the open sensor would read as a very cold day and lock out the compressors

The unit's older economizer controller treated the reading as real; newer controllers with fault detection would have flagged it and fallen back to allowing the compressors. At the sensor, Theo measured an open circuit: a bird had pulled its cable apart under the hood. He replaced the sensor and cable, routed the new cable in conduit, confirmed the reading against his hand-held thermometer in the shade, and the compressors started on the next call. Because the old controller had no sensor fault logic, Dana recommended upgrading the economizer controller, which would also bring the fault detection the current energy code expects on new units.

Call 4: the residence's walk-in freezer alarms at 3 a.m.

The residence's new alarm routing from lesson 11 worked: at 3:10 a.m., Northfield's on-call phone received a high-temperature alarm from the kitchen walk-in freezer. Raj logged in remotely through the residence's approved remote access and checked the controller's trend: the box had been warming slowly since about midnight, the compressor output was on, but the evaporator fan output was off, and the door input showed the door open, although the night cook confirmed it was closed. The controller's door settings stopped the fans whenever the door was open and, after a delay, raised a door alarm, but someone had changed the door alarm delay to its maximum and set the fans not to restart while the door was open.

In the morning, Theo found the door switch's magnet bracket bent where a cart had hit the door frame the previous evening, so the switch no longer closed. With the fans stopped, the coil had frosted and the box had warmed. He realigned and replaced the bracket, confirmed the door input changed state as the door opened and closed, forced a defrost to clear the coil and, with Raj, reviewed the door parameters against the settings recorded in lesson 6. The parameter changes had been made during the integration visit for testing and never reversed. They restored the recorded values, which restart the fans after five minutes of door-open time and alarm after ten, and re-ran steps 1 and 2 of the functional test from lesson 11.

The write-ups

Theo's four write-ups each answered the same questions: what the complaint was, what the control was trying to do, what it was seeing, what the equipment was doing, where the disagreement was, what caused it, what he changed and how he proved it was fixed. Dana read them in the van. Every one of the faults had been outside the controller itself: a sensor half out of its well, scale under a solenoid seat, an open sensor cable and a bent bracket with a test setting left behind. "See the pattern?" she asked, and then answered herself. "Not one new board. That's what good controls work looks like."

Writing a good service record

A control repair is not finished until it is recorded. A good record lets the next technician, who may be you in a year, understand what was found and why it was changed. It lists the complaint in the customer's words, the readings and fault codes found, the disagreement and its cause, every part replaced, every setting changed with its old and new values, any overrides placed and released, and the tests that proved the fix. It also notes anything recommended but not done, such as Dana's suggestion to upgrade the clinic's economizer controller. Records like these build the equipment history that makes later diagnosis faster, and they protect both the customer and the contractor when questions arise.