What a Lockout Condition Means to the Equipment

Why this matters

A machine in lockout is usually described as broken. It is not broken. It is a machine that tried a bounded number of times, failed each time, and then made a deliberate decision to stop trying rather than keep attempting something it could not complete.

The claim: a lockout state carries three facts about the fault - which trial failed, how many attempts were permitted, and what will clear it - and calling the machine broken discards all three. Reading them is most of the diagnosis, and they are available before you touch anything.

The word collision that gets people hurt

This is the most important paragraph in the article. A control lockout is not a lockout/tagout. They share a word and share nothing else.

A machine sitting in control lockout is fully energized. Line voltage is present, control voltage is present, and the machine can leave that state on its own the moment a timer expires, a signal clears, or somebody presses a button in another room. Under 29 CFR 1910.147(b), an energy isolating device is a mechanical device that physically prevents the transmission of energy, and the definition expressly excludes push buttons, selector switches and other control circuit type devices. A controller's internal refusal to retry is further down that same road than a push button is: nothing has been isolated at all.

So before any work on a machine in control lockout, isolate it properly. Electrical work on utilization equipment is 29 CFR 1910.333(b)(2), with the live-dead-live proving sequence in NFPA 70E-2021, 120.5 against a known live source before and after. Mechanical isolation and stored energy, meaning a spring-return actuator, an accumulator, a pressurized line or a raised mass, is 29 CFR 1910.147, and 1910.147(a)(1)(ii)(C) is why those are two standards rather than one. On construction work the electrical counterpart is 29 CFR 1926.417.

And the second rule, which the rest of this article depends on: establish why the machine locked out before you clear it. A lockout entered because a protective device operated is a report about a real physical condition. Clearing it, or replacing the device that reported it, reaches the same end state as jumpering the device, one step slower and with a part on the invoice.

Three facts, available before you touch anything

Which trial failed. A lockout names a step. The controller entered lockout at a specific point in the sequence, and the code or the indicator tells you which. That is a location in the timeline, not a cause, but it is the strongest single piece of free information the machine gives you.

How many attempts were permitted. This is the retry budget, and it is published per control. Three trials before lockout is common; one is common on some functions; some controls permit more. The number matters because it tells you how many independent failures the machine observed before it gave up.

What will clear it. Whether the state clears on a power interruption, on a demand cycle, on a timer, or only on a deliberate manual reset. This determines how much evidence still exists and how much has already been destroyed, and it varies more between controls than most people expect.

The retry budget, and why it is bounded

Retrying is not free. Every attempt consumes something: a start on a driven load, an operation of a switching device, an unburned quantity of whatever the machine handles, a thermal cycle. An unbounded retry turns a small fault into a large one overnight, so the designer picks a number that gives a genuinely marginal condition a second chance without letting a real fault repeat forever.

That means the budget itself is diagnostic. A machine that locked out on the LAST permitted trial observed the failure that many times in a row. A machine that locked out on the FIRST attempt is on a function where the designer decided even one failure is not retryable, which is usually a function with a safety consequence, and that distinction should change how you approach it.

What lockout does not do

The negatives are where the misunderstandings live, and each has a field consequence.

It does not de-energize. Covered above, and it is the one that matters.

It does not isolate the fault. The step it names is the step that could not complete, which is frequently downstream of the actual cause. An output that could not prove is a failure at the output's step whether the cause is the output, the proving device, or a permissive that dropped when the output loaded the circuit. The sibling article on establishing where in the sequence it stopped separates those.

It does not diagnose. The controller applied a rule and reported the outcome. It has no model of the machine.

It does not necessarily persist. This is the one that costs the most evidence. Some controls hold lockout until a manual reset. Others clear on any power interruption, so an outage, a customer flipping the disconnect, or a tech switching the machine off to look at something all wipe the state. And some enter a soft lockout that clears itself after a set interval and retries automatically.

Soft lockout is why "it works sometimes" gets reported

A control that self-clears after a fixed interval and retries produces a machine that is, from the customer's side, intermittent. It is not intermittent. It is failing every attempt and being re-armed on a schedule.

Take a control with a 3-trial budget and a soft lockout that auto-retries after 60 minutes. Over a full day of continuous demand that is up to 24 re-arms, and each re-arm spends the full budget before locking out again. So 24 x 3 = 72 failed trials in 24 hours, on a machine the customer describes as working occasionally.

The counters settle it, and this is a different reading from the cycle-length analysis its sibling article uses. Compare the trial or attempt counter against the run-hour counter over a known interval. A trial counter climbing at tens per day while run hours barely move means the machine is trying constantly and completing nothing. Run hours moving normally alongside a climbing trial counter means it is failing some attempts and succeeding at others, which is a genuinely intermittent condition and a different investigation.

Reading a lockout state as three facts

Two machines, same control family, same displayed lockout, opposite fault classes. The retry budget is 3 trials on both.

Machine one. Lockout reached within a single demand cycle: three trials, back to back, inside a few minutes. The condition that defeated trial one was still there for trials two and three. That is a persistent condition, present continuously, and it will be present while you stand there. Diagnose it live.

Machine two. Lockout reached after three trials spread across three separate demand cycles over two days, on a control that accumulates failed trials across cycles within a window rather than resetting the count at each new demand. Between those trials the machine started and ran normally. That is an intermittent condition and it will almost certainly not be present while you stand there, so live diagnosis is the wrong tool and a logged or witnessed reproduction is the right one.

The two are indistinguishable on the display. They are cleanly distinguishable from the trial counter and the run-hour counter read together, provided you know whether that control accumulates across cycles or resets each demand, which is published and is worth confirming rather than assuming. Getting that one property backwards inverts the conclusion, which is why it is the first thing to look up rather than the last.

What this changes about the visit. Machine one is a same-visit diagnosis. Machine two is a visit to instrument and leave, and promising the customer a fix today is a promise you will break. Making that call from the counters, at the start, is worth more than any single measurement you would otherwise spend the hour on.

The failure mode. The common wrong path is to clear machine two's lockout, watch it start and run correctly, and hand it back as no fault found. It was always going to start; that is what the record already said. The visit ends with the evidence destroyed and the customer's confidence spent, and the sibling article on clearing a lockout without losing the evidence exists because this is the most common way a controls call is wasted.

Before you clear it

Clearing destroys the state in a fixed order, and the sequence for capturing it is its own procedure, which the companion HowTo carries. The one rule to hold here: the lockout state is evidence, the clear is irreversible, and it is the last diagnostic step rather than the first.

If the equipment has to be returned to service before you can investigate, capture the three facts in writing first, along with the counters and the time, because a machine handed back running and locked out again next week is a machine whose only useful record is the one you took today.

References

• 29 CFR 1910.147, including the definition of an energy isolating device at 1910.147(b), which excludes control circuit type devices, and 1910.147(a)(1)(ii)(C), which separates electrical work from the hazardous energy standard
• 29 CFR 1910.333(b)(2) for de-energizing and lockout of electrical circuits, and 29 CFR 1926.417 for lockout and tagging of circuits on construction work
• NFPA 70E-2021, 120.5 for live-dead-live verification of a de-energized state
• Manufacturer control documentation for the retry budget, whether failed trials accumulate across demand cycles, and what clears a lockout on that specific control
• See related: How to Clear a Lockout Without Losing the Evidence; What a Lockout Count Tells You That a Single Visit Can't; What a Manual Reset Is Telling You