The Fault That Appears Only When Two Systems Run Together
Why this matters
The worst call to walk into is the one where every part tests good and the system still misbehaves, because the fault does not live in a part. It lives in what two systems do to each other when they run at the same time. Each one is fine alone. Together they produce a symptom that vanishes the moment you shut one off to test it. A tech who keeps meter-checking single components on this fault burns a whole visit and leaves with nothing, then eats the callback. The skill is recognizing an interaction fault early and isolating it as a relationship, not a component.
The signature: it only happens with both running
An interaction fault has a tell before you ever put a meter on it. Ask when the symptom shows and you get a two-condition answer: the water hammers only when the sprinklers run and someone flushes, the lights dim only when the compressor starts, the control locks up only when the newer system is powered. One condition alone never triggers it. If the customer can give you the second condition, they have handed you the diagnosis; most of the work is confirming it, not finding it.
The trap is that each half tests perfect in isolation. That is not a clean bill of health. It is the definition of the fault.
The isolation truth table
Stop chasing parts and run the two systems in all four combinations. Read the pattern, not any single result.
| A running | B running | Symptom present? | What it means |
|---|---|---|---|
| No | No | No | Baseline, nothing latent |
| Yes | No | No | A is innocent alone |
| No | Yes | No | B is innocent alone |
| Yes | Yes | Yes | The fault lives in the interaction |
When only the both-on row lights up, you have proven an interaction and can stop condemning either system on its own. If the symptom shows with just A running, it was never an interaction, and you are back to an ordinary single-system fault in A.
The four ways two systems collide
- Shared-resource contention. Both draw on one finite supply (amps, flow, drain capacity, combustion air) and their sum crosses the ceiling. This is its own deep topic; hand it to the related shared-resource article rather than re-deriving it here.
- Coupling and interference. One system's output leaks into another's input: induced voltage on a signal wire, vibration into a sensor, pressure pulses down a shared line, exhaust or heat into another unit's intake. The victim reacts to noise it was never meant to see.
- Control conflict. Two controllers fight over one variable, two thermostats on overlapping zones, two pumps on one loop, a demand call versus a recirculation cycle. Each is doing its job; the job descriptions overlap.
- Byproduct coupling. One system's heat, moisture, or exhaust becomes another system's operating environment. Safety branch first: if the byproduct is combustion gas or a backdraft that could spill carbon monoxide when both run, stop, confirm the space is safe with a CO instrument, and correct the venting before continuing any other diagnosis.
Which one starts first often decides it
Ordering matters. A system that starts into a resource already loaded by the other behaves differently than one that got there first. A motor that starts while voltage is already sagging may stall or trip, though the same motor starts fine when it leads. Reproduce the fault in the real start order the customer lives with, not the order that is convenient for you, or you can miss it entirely.
The fix is rebalancing, not condemning
Because the fault is a relationship, you can relieve it at either end, and none of the options require calling a good system bad:
- Separate them. A dedicated circuit, line, drain, or vent removes the shared path.
- Sequence them. Interlock or stagger so they never run at the same instant.
- Isolate or shield. Break the coupling with a filter, a check device, a barrier, or corrected routing away from the sensitive input.
- Resize. When the interaction is really a capacity or design limit, the honest fix is enlarging the shared resource, not a part swap.
Name the interaction to the customer plainly: both systems are fine, the problem is that they were never set up to run together. That framing keeps you off the hook for a part that was never broken and points at the real correction.
References
- Trade-standard practice for systems-level and interaction-fault diagnosis
- Manufacturer minimum-supply, isolation, and interference specifications
- See related: The Interaction Between Two Loads That Creates a Fault; Reading a System That Two Trades Both Touched