An intermittent fault is the call every tech dreads. It happened at 2 a.m., or every few days, or only when nobody was watching. You arrive, everything works, you poke around for an hour, change something that looks suspicious, and leave. Three days later it happens again.
The rule for intermittent problems is short: trend it and come back. Do not guess. That sounds passive. It isn’t. Done properly it’s the most active kind of troubleshooting there is, because you’re building the evidence the fault refuses to give you in person.
Step one: define it better than the call did
“It keeps going offline” and “it trips sometimes” aren’t complaints you can work. You need the shape of the fault, and most of it is already sitting in the system for free.
- Exactly when? Get timestamps. Alarm history and event logs are free timestamps, including alarms that cleared themselves before anyone looked.
- How often, and how long? Once a week for an hour is a different problem from forty times a day for two seconds.
- What exactly happens? A trip, a dropout, a wrong value, a comfort complaint? Which device, which point?
- What changed? A renovation, a power event, a controller swap, a firmware update, a new device on the network, another trade in the ceiling. Check the change log if there is one. Ask if there isn’t.
- Has anyone already worked on it? Somebody usually has, and what they changed is part of the evidence.
Ask the people who reported it to write down the time the next time it happens. One accurate timestamp from an occupant is worth an afternoon of theories.
Step two: trend before you touch
Set up the trends before you change anything, so the first thing you capture is the fault as it really is, not the fault after your adjustments.
- Trend the process variable, setpoint and output together. Any one alone is ambiguous.
- Trend command and feedback together on anything that moves or starts.
- Trend the neighbours. Outside air temperature, the other equipment on the same transformer, the other devices on the same trunk. Correlation is the whole game, and you can’t correlate with something you didn’t record.
- Trend fast enough to see it. A two-second dropout disappears completely on a fifteen-minute trend. Your trend interval is hiding the problem goes into why.
- Log in the controller where you can. A trend polled by the supervisor goes blank when communication drops. That gap is data, but it can’t tell you what the equipment did during it. Heavy trend polling on a slow field bus can also cause the intermittent dropouts you’re chasing.
- Look at a longer window than you think you need. A pattern invisible over two hours is often obvious over two days.
Step three: correlate
Once you have a few occurrences on a trend, stop looking at the fault and start looking at what else was happening at the same moment. The pattern points at the cause.
| Pattern | Suspects |
|---|---|
| Same time every day | A schedule: this unit’s, another system’s, a big load starting, a cleaning crew, sun reaching a sensor, a time-sync problem shifting everything by hours |
| When another piece of equipment starts | Electrical noise, a voltage sag on a shared transformer, a shield grounded at both ends picking up ground current, VFD leads run beside signal wire |
| With the weather | A threshold being crossed back and forth: an OAT lockout or changeover with no hysteresis, a freezestat on cold mornings, condensation in a junction box, thermal expansion at a marginal landing |
| With vibration or running equipment | A loose landing, a corroded contact that drops out when shaken, a connector on a fan-mounted device |
| Many devices at once, no schedule | Network: an address conflict, a duplicate MAC, missing bias, an overloaded trunk or supervisor |
| One device, random, always recovers | A marginal timeout on a slow path, a device answering just slower than the supervisor waits |
| Started on a specific date | Whatever changed that day. The start date is one of the biggest clues you will ever get |
The weather row catches a lot of people. A decision made with a single number (“economizer allowed below 62 °F”) behaves perfectly on most days and falls apart on the one afternoon outside air sits right at 62 and sensor noise flips the answer every few seconds. The damper slams, the compressors cycle, and by the time anyone arrives the temperature has moved on. The fix is hysteresis, two numbers instead of one, and the trend is how you see it.
The “other equipment starts” row catches the rest. A controller that resets only when the exhaust fans on the same transformer start is telling you about the transformer, not the controller: measure it loaded, because an unloaded reading proves nothing. A trunk that drops every time the chiller starts is often a shield grounded at both ends, carrying ground current between two panels that aren’t quite at the same potential. Neither fault exists while the building is quiet, which is exactly when most people go looking.
Step four: leave a trap
If the trends don’t catch it, make the fault leave evidence when it happens. You won’t be there. Your instruments will.
A latch on the thing that trips
A momentary opening of a safety or a status contact might last half a second. A trend can miss it completely. A latched flag with a timestamp won’t. If you add one, it’s a change to the program: document it, tell the facility, and take it out when you’re done.
Communication counters
Most controllers and routers keep counts of timeouts, retries, and frame or CRC errors. Clear them, come back tomorrow, and compare. A counter that climbs only on one side of a trunk tells you where to look.
A capture that runs while you’re gone
A laptop left on the network with a ring-buffer capture (a set of files that overwrite the oldest when full) will hold the minutes around the fault. On an MS/TP trunk, a frame capture shows framing errors, missing tokens and the token loop time climbing before a device drops. Why “offline” isn’t always offline covers what to look for in it.
A meter that remembers
Many meters have a min/max or recording mode. Left on a control transformer or across a signal, it tells you whether voltage sagged when the fault happened, even though you weren’t there to see it. Only leave a meter connected where it’s safe and secured to do so.
Step five: make it happen on demand
A diagnosis is proven when you can make the symptom appear and disappear. If you can, you own the problem. If you can’t, you have a correlation. Correlations are useful, but they aren’t a diagnosis.
- If it correlates with a chiller or big motor starting, start it while you watch the trunk or the signal.
- If you suspect a loose landing, tug-test the terminations one at a time while watching the value or the comm counters. Know what each wire controls before you disturb it.
- If it follows a threshold, trend the input right at the threshold and watch the decision flip.
On an MS/TP trunk, a loose landing at one device produces a signature worth knowing: everything past that point drops intermittently while everything before it is solid. Resistance and voltage readings taken at each device, compared end to end, usually find it. MS/TP wiring, termination and biasing covers the readings.
Sometimes the intermittent fault is the alarm
“It alarms several times a day and it’s always fine when anyone looks” is sometimes exactly what it sounds like: the alarm has no time delay and no deadband, and normal operation crosses its threshold. The fault isn’t in the equipment. It’s in the alarm configuration. The fix is a real delay and a real deadband, not a higher threshold that hides the next real event. Why nobody reads your alarms covers the rest.
Document the trap, too
Write down what you measured, what the trends showed, what you changed, and how long you verified. Then write down every trap you left: the extra trends, the latch, the capture laptop, the meter. Remove what should be removed. A forgotten fast trend on forty points is somebody else’s intermittent problem next year.
Intermittent faults are only hard when you try to solve them in the ten minutes they aren’t happening. Give the building a week to tell you, and it usually will. If it looks like everything is fine but the complaint keeps coming, read Everything looks normal, but the equipment isn’t working next.
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 FundamentalsFound a wrong number or a broken link? Tell me and I’ll fix it.