Education · Status & Proof

Status & Proof Signals

Every equipment graphic has a fan icon that turns green when the fan is "on." That green is not the fan — it is a binary input reporting whatever the status device on the other end of the wire happens to prove, and the gap between those two things is where a whole family of service calls lives. This page is about that gap. One question, start to finish: when the graphic says a fan is ON, what is the controller actually sensing — and why do command and status sometimes disagree? How a status contact physically lands on a binary input — the wetting current the controller supplies, dry versus externally powered contacts — is Controller Wiring's ground; here the landing is taken as given, and the question is what the closed contact actually means. (This is the binary half of the chapter's believe-the-graphic question — Analog Sensing asks the same thing of the analog values beside that fan icon.)

The status-source menu

Command is the easy half: the controller closes a binary output and the starter pulls in. Status is the return trip — some device out at the equipment closes a contact to say it worked, and the controller reads it on a BI. What that contact is attached to decides what "it worked" means, and there are three common choices, in rising order of how much they prove.

A starter auxiliary contact is a spare contact ganged to the contactor's armature: when the coil pulls the power poles in, the aux goes with them. It is the cheapest status there is, and what it proves is exactly this: the contactor closed. Nothing downstream is in the picture — not whether the motor drew a single amp, not whether the belt survived, not whether any air moved. An aux contact is one honest step above wiring nothing at all and letting the graphic show the command back to you: it proves the starter answered, and no more.

A current switch is a small current transformer clamped around one motor lead, with an adjustable trip point: when the current through its sensing window rises above the trip, the contact closes. Now the proof reaches past the contactor to the motor itself — closed means the motor is drawing amps, real electrical work, not just a closed set of poles. What it still cannot see is the machine on the far end of the shaft. And its honesty hangs on a setting — the trip point — which section 3 comes back to.

A differential-pressure switch reads the pressure rise across the fan, its two sensing tubes tapped into the duct on either side; a paddle switch — a sail in the airstream — swings closed when moving air pushes it. Either way, the proof is the delivered effect itself: air is moving. On the water side the same rung is a flow switch or a DP switch across the pump. This is the strongest proof on the menu, and — because it watches a live physical quantity instead of a contact block — the touchiest to set up, which is also section 3's business.

The classic separator for all three is a broken belt. Snap the belt on a belt-driven fan and walk the menu: the aux contact says ON — the contactor genuinely is closed; it is not lying about the thing it watches. The current switch sees a motor spinning freely with no load — the draw falls to its unloaded level, and whether the switch still "proves" depends entirely on where the trip sits. The DP switch says OFF — no air, no pressure rise, no proof. One fault, three different verdicts, each source reporting honestly on the thing it was built to watch. Keep that picture; the rest of the page keeps coming back to it.

Whichever source you pick, it reaches the controller the same way: a dry contact landed on a binary input, wetted by the controller's own sensing voltage. The landing rules live in Controller Wiring, and the wiring simulator models exactly this case — a dry status contact on a BI you can land yourself and fault on purpose.

One fan circuit, three status sources, and what each one proves A belt-driven fan circuit drawn once, left to right: line power enters a contactor, a motor lead runs from the contactor through the sensing window of a current switch to the motor, a belt connects the motor pulley to the fan pulley, and the fan sits in a duct with air flowing out to the right. Three status sources are tapped at their physical points, each with a dashed leader down to a card describing it. The auxiliary contact rides the contactor and proves only that the contactor closed — blind to amps, belt, and air. The current switch clamps the motor lead and proves the motor is drawing amps — blind to the belt and the air. The differential-pressure switch taps the duct on either side of the fan and proves air is actually moving — the delivered effect itself. A caption reads: three different claims — contactor closed, motor drawing amps, air moving. line power CONTACTOR coil + poles M motor belt air DP SWITCH AUX CONTACT spare contact on the starter PROVES: CONTACTOR CLOSED blind to: amps · belt · air CURRENT SWITCH CT clamped on a motor lead PROVES: MOTOR DRAWING AMPS blind to: belt · air DP / PADDLE SWITCH taps across the fan PROVES: AIR MOVING the delivered effect itself three different claims: contactor closed ≠ motor drawing amps ≠ air moving

power path status tap moving air

Proof logic — command, wait, expect

With a command point and a status point on the same fan, the controller can do something neither point does alone: compare them. Command-versus-status comparison is proof logic — the sequence commands the fan, then expects the status to confirm it, and treats disagreement as a fault instead of trusting either side blindly.

The wrinkle is time. A real fan takes a few seconds to pull in, come up to speed, and build enough pressure to close a DP switch — so the comparison runs on a proof window: command it, wait a defined time, then expect proof. Set the window too short and every legitimate start trips a nuisance alarm — the fan was coming; the logic didn't wait. Set it too long and the window becomes a blind spot: a start that genuinely failed runs unreported for the whole delay, and anything the sequence interlocks against "proven" — an electric heater that must never run without airflow, a downstream stage waiting its turn — inherits that blind spot with it. The window should be as long as the slowest honest start, and no longer.

