How to Read a Sequence of Operation as a Diagnostic

Why this matters

Most of the equipment a service shop meets has no written sequence of operation available on site. The submittal went to a general contractor who is out of business, the controller was reconfigured twice, and the manual in the door pocket is for a different model. Sibling articles cover using a sequence you have. This one is about the case that is actually normal: building one by watching the machine, and then using it without being fooled by it.

The load-bearing point, and everything below serves it: a sequence you derived by observation records what the machine did, never what it was supposed to do. The moment you let those two collapse into one document, you have written the fault down as the specification, and every tech after you will diagnose against it.

Set up the observation before you start anything

Watching a machine cycle means being beside it while it starts. Know what moves first, and dampers and actuators move before anything makes a noise. Stand clear of damper blades, linkages, belts, couplings and discharge openings for the whole cycle, and keep hands outside the guard line the entire time the machine is capable of starting. If something has to be reached, that is not an observation any more: isolate at the energy isolating device and lock and tag it under 29 CFR 1910.147 first, including any stored spring or pressure energy in an actuator.

Reading terminals live is permitted under 29 CFR 1910.333(a)(1) where de-energizing would introduce additional or increased hazards or is infeasible given the equipment design, and a sequence observation is the clearest example of the second, because a dead machine has no sequence. Use a test instrument rated to the highest voltage in that enclosure rather than to the control voltage you intend to read, because line-voltage terminals sit inches away. Where you move from reading to landing wires, that is 29 CFR 1910.333(b)(2), with live-dead-live proving per NFPA 70E-2021, 120.5.

Two tests below deliberately change conditions, so bound them now. A restart during fan coast-down is a normal thing to do to a fan and is not to be done on a refrigeration compressor, where restarting before pressures equalize is a recognised damage mode and the manufacturer's minimum off-time exists for that reason. And do not restrict airflow on any heating appliance to force a proving switch to change state: that is a fire hazard, not a controlled test.

Record transitions, not states

A sequence looks like a list of states. The diagnostic content is entirely in the transitions between them, because a transition is where a decision was made. For each one, you want three things: what ended the previous state, what began the next, and how long it took.

That means instrumenting the events rather than describing them. Clamp the loads you care about, put a meter on the input terminals that change, and run a clock. "The fan starts after the damper opens" is a sentence anyone can write. "The fan contactor pulled in 1.0 second after the damper end switch made, on all five runs" is a sequence line.

Deriving it: one cycle on an undocumented machine

A packaged unit, complaint of intermittent no-heat. Demand applied at elapsed zero, all events referenced to it, readings from a clamp on the load circuits and a meter on the terminal strip.

That is one run and it is not yet a sequence. Every interval in it could be a timer or a physical proof, and from outside the two look identical.

Separating a timer from a proof

This is the technique the rest of the method rests on, and it is portable to any machine. Repeat the cycle and vary the physical condition. An interval that stays fixed to within your measurement resolution is a timer. An interval that moves with the condition is a proof.

Zero to 2.0 s. Across three runs: 2.0, 2.0, 2.1 s. Fixed. A delay, either a deliberate one or a relay pickup.

Damper proof, elapsed from demand. Across the same runs plus a cold start the next morning: 34, 31, 36, 39 s. Note that these are absolute elapsed times from demand, not the actuator's own travel; the actuator does not begin driving until 2.0 s, so the travel itself is two seconds shorter in each case. Moves with condition. That is a genuine end switch reporting actuator travel, not a timed allowance.

Fan pull-in to airflow proof. Across three consecutive runs: 6.0, 5.8, 6.0 s. Fixed within resolution, which on its own is consistent with a 6-second timer and equally consistent with a fan whose spin-up is simply very repeatable. Consecutive runs cannot separate those two, so the condition has to be changed. The safe change here is a restart while the fan is still coasting, which on this machine put the airflow proof at 0.8 s after contactor pull-in. It moved with the condition, so it is a proof.

Stage 1 to stage 2. 59.5 s on the first run, then 60 and 60 on repeats, and still about 60 s on a much colder start where a demand-driven stage-up would have come sooner. Fixed against a large condition change, so it is a timer: this machine stages on elapsed time rather than on unmet demand. That single line changes how you would ever diagnose a capacity complaint on it.

What the derived sequence found

The complaint was intermittent, so the run count matters more than the detail of any one run. Four proofs made, at 34, 31, 36 and 39 s, and a fifth run that abandoned at 58 s with the proof never made at all; the cycle simply gave up and the demand input dropped. The 58 is an abort time, not a slow proof, and that distinction is the whole value of the series.

Read that series carefully rather than as a trend. The first four scatter between 31 and 39 s with no direction to them, and the fifth is far outside that spread. It is not a wear curve, it is an intermittent, which points at binding in the linkage or an actuator that stalls occasionally rather than one that has uniformly slowed. That distinction changes the repair: a binding linkage is found by hand-stroking the damper with the machine isolated and locked out, and a degrading actuator is not.

It also produced a number the machine never told anyone. There is a maximum wait on that damper proof, because the 58-second run aborted and the 39-second run did not. So the limit is above 39 s and at or below 58 s. That is a bound, not a value, and writing it down as a bound is the difference between a useful record and a fabricated one.

The three things a derived sequence cannot give you

Values you can only bound. The abort limit above is the example. You can narrow it by running more cycles, and you will never read it off the machine.

Anything the machine did not do while you watched. Alarm behaviour, safety trip response, what happens on power loss and restoration, a summer mode, a defrost, a purge, a lockout retry count. None of it appears in an observation of one normal cycle, and the absence of a line is not evidence that the behaviour does not exist.

Whether what you observed is correct. This is the one that matters. If that second heat stage coming on at a fixed 60 s is wrong for this application, your derived sequence has just recorded the fault and given it the authority of a document. Nothing inside an observation can tell you that an observation is of a healthy machine.

What to do about all three

Chase the real document once, properly, and then stop: the equipment manufacturer for the appliance-level sequence, the controller's own configuration printout or parameter list for the programmed part, and the controls contractor's submittal if the building has a record set. One focused hour usually settles whether a document exists at all, and it is worth spending before you build a large derived record.

Where it does not exist, mark it. Every derived line carries three tags: observed, the date, and the number of runs it rests on. A line built from one run and a line built from five are not the same quality of evidence and should not look the same on the page.

Then hold the two apart on the page itself. Two columns, observed and specified, with the source named for every specified line. The specified column starts almost empty and that is the honest state of it. The empty cells are not a gap in your work, they are the customer's punch list, and they are the argument for getting the controller's configuration exported before the next person has to derive it all again.

Handing it over

Leave the artifact on the machine, not only in the ticket. A printed page in the door pocket with the two columns, the run counts, and the date is worth more to the next tech than the same information filed under a job number they cannot search.

And write the bounds as bounds. "Damper proof abort limit: above 39 s, at or below 58 s, derived from 5 runs on this date" is a sentence a later tech can act on and can improve. A confident "45 s" invented to make the page look finished is the exact defect this whole article exists to prevent, and it will be quoted back as fact by somebody who was not there.

References

• 29 CFR 1910.147 for control of hazardous energy before any part of the equipment is reached into
• 29 CFR 1910.333(a)(1) for the conditions permitting energized troubleshooting, and 1910.333(b)(2) for de-energizing electrical circuits
• NFPA 70E-2021, 120.5 for establishing and verifying an electrically safe work condition
• See related: How to Read a Control Sequence of Operation; The Sequence of Operation as a Diagnostic Instrument; How a Permissive Chain Is Supposed to Work