Interlocks and Enables: Why the Equipment Won’t Run When Everything Says It Should

The schedule says occupied. The start command is on. There are no alarms you can see. And the equipment won’t run. More often than not, nothing is broken. Something is doing its job: a safety, an interlock, an enable waiting for a proof, a lockout, or a timer that hasn’t expired. The trouble is that the BAS often can’t tell you which one.

Equipment in a building runs behind a stack of permissions. Every one of them was put there on purpose, and most of them are invisible on the graphic. Finding which permission is missing isn’t a matter of experience or luck. It’s a matter of walking the chain in order.

The principle. An interlock that stops equipment is working until you prove otherwise. Your job isn’t to get the equipment running. It’s to find which condition is holding it off, and why that condition is true.

Two different animals

“Interlock” gets used for two very different things, and mixing them up is how people end up resetting the wrong one.

	Hardwired safety	Software interlock or enable
Examples	Freezestat / low limit, duct smoke detector, high static cutout, motor overload, fire alarm shutdown relay, drive safety input	Fan proof enabling heating and cooling, outside air lockouts, minimum off timers, freeze latch, mode enables, lead/lag failover
Where it lives	In series in the control circuit	In the controller program
Works when the controller is dead?	Yes. That’s the point	No
Does the BAS see it?	Only if somebody wired it to an input	Yes, if you know where to look in the logic
How you find the open one	A meter, walking the string	Reading the logic, one condition at a time

A proper design has both. Freeze protection is a hardwired safety first and a software function second: the low limit is wired into the fan starter circuit so it stops the fan whether or not the controller is running and whether or not the program is right. The software supplements it. If you find freeze protection that exists only in software, that’s a finding to report.

The enable chain

On most air handlers, permissions stack in a specific order, and each link waits for the one before it:

Schedule or occupancy calls for the unit.
The fan start command goes out.
The safety string has to be closed for the starter or drive to respond.
The fan runs, and the proof (a current switch or airflow switch) has to close within a proof delay.
Fan proven enables the economizer, heating and cooling.
Each of those has its own conditions: outside air lockouts, mode, minimum off timers, stage delays.

The consequence is that a broken link early looks like a dead system late. A cooling complaint can be a proof problem: the fan is running, the current switch never closes because its trip point is above the motor’s running current, so the program never sees a proven fan and never enables cooling. Nobody looks at the proof, because the complaint was about cooling.

Read the chain from the complaint backwards. Cooling isn’t running. What enables cooling? Is that condition true right now? If not, what enables that? Keep going until you hit the first condition that’s false. That’s your link.

The permissions people forget

Lockouts

Compressors locked out below a low-ambient limit. Heating locked out above an outside air temperature. Economizer locked out above a high limit. Each lockout depends on a sensor, and a lockout is only as right as the sensor feeding it. A drifted outside air sensor reading a few degrees warm can hold a heating lockout on through a cold morning without a single alarm. See sensor drift.

Look for: the lockout’s input value, and whether it matches reality, not just whether the lockout is on

Timers

Minimum off (anti-short-cycle) timers, proof delays, stage delays, staggered restarts after a power outage. Plenty of “it won’t start” calls are equipment that would have started on its own in four more minutes. Protection timers sit closest to the output on purpose, and they’re equipment protection. Shortening one to make a call go faster is how compressors get destroyed.

Look for: a timer counting down, and when the equipment last stopped

Latches and manual resets

A freeze condition that latches until someone resets it. Often there are two resets: the device itself (a manual-reset low limit on the coil) and the software latch in the program. Reset one and not the other and the unit still won’t run. A good program also refuses to clear its latch while the input is still in trip. That’s correct behaviour, not a bug.

Look for: which reset is still pending, and whether the input has actually returned to normal

The fire alarm system

A duct smoke detector in alarm or supervisory, or a fire alarm shutdown relay holding the unit off, looks from the BAS exactly like any other open safety: commanded on, no proof, fan failure alarm. After duct cleaning or detector service, check the fire alarm panel early. And don’t simply reset a smoke detector. It belongs to another system with its own responsible people.

