What a Sequence Tells You That a Wiring Diagram Cannot

Why this matters

A tech with the wiring diagram open and a machine that stops partway through can spend an hour ringing out a circuit that turns out to be electrically perfect. The diagram was not wrong. The readings were not wrong. The question was wrong for the document.

The claim this article rests on: a wiring diagram is a complete statement of what is connected and a total silence on when anything is supposed to happen. Any question containing "when", "before", "how long", or "why not yet" sits outside what a diagram can answer, and no amount of continuity testing converts one kind of question into the other.

Before you open a panel to compare the two documents

Opening an enclosure to trace a control circuit means de-energizing and locking out under 29 CFR 1910.333(b)(2), then proving dead with the live-dead-live sequence in NFPA 70E-2021, 120.5 on a known live source before and after. On a construction site the electrical lockout counterpart is 29 CFR 1926.417. Note the fork: 1910.147 covers mechanical isolation and stored energy, and at 1910.147(a)(1)(ii)(C) it expressly excludes exposure to electrical hazards from work on electric utilization equipment, so a panel is a Subpart S job.

Where the comparison genuinely requires the circuit live, 29 CFR 1910.333(a)(1) permits energized work only where de-energizing would introduce additional or increased hazards or is infeasible given the equipment design, which a running-sequence observation usually satisfies. Use a meter whose measurement category rating matches the location and whose voltage rating is at or above the system voltage, inspect the leads and probes for damage before the first reading as 29 CFR 1910.334(c) requires, and wear the shock and arc-rated protection the task calls for under 29 CFR 1910.335(a). Keep the enclosure door in its normal position and read at accessible test points rather than reaching past energized bus.

What the diagram owns outright

This is the half of the split that gets forgotten, and reaching past it wastes exactly as much time as reaching past the sequence does. For these questions the diagram is the fastest document on the truck and the sequence is useless:

• Wire identity and terminal designation. Which wire lands where, what it is marked, what colour convention the builder used.
• Topology. What is in series with what, what is parallel, what is common, what is switched.
• Device inventory. How many contacts a given device carries and which of them appear in which circuit.
• The line-voltage and control-voltage boundary, and where the transformer sits across it.
• Grounding and bonding paths, which no sequence of operation ever describes.

If your question is "is this switch in the path to that coil" or "which terminal does the sensor common land on", open the diagram, answer it in a minute, and close it.

The three things a diagram structurally cannot hold

Order. A diagram draws every contact at once. It has no way to say that one closes before another. Two contacts in series look identical on paper whether the first closes at second zero and the second at second forty, or the other way around, and the difference is often the whole diagnosis.

Elapsed time. No diagram carries a duration. A timer relay appears as a coil and a contact with a symbol indicating delay-on or delay-off, but the delay VALUE and what it is waiting for live only in the sequence, and sometimes only in the controller's parameter list.

Conditionality, meaning which inputs the controller is even watching right now. This is the one that catches experienced people. On a machine where a programmable controller reads the inputs and drives the outputs, a contact you can see in the field wiring is only a permissive during the windows the program chooses to evaluate it. Drawn in series with an output, it looks like an unconditional requirement. In the program it may be ignored for the first thirty seconds after a start command, deliberately, so that a device that has not yet had time to respond does not fault the machine.

"In series with" is not "required by then"

Take those two ideas together and you get the specific trap. A field wiring diagram showing a proving switch in series with an output device supports the reading: this output cannot energize unless that switch is closed. That reading is true and incomplete. What it omits is WHEN the controller starts caring, and what the controller does about a switch that is closed too early.

Many sequences check a proving input in both directions: it must be OPEN before the start command, to demonstrate that the input is capable of changing state and is not stuck closed or jumpered, and then CLOSED within a stated window after the driving device is commanded. A switch stuck closed passes the series test on the diagram perfectly and fails the sequence at the first gate, before anything has run. You cannot get there from the diagram, because "must be open first" is not a topology fact.

The worked example: one machine, two documents, one question

