In ladder logic there are two ways to turn an output on. A normal coil follows its rung every scan, so it drops the moment the rung goes false. A latch instruction does something different: it sets a bit on and leaves it on, and only a separate unlatch instruction can turn it back off. This pair, written as OTL and OTU on Allen-Bradley platforms or set and reset elsewhere, is how a PLC remembers a decision instead of continuously re-deciding it every scan. Understanding when a bit should be latched, and the safety consequence of one that stays latched through a restart, is fundamental to writing control logic that behaves the way an operator expects.
Latch and unlatch instruction in one line: A latch instruction, often shown as OTL or set, turns an output bit on and holds it on across every future scan until a separate unlatch instruction, shown as OTU or reset, turns it off. Unlike a normal coil, which follows its rung every scan and drops as soon as the rung goes false, a latched bit is retentive and can survive a fault or a power cycle. That persistence is the whole point of the instruction and also its main hazard.
A normal output coil is a slave to its rung. Every scan the processor evaluates the contacts feeding the coil, and if the rung is true the coil is on, if it is false the coil is off. There is no memory involved. The instant the enabling condition disappears, the output disappears with it on the very next scan. That behavior is exactly what you want for something like a run indicator that should track a live condition moment to moment.
A latch instruction breaks that link deliberately. When its rung goes true, it writes the bit on and then stops caring about its own rung. Even if the rung immediately goes false again, the bit stays set. The only thing that turns it off is an unlatch instruction acting on the same bit, which forces it off and likewise leaves it off. In practice you write the two instructions on separate rungs: one rung with the start conditions driving the latch, and another rung with the stop conditions driving the unlatch. The bit lives in whatever state was last commanded.
This is close in behavior to the older habit of holding an output on by wiring one of its own contacts back around the start button, but the mechanism is not the same. That self-holding approach uses a normal coil that stays energized because the rung keeps evaluating true through the feedback contact, so cutting power drops it. A latch stores the bit's state as data, which is why on many processors it can be configured as retentive and survive events that would clear an ordinary coil. Knowing which mechanism you are looking at tells you how the output will behave after a power interruption.
The classic use is a pump or motor that a momentary start button must turn on and a momentary stop button must turn off. You cannot use a plain coil, because the start button springs back the instant the operator lets go and the coil would drop with it. So one rung latches the run bit when the start button is pressed and the permissives are satisfied, and a second rung unlatches the same run bit when the stop button is pressed or a fault appears. Between presses the run bit simply holds whatever it was last told.
The subtlety that trips people up is retentivity across a power cycle. On many controllers a latched bit is stored in retentive memory, which means it keeps its value when the PLC loses power and powers back up. So a pump that was running when the plant lost power can find its run bit still set on restart. Whether that is desirable depends entirely on the equipment. For a data flag it may be harmless; for a physical output driving a motor or valve it can be dangerous, because the machine may spring back to life the instant power returns with no operator command.
Because of that, well-written logic almost never lets a raw latched output come straight back on after a restart. A common discipline is to clear or re-evaluate latched physical outputs on the first scan after startup, forcing the operator to deliberately restart equipment rather than letting it resume on its own. Some programmers avoid latch instructions for motion-producing outputs entirely and use explicit run/stop logic with a normal coil so the behavior on power loss is unambiguous. The instruction is a tool, and its retentive nature is the thing you must consciously decide to keep or defeat.
The persistence of a latched bit becomes a real safety concern in emergency shutdown logic on unmanned sites. Consider an oilfield ESD scheme where a controller is supposed to hold a wellhead valve open during normal operation and drive it shut on a trip. If the open command is implemented as a latched output and that bit is retentive, a controller reboot can bring the valve back to its latched-open state before the trip conditions have been re-checked. The correct design de-energizes to a safe state on power loss and re-proves every permissive before allowing anything to reopen, rather than trusting a stored bit.
From a SCADA and remote-monitoring standpoint, latched bits are also what makes state visible across a slow or intermittent link. Because the bit holds its value, a cloud dashboard polling a remote site can read the current latched state at its own pace and still show the operator a correct picture of what is on and what is off, even if it missed the exact scan the change happened. The retained value is effectively the site's memory of its own decisions, which is why latch and unlatch bits are among the first status points an integrator maps to a remote display.
The operational risk to watch is a latched alarm or shutdown bit that stays set long after the underlying condition has cleared, leaving a remote operator looking at a trip that no longer reflects reality, or an inhibit that was never reset. Good practice pairs every latch with a clearly reachable unlatch path, an obvious reset action, and annunciation of anything that has been latched for an unusually long time, so a persistent bit is always something a human chose to keep rather than something the logic quietly forgot to clear.
OTE is a normal output that follows its rung every scan, so it turns off the moment the rung goes false. OTL latches the bit on and leaves it on regardless of its own rung, and only an OTU acting on the same bit will turn it off. Use OTE when the output should track a live condition, and OTL/OTU when the PLC needs to remember a decision between events.
On many controllers a latched bit is stored in retentive memory, so it keeps its value when the PLC loses power and comes back on. Whether that is safe depends on what the bit drives. Latched data flags are usually fine, but a latched physical output that can restart a motor or move a valve on power-up is a hazard, so good logic clears or re-proves those outputs on the first scan after startup.
Use a latch when a momentary input must produce a lasting result, such as a spring-return start button that has to keep a pump running after it is released. Use a normal coil when the output should mirror a live condition and drop as soon as that condition ends. For outputs that physically move equipment, many engineers prefer explicit run and stop logic over a raw latch so the power-loss behavior is unambiguous.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.