Walking the chain, in order

Here’s the sequence I use. It follows the troubleshooting method: what should be happening, what the BAS believes, what the equipment is actually doing, then the layer.

1. Read the sequence and write the chain down

List every condition that has to be true for this piece of equipment to run, in order. If there’s no written sequence, read the program. Reading a sequence of operations covers what to pull out of it, including the interlocks the sequence forgot to mention.

2. Read the drawing to learn what the BAS can’t see

The control drawing tells you which safeties are in the string and which of them have a point in the BAS. On many units the BAS commands the fan and reads its proof, and has no point on the freezestat, the smoke detector or the high static switch. All three failures look identical on the graphic. Knowing that is often the most valuable thing on the page.

3. Check the software side, one condition at a time

For each enable in your list: is the condition true right now? Look at the live value going into the block, not the label on the graphic. Look for timers counting, latches set, lockouts active, modes you didn’t expect. Stop at the first false condition.

4. Check the hardwired side with a meter

If the software says run and the equipment doesn’t, walk the safety string. Black lead on the transformer common, left there. Probe the midpoint first, then halve again. Voltage on one side of a device and none on the other identifies the open device. Tracing a command that produces no output walks the rest of that path.

5. Find out why it tripped before you reset it

A tripped safety is a safety doing its job. A freezestat that trips four times a month isn’t a bad freezestat until you’ve proven the coil wasn’t really getting cold. Often the fault is upstream in the sequence, like a 100% outside air unit opening its damper before preheat is proven. Adjusting the freezestat would “fix” the call and eventually cost a coil.

6. Reset, verify in automatic, document

Reset what needs resetting, then watch the whole chain come up in AUTO: fan, proof, enables, stages. Trend it through the next start if the trip was intermittent.

Never jumper a safety to “test” or to keep a space running. If the fix requires defeating a freezestat, a high static cutout, a smoke detector or a high limit, the fix is wrong or the decision is above your pay grade, and usually both. And if you find a jumper someone else left across a safety, that’s a finding. Report it; don’t quietly work around it. Nobody has ever been fired for asking before bypassing a freezestat.

When the software interlock is wrong

Sometimes the interlock really is the fault: a lockout that never clears, a latch that clears on its own, an enable that checks the command instead of the proof. The tests that find these are simple to describe and easy to skip:

Does the interlock fail toward safety? If the sensor fails or reads bad, does the logic treat it as the dangerous case? Fail-safe is a direction, not a feature.
What happens when two conditions arrive together? A freeze trip during an occupied override, or a reset pressed while the low limit is still tripped. A sequence that works one input at a time can still fail with two at once.
Does the interlock outrank everything else? A freeze condition has to win over a minimum-position ventilation requirement and over an operator override. If it doesn’t, the damper can stay open during a freeze event.
Is the enable based on proof, not command? Enabling heating because the fan was commanded on isn’t the same as enabling it because the fan is proven running.

Changing a sequence is engineering work. If you find one of these, document it and take it to whoever owns the sequence. Don’t just rewrite it on a Friday afternoon.

Document the chain

Write down the chain you walked, not just the link that was open: every condition, what it read, and where you measured. Mark up the drawing if the panel didn’t match it, and get the marked copy to facilities, not just into your own file. The next tech who gets this call will start at the link you found instead of at the top.

When everything reads normal and the equipment still isn’t doing its job, the chain may be intact and the fault somewhere the controls can’t see at all. That’s everything looks normal, but the equipment isn’t working. And if the unit runs sometimes and not others, start with intermittent problems.

Stuck on a live call? The BAS Troubleshooter walks you through this method step by step, offline, on your phone.

Go deeper

The method behind this, chapter by chapter

Every sensor, drive and control loop in the building — how it works, how to prove it with a meter, and how it fails. BAS Field Fundamentals is the method this article uses, with 20 field cases and a browser diagnostic simulator to practice on.

Get BAS Field Fundamentals

Found a wrong number or a broken link? Tell me and I’ll fix it.