The Command Is On, the Equipment Isn’t: Tracing a Command That Produces No Output

The graphic says the fan is commanded on. The fan is not running. Between those two facts is a chain of maybe ten links, and the fault lives at exactly one of them. The job isn’t to guess which one. It’s to split the chain until only one is left.

“Command present, equipment off” is one of the most common calls in the trade, and one of the most commonly misdiagnosed. It gets blamed on the controller because the controller is what the tech can see from the laptop. Most of the time the controller is doing exactly what it was told. The problem is further down, somewhere the BAS has no point.

The chain, end to end

For a typical start/stop fan, the path from the graphic to moving air runs like this:

Read it top to bottom and it’s how the fan is supposed to start. Read it as a list of places to put a meter and it’s a diagnostic sequence.

First: is the command you see the command that won?

This is a free check, and it resolves a surprising share of calls before you pick up a tool.

On a commandable BACnet point, the present value is the highest-priority slot in its priority array that isn’t empty. The graphic might show the value you just wrote, or the value the logic is producing at a low priority, while a manual command left at priority 8 months ago holds the output off. Everything in the program can be right. It just isn’t the opinion that won.

• Read the priority array on the output point, not just the present value. Look for anything at a higher priority than the logic writes at.
• Check the output point itself, not the logic block feeding it. A block can say on while the point is in manual, overridden, or out of service.
• Find out who wrote it and why before you relinquish it. An override is sometimes a safety decision somebody made on purpose.

Then do the other free checks from the field side. Is the HOA in AUTO? Is the drive keypad in local, hand or off? Is the disconnect on? Is anything alarming that you haven’t read, including alarms that cleared an hour ago? Has anybody already worked on it? That last question saves more time than any other.

Half-split at the controller output

Don’t start at the graphic and walk down, and don’t start at the motor and walk up. Start in the middle. Put a meter on the controller’s output terminals with the command on.

If the output is right, everything above it (software, logic, priority, controller) is fine, and you have eliminated half the stack in one test. If the output is wrong, everything below it is irrelevant for now. Seven layers resolve in about three tests if you split them, and in seven if you walk them.

Output right at the controller and wrong at the device means the wiring in between: a loose terminal, a broken conductor, a landing on the wrong terminal after a controller swap. Right at the device and nothing moves means the fault is in the device, the circuit it switches, or the equipment.

Walk the rest of the path

“Works in hand, not in auto”

This one is worth its own section because it tells you so much for free. In HAND, the HOA switch bypasses the controller path and energizes the starter directly. If the equipment runs in HAND, the motor, the starter, the power circuit and usually the safeties are fine. The fault lives in the part of the circuit only AUTO uses: the controller output, its wiring, the interface relay, or anything wired into the auto leg only.

A failed relay coil in the auto path is one of the most common answers. Test it the way the table says: power off, one leg lifted, measure the coil. Don’t replace the controller because the equipment “won’t take a command.” Measure the output first. It’s usually fine.

Sometimes the equipment is running

Before you walk any of this, go look. A “no output” call is sometimes a “no proof” call: the fan is running and the status says it isn’t. A fixed-setpoint current switch whose trip point sits above the motor’s running current after a drive retrofit or a belt change will report off forever while the fan turns happily. The BAS alarms, the tech assumes the fan is dead, and the investigation starts in the wrong place.

The reverse happens too. Commanded 60 Hz, the drive running at 48 Hz because it’s current-limiting to protect itself. The command is on, the equipment is on, and the output still isn’t what the command asked for. Command, running and result are separate facts, and each one needs its own proof. Everything looks normal, but the equipment isn’t working is the same lesson from the other side.

The order, on one card

1. Go look. Is it actually off? Is anything alarming, at the panel or on the drive?
2. Free checks. HOA in AUTO, drive in remote, disconnect on, priority array clear of stale overrides.
3. Meter the controller output with the command on. This splits the stack in half.
4. Meter at the device end of the wiring. Same reading, within a small drop.
5. Walk the relay, HOA and safety string with the black lead on common. Midpoint first.
6. Read the starter or drive. Does it see a run command? What mode is it in? What’s in its fault history?
7. Verify in AUTO, under the conditions where it failed. A fix verified in HAND is not verified.
8. Document what failed, what you measured at each point, what you changed, and any override you released and who placed it.

If you want the method in context, reading a sequence of operations tells you what the command should be in the first place, and intermittent problems covers the version of this call where it starts fine on Monday and fails on Thursday.

The controller is the most visible link in the chain and the least likely to be broken. The meter is how you stop blaming it.

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

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