A packaged machine with an air-moving device, an airflow proving switch, a purge period, and an output device that is the actual work being done. The complaint is that the output device never energizes.

The written sequence, converted to a timeline from the start command at t = 0 seconds:

Observed on site: the machine takes the start command, the air-moving device runs, and everything stops at about t = 12 seconds.

The diagram, read alone, offers the honest answer that the proving switch is in series with the output and could be the cause. That answer sends a tech to test the proving switch, find it works, and lose the hour.

The sequence places t = 12 seconds inside the purge window, 28 seconds before the output was ever going to be commanded. The proving input demonstrably made it to closed, because the controller advanced past the t = 10 gate. So the fault is a proving input that closed and then re-opened during purge, which is a different fault entirely from one that never closed. That points at a marginal airflow condition, a switch set near its actuation point, or a duct or damper condition that changes a few seconds after the air-moving device comes up to speed, and it points AWAY from wiring, contacts, and continuity.

The failure mode of skipping the sequence here is specific and common: the tech concludes the proving switch is defective because it is the only device in the path they can reach, replaces it, and the new one behaves the same way because it was never the fault. That outcome is worth naming plainly, because it lands in the same place as jumpering the switch would have, one step slower and with a part on the invoice. A proving device that has operated is telling you a physical condition went away. Establish WHY it opened before you treat the device as the fault.

One condition that would change the reading: if the observed stop had landed before t = 10 seconds, the timeline would not distinguish "switch never closed" from "air never moved", because both fail the same gate. The 12-second observation is only diagnostic because it sits past a gate the machine had to pass. Timing an event to the second, with a stopwatch, is what makes that distinction available, and estimating it as "about ten seconds" destroys it.

What a sequence cannot give you either

The symmetry matters, because a reader who takes only the first half of this article will over-trust the sequence next time:

• No terminal numbers, no wire markings, no colours.
• No statement of which physical device implements a named step. "Proves airflow" does not tell you there are two switches in series.
• No guarantee that the installed machine matches the written text. A sequence is a design document, and the reconciliation between written and installed behaviour is its own job, covered in the sibling articles on reading and deriving a sequence.
• Nothing about fault current, grounding, or conductor sizing.

Picking the document from the shape of the question

The middle rows are where the hours go. If you cannot answer a timing question from the documents you have, the honest move is to derive the timeline by timing the transitions across one full cycle rather than to keep re-reading the diagram harder. Do that from a position outside the swept path of every rotating or driven part with all guards in place and the enclosure closed, clear of the flue and relief-opening path, and with a personal CO monitor on your collar before a fuel-burning machine fires. Nothing about a timing observation requires you to be inside the machine, and the machine will start and stop without warning while you are watching it.

How to verify you got this right

Take a machine you already understand and try to state, from the diagram alone, the answer to three questions: which of two series contacts closes first, how many seconds the controller waits for a proving input, and whether any input is required to be open before start. If you can answer any of the three from the diagram, you are reading something into it that is not there, usually from memory of similar equipment, and that inference is where a wrong diagnosis enters.

Then run the reverse check on the sequence: try to find, in the sequence text alone, the terminal a given sensor lands on. When you cannot, you have located the boundary correctly and you will stop asking either document to do the other's work.

References

• 29 CFR 1910.333(b)(2) for de-energizing and lockout of electrical circuits, 29 CFR 1910.333(a)(1) for the conditions permitting energized troubleshooting, 29 CFR 1910.334(c) for inspection of test instruments and leads, and 29 CFR 1910.335(a) for electrical protective equipment
• 29 CFR 1926.417 for lockout and tagging of circuits on construction work, and 29 CFR 1910.147(a)(1)(ii)(C) for the exclusion that separates electrical work from the general hazardous-energy standard
• NFPA 70E-2021, 120.5 for the live-dead-live verification sequence
• Manufacturer installation and service documentation for the controller's parameter list, where delay values and input-evaluation windows are usually published
• See related: How to Read a Control Sequence of Operation; The Sequence of Operation as a Diagnostic Instrument; What Proving Actually Means in a Sequence