When the window expires with the command ON and the status still OFF, that is a fail-to-start: the controller alarms, and most sequences also latch the command back off — there is no point holding a start signal into a fault, and some failures get worse if you keep trying. The block-level way the window is actually built — an on-delay timer holding the fail alarm off while the fan comes up — belongs to a lesson on timers and delays.

Disagreement runs in two directions, and they point at different suspects. Commanded ON, status OFF is the fail-to-start family: no control power at the starter, a coil that never pulled in, a tripped overload — or, per section 1, a fault the chosen status source can see that a cheaper one could not. Commanded OFF, status ON is stranger and often more urgent: the equipment is running, and the controller is not the one running it. A hand-off-auto switch left in HAND, a welded contactor, a jumper someone left behind from troubleshooting — the machine has an authority problem, not a proof problem. The same comparison catches both; the direction tells you which story you are walking into.

And all of it rests on the status point itself telling the truth — a point that reads backwards will alarm on every healthy start and bless every real failure. Proving the point before trusting the logic — actuate the real contact, watch the value land where the sequence expects — is point-to-point checkout, Controls Commissioning's ground.

Binary fault signatures

Binary status points fail in a small number of recognizable ways, and each leaves a distinct signature on the graphic and in the alarm log. Learn the signatures and you can often name the fault before you leave the desk.

Inverted polarity. A NO/NC mismatch between the contact and the point's configuration — the device offers both contact types and the wrong one got landed, or the point's polarity flag is set backwards. The point is not dead; it tracks perfectly, inverted. Because most equipment holds one state for hours, it presents as a status stuck at the wrong value: perpetual ON on a unit that sits off, perpetual OFF on one that runs around the clock. The giveaway is the alarm pattern at the transitions — a fail-to-start on every start of a fan you can hear running, and a running-unexpectedly alarm the moment it legitimately stops. Backwards twice is the signature; a genuinely dead point never changes at all.

Chattering status. The point flips ON/OFF rapidly, spamming alarms and change-of-value traffic. Two usual causes. Mechanical: a loose termination, or a contact bouncing with equipment vibration. Marginal: a DP switch set so close to the fan's actual operating pressure that normal swings — VAV dampers throttling back, a filter loading up — walk the pressure back and forth across the trip. If the chatter tracks the system (worse at low load, gone at full speed), suspect the setpoint margin; if it tracks the machine's vibration, suspect the termination. The fix is margin: set the trip so the normal operating point sits well past it, and let the switch's built-in differential do its job.

A current-switch trip set below the unloaded draw. The broken-belt caveat from section 1, now as a number. A motor that loses its load does not stop drawing current — it drops to its unloaded draw, mostly magnetizing current, commonly somewhere around a quarter to a third of nameplate on a fan motor. Set the current switch's trip below that and the switch will "prove" a motor spinning a broken belt forever: the draw never falls under the trip, so the contact never opens. The trip belongs above the unloaded draw and below the normal running draw — that window exists on any healthy belt-driven load, and putting the trip inside it is the whole reason to buy a current switch instead of settling for an aux contact.

Here is the section-1 machine one more time — belt snapped, all three sources reporting at once. Two of them say ON. Both are honest about the thing they watch, and both are wrong about the fan.

The same fan with the belt snapped — three status verdicts The same belt-driven fan circuit as the previous diagram, but the belt between the motor pulley and the fan pulley is drawn snapped, and no air moves in the duct. The three status-source cards now carry verdicts. The auxiliary contact reads ON — true, the contactor is closed, but it says nothing about the fan. The current switch reads ON with an asterisk — the motor is still drawing its unloaded current, and the trip point sits below that draw, so the switch keeps proving. The differential-pressure switch reads OFF — no air, the only source that caught the failure. A caption reads: two honest ONs, one true answer — only the source watching the air catches the broken belt. line power CONTACTOR closed M spinning, unloaded belt snapped no air DP SWITCH AUX CONTACT ON true — the contactor is closed and useless about the fan CURRENT SWITCH ON * * trip sits below the motor's unloaded draw DP / PADDLE SWITCH OFF no air — the only source that caught the failure two honest ONs, one true answer — only the source watching the air catches it

power path status tap

That is the whole lesson in one drawing: status is not a fact about the fan — it is a fact about whatever the status device watches. Pick the source that proves what the sequence actually needs proven (a duct heater's interlock wants air, not amps), wrap the comparison in a proof window long enough for an honest start, and when command and status disagree, read the direction before you drive out. The graphic's green icon is only ever as truthful as the contact behind it.

← Back to Education