A latch has two inputs, one that turns it on and one that turns it off, and most of the time only one of them is active. But what happens on the scan when both the set condition and the reset condition are true at the same instant? The answer is not left to chance; it is decided by which input is defined to win, and that choice is the difference between a set-dominant and a reset-dominant latch. Getting that priority right is trivial in normal operation and critical in shutdown logic, where a live trip must never be overpowered by a start command.
Set-dominant vs reset-dominant latch in one line: A set-dominant latch, often labelled SR, turns its output on when set and reset are true at the same time, so set wins the tie. A reset-dominant latch, labelled RS, turns its output off in that same situation, so reset wins. The two behave identically whenever only one input is active and differ only on the scan when both are true, which is exactly the moment that matters most in trip and shutdown logic.
A basic latch remembers its state: a set input turns it on, a reset input turns it off, and it holds in between. The ambiguity only appears when set and reset are asserted in the same scan. With no rule, the outcome would depend on incidental details of how the logic happened to be written, which is unacceptable in control code. Dominance is the rule that removes the ambiguity by declaring, up front, which input takes priority when the two conflict.
In a set-dominant block, commonly drawn as an SR function block, set has priority. If both inputs are high, the output goes to one, meaning on. Read it as start wins. In a reset-dominant block, drawn as RS, reset has priority. If both inputs are high, the output goes to zero, meaning off. Read it as stop wins. The letter order in the name tells you the dominant input: the last-listed input is the one that wins in most conventions, which is why RS is reset-dominant and SR is set-dominant, though it is always worth confirming against the specific platform's documentation.
In plain ladder logic, without a dedicated function block, the same idea is encoded by rung order. Because the processor scans top to bottom and the last write to a bit before the output is used is what sticks, the instruction placed later in the scan effectively dominates. If you latch a bit on one rung and unlatch it on a rung below, the unlatch is evaluated last and therefore wins any tie, giving you reset-dominant behavior. Swap the order and you get set-dominant. The dominance is real and physical even when no function block names it, so the rung order is not cosmetic.
For anything that can shut equipment down, reset-dominant is almost always the correct choice, and the reasoning is about failure direction. A trip or shutdown condition is a demand to stop, and it must be honored no matter what else is happening. If an operator is holding a start command, or a start pulse arrives, in the same scan that a genuine trip fires, the safe outcome is unambiguous: the equipment stays down. A reset-dominant latch guarantees that, because reset wins the tie and the output goes off.
A set-dominant latch in the same situation does the opposite. If someone is asking the machine to start at the very moment a protective condition is demanding it stop, set-dominant lets the start win, and the equipment runs into the fault. That is precisely the scenario that a shutdown system exists to prevent, so choosing set-dominant for a trip effectively hands the tie to the wrong side. The tie may seem like a rare edge case, but shutdowns are exactly where rare edge cases turn into incidents, and a start command sitting active while a trip arrives is not far-fetched at all.
The practical rule engineers carry is simple. Model a shutdown or trip latch as reset-dominant so a live trip always overrides a start, and reserve set-dominant for the handful of cases where you genuinely want an on command to prevail, such as latching an alarm annunciator that should light on any occurrence regardless of an in-progress acknowledge. When in doubt on protective logic, reset wins. The whole discipline of fail-to-safe control leans in the direction of stop having the final word.
Consider the run permissive latch for a well or a compressor on a remote site. The set condition is the operator's start command with all permissives met. The reset condition is any active trip: high pressure, low lube oil, an ESD pushbutton, or a communications-loss shutdown. During a startup the operator may press start repeatedly, or a start command may be latched at the console, precisely while conditions are still stabilizing and a protective setpoint could momentarily be exceeded. If the run latch is reset-dominant, a trip in that window drops the run bit even with start held, and the unit stays safely down.
Now suppose someone built that same latch set-dominant, perhaps by placing the latch rung below the unlatch rung without thinking about scan order. On the scan where the operator's start command and a high-pressure trip are both true, set wins. The run bit stays on. The ESD has effectively been defeated by a start command, not by any wiring fault, but by a one-word choice about which input dominates. The unit continues into a condition the trip was supposed to stop, and nobody looking at the logic casually would spot why.
This class of error is quiet because it is invisible until the exact coincidence occurs, and in remote and SCADA-monitored operations that coincidence can happen at three in the morning with no one on site. It rarely shows up in a normal function test that presses one button at a time, which is why review of protective latches specifically checks the both-inputs-true case and confirms it lands on stop. When you review shutdown logic, deliberately ask what happens when set and reset are both true, and make sure the answer is the safe one.
For trip and shutdown logic, reset-dominant is safer because a live trip must always beat a start command when both are true in the same scan. Reset-dominant sends the output to off in that tie, keeping equipment down. Set-dominant is only appropriate where you specifically want an on command to win, such as certain alarm-latch cases.
The processor scans top to bottom, and the last write to a bit before it is used is the one that sticks. If the unlatch rung is placed below the latch rung, the unlatch is evaluated last and wins any tie, giving reset-dominant behavior. Putting the latch below the unlatch makes it set-dominant, so the physical order of the rungs is what determines the priority.
SR and RS name latch function blocks by which input dominates. In common conventions the last letter is the dominant input, so SR is set-dominant, meaning set wins when both are true, and RS is reset-dominant, meaning reset wins. Because naming conventions vary between platforms, always confirm the behavior against the specific controller's documentation rather than assuming.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.