The Interaction Between Two Loads That Creates a Fault
Why this matters
Some faults do not live in any one component. They live in the relationship between two loads that were fine on their own and became a problem together. This is the class of fault that makes a good tech look bad, because every part tests good and the system still fails. Understanding how two loads interact through a shared, finite resource is what lets you diagnose the space between the parts instead of the parts themselves.
Every shared resource has a finite budget
Any resource two devices share has a ceiling. A circuit carries only so many amps, a supply line delivers only so much flow at pressure, a drain carries away only so much, a fuel line and its air feed only so much combustion. On its own, each device stays under the ceiling. Run two at once and their combined demand can cross it. Nothing broke. The budget was simply exceeded, and the shared resource cannot serve both at the same moment. That is the whole mechanism, and once you see it you stop looking for a broken part that is not there.
The interaction patterns
| Shared resource | Combined-demand failure | Who tends to fail |
|---|---|---|
| Electrical circuit or service | Voltage sags under combined draw or a motor start | The voltage-sensitive device |
| Water supply line | Pressure and flow drop when both draw | The device needing a minimum inlet pressure |
| Drain or waste | Capacity exceeded, backs up or siphons a trap | The lowest or furthest fixture |
| Fuel or combustion air | Supply or air split too thin | The appliance that fires second |
| Shared structure or mount | Combined vibration or heat exceeds tolerance | The most sensitive nearby part |
Why the last or weakest actor fails
The resource does not fail evenly across everything on it. The marginal actor drops first: the device with the least headroom, the one furthest from the source, or the one that starts into a resource already loaded by the other. That is why the "victim" is so often blameless. It is not weaker in any absolute sense; it is just the one operating closest to the edge when the combined demand arrives. Chasing the victim is the classic wrong turn, because it tests fine every time you check it alone.
Read the shared node, not the two parts
The diagnostic move that cracks these faults: stop measuring the two devices and measure the shared resource itself, under combined load. Voltage at the panel or at the victim's terminals with both running. Flowing pressure at the fixture with the other draw open. Draft and combustion with both appliances firing. The number at the shared node under combined demand tells the story that a single-device test, taken in isolation, is built to hide.
Additive, not either-or
The trap is deciding one device is "the problem." Both are within spec. The fault is the sum of their demand against a fixed ceiling. That also opens up the fix, because you can relieve the interaction at either end: reduce one device's demand, stagger the two so they do not run together, or raise the resource's ceiling (a larger conductor, bigger pipe, a dedicated circuit, more combustion air). None of that is condemning a load. It is rebalancing demand against supply.
The design question underneath
Often the interaction is really a sizing decision that was never made. The shared resource was provisioned for one device, and a second was added later without anyone re-checking the total. Or two loads were installed at different times by different hands. When you find a two-load fault, ask whether the shared resource was ever sized for both together. If it was not, you are looking at a design limit, and the honest fix is a correction, not a part. Hand that off to the design-versus-fault decision.
References
- Trade-standard practice for systems-level and shared-resource diagnosis
- Manufacturer minimum-supply and capacity specifications (voltage, pressure, gas, combustion air)
- Applicable sizing codes for conductors, piping, drains, and venting
- See related: It Fails Only When Another Appliance Runs (Decision Tree); Patch the Symptom or Fix the Design (Decision Tree)