PLC Latching: Seal-In, Set/Reset and Held-Input Tests

PLC latching stores a state after the condition that established it has changed. A useful latch design specifies what sets the state, what clears it, which condition wins when both occur, and what happens during initialisation or a skipped execution.

This tutorial compares seal-in memory, separate set and reset assignments, and set-priority versus reset-priority blocks. It then develops a fictional fault-memory model that requires a fresh reset request after the fault clears. The worked examples distinguish a present condition, its remembered history and an operator acknowledgement.

For South African PLC learners, the objective is to predict the state on each evaluation and retain evidence for simultaneous and held-input cases. These are software learning models. A Boolean memory example is not a validated motor circuit, protective function or machine restart design.

Name the state before choosing a latch instruction

Begin with a sentence describing what the bit means. “Run request accepted” differs from “motor feedback present”. “Fault has occurred” differs from “fault is active now”. A bit called Latch without a defined meaning invites different readers to assume different reset behaviour.

For each state, record its owner, initial value, set condition, reset condition and simultaneous-input priority. Also identify whether the state is recalculated every evaluation or changed only by particular executed assignments.

These states can be related without being the same variable. Acknowledging an event need not remove an active condition, and clearing fault memory need not issue a run request. Keep those distinctions in the interface and the test record.

The alarm detection and priority guide provides context for separating the measured condition from its presentation to the operator. Decide the meaning first, then select instructions that implement it.

Separate a program test from a physical contact description

In Boolean logic, testing a variable directly gives its value; testing its negation gives the opposite value. That relationship is independent of the physical contact arrangement that may have produced the variable.

For a fictional input called StopActive, true means the stop condition is asserted. The run-memory equation therefore uses NOT StopActive. For another input called StopPermission, true would instead mean permission is present, so the equation could test StopPermission directly.

Do not silently change between those meanings while explaining a rung. Write the input semantics next to the program example and use the same convention in every test row. A contact symbol alone does not explain the field circuit, diagnostic coverage or machine response.

The ladder-logic basics tutorial develops Boolean contact interpretation. When studying an actual installation, use its drawings and equipment documentation to establish what the input represents; a generic tutorial cannot establish physical safety from a normally-open or normally-closed label.

02

Describe seal-in memory as a next-state equation

Use a virtual run-memory bit, initially false. On every evaluation, calculate the next value as Permission AND NOT StopActive AND the result of Start OR OldRunMemory. Then store that next value as RunMemory.

The Start input can establish the state, and the old state can maintain it after Start becomes false. Either a false Permission or a true StopActive clears it in this specific equation. The permission and stop conditions apply to the whole memory path.

RunMemoryNext = Permission AND NOT StopActive
               AND (Start OR RunMemoryOld)

This equation is clearer than an ambiguous sketch whose contact meaning changes halfway through the explanation. It also makes a limitation visible: a held Start can establish the memory again when Permission returns.

The fourth row is a restart of the virtual memory without a fresh Start transition. Therefore the basic equation must not be described as inherently requiring a new button press after every interruption. Whether that behaviour is acceptable depends on the declared task.

Define a fresh-request policy separately

If the learning requirement is a fresh Start transition, add an explicit raw-input history. StartEdge is true only when Start is true and its previous sampled value was false. Update that previous value every evaluation, including while permission is absent.

Initialise the previous value to the current Start input so a held Start at initialisation is not treated as a new request. Clear RunMemory when StopActive is true or Permission is false; otherwise set or maintain it from StartEdge OR OldRunMemory.

Under the six-row sequence above, this version remains false at row four because Start never returned false after the earlier press. Its outputs are zero, one, zero, zero, zero, zero. The distinction is an explicit policy change, not a different name for the same seal-in equation.

A Start transition observed while Permission is false is consumed in this model rather than queued for later. If a task requires a queued request, that is another state and another set of tests. The start-stop exercise provides more detailed practice with these distinctions.

03

Understand separate latch and unlatch assignments

Rockwell's Output Latch instruction reference describes setting the addressed Boolean when its rung condition is true and leaving it unchanged when that condition is false. Its Output Unlatch reference describes clearing the bit when its rung condition is true.

These are separate writes to a stored value. In an explicitly ordered learning example, an executed set assignment followed by an executed reset assignment leaves false. Reversing those two assignments leaves true. This conclusion assumes that both execute and no other writer intervenes.

A consumer placed between the two assignments can observe a different state from a consumer after both. When investigating a latch, record execution order and observation point rather than using “the bit is on” as a timeless statement.

Search for every writer, including initialisation, indirect access or writes to a containing structure. An absent matching unlatch instruction does not alone prove a bug: another deliberate assignment may clear the state. The relevant question is whether a reachable, specified clearing path exists.

Compare set-priority and reset-priority explicitly

The CODESYS SR reference documents set-dominant behaviour. The CODESYS RS reference documents reset-dominant behaviour. Verify actual pin names and library definitions when implementing either block.

For the independent Boolean comparison, set-priority means Set OR (OldQ AND NOT Reset). Reset-priority means NOT Reset AND (Set OR OldQ). Their outputs differ when Set and Reset are both true.

Test the table with OldQ initially false and initially true. Choosing priority is part of defining the state; it is not a universal rule that one block is always preferable. A fault memory that must preserve an active condition has a different contract from a resettable demonstration bit.

The function block diagram tutorial adds instance-isolation tests. Two named devices need independent state when their memories are intended to evolve separately.

04

Show why a rising-edge set can still lose a fault

Consider a flawed learning design: detect the rising edge of FaultActive, feed that pulse into a reset-priority memory element, and use the level of ResetButton as reset. Initialise the fault-edge history false and the memory false.

Use three evaluations. First, FaultActive is false and ResetButton is held true. Second, FaultActive becomes true while ResetButton remains true. Third, FaultActive remains true while ResetButton becomes false.

At the second evaluation, reset priority discards the only set pulse. At the third, releasing reset does not recreate that pulse because the fault is still active. The memory stays false despite the active fault.

Edge detection did not repair the priority conflict. The design needs a different contract for retaining the fault and accepting reset. Telling an operator not to hold a button does not change the Boolean result of this test.

Build a fault memory that clears only after the condition clears

The replacement learning model has FaultActive, ResetButton, stored FaultMemory and stored PreviousReset. Initialise FaultMemory false and PreviousReset to the current ResetButton value. A held reset at startup therefore creates no initial reset edge.

On each evaluation, calculate ResetEdge as ResetButton AND NOT PreviousReset. Then calculate FaultMemoryNext as FaultActive OR the result of OldFaultMemory AND NOT ResetEdge. Store the new memory and update PreviousReset from the raw button value every evaluation.

ResetEdge = ResetButton AND NOT PreviousReset
FaultMemoryNext = FaultActive OR (FaultMemoryOld AND NOT ResetEdge)
PreviousResetNext = ResetButton

FaultActive has priority. A reset edge cannot clear memory while the fault is active. Once the fault clears, the memory remains until a fresh reset edge occurs. A button already held through fault clearance is not a fresh request.

This model remembers a supplied fault condition; it does not define the condition's physical detection or command any equipment. If the supplied condition's quality is uncertain, a separate validity and response policy is required rather than pretending uncertainty means no fault.

Replay held reset, clearance and a new reset request

Start with ResetButton already true at initialisation. The following ten-row trace includes a new fault while reset is held, a valid clearing request, and a reset pressed while the condition remains active.

Row two captures the fault even though reset is held. Row three retains its memory after the condition clears. Releasing and pressing reset produces the accepted edge in row five.

Row seven cannot clear an active fault. When the condition clears in row eight, that earlier reset press is not reused. A new release and press clears the remembered event in row ten. Also test a fault becoming active on the same evaluation as a fresh reset edge: the active condition must win.

05

Keep acknowledgement separate from fault-memory reset

Acknowledgement records an operator interaction with an event or alarm. Fault-memory reset changes a stored application state under its specified conditions. They can be separate actions with different permitted timing.

An operator may acknowledge an active alarm while its condition remains true. That does not require clearing the active condition or the fault memory. Conversely, a condition can return to normal before an operator acknowledges its recorded event.

The first-fault annunciator exercise develops event memory and acknowledgement separately. Do not replace that richer behaviour with a single bit that simultaneously means active fault, unseen event and permission to run.

Names on the HMI should reflect the actual action. A control labelled Acknowledge should not silently clear an unrelated run inhibition simply because both operations were connected to the same latch reset input.

Distinguish latching across evaluations from restart retention

A memory bit can remain true between normal evaluations without any promise about power loss, a controller reset, a download or application replacement. Those are separate lifecycle events with platform-specific behaviour.

For a learning project, declare the startup state explicitly. For the fault-memory model here, memory starts false but an active FaultActive input sets it on the first evaluation. Initialising PreviousReset from the current button prevents a held button from becoming an artificial reset request.

For a native project, document the intended outcome for each lifecycle event and verify the actual controller and configuration. Avoid assuming that an instruction name establishes retention, or that every family provides a universal Retain checkbox or the same first-scan flag.

A test record can distinguish ordinary stop-and-resume, a supported restart, and reloading an initial fixture. State what was performed and observed. Do not report a simulated initialisation as evidence of hardware power-cycle behaviour.

Investigate a latch that appears stuck

First identify whether the stored value is actually unchanged or whether the screen is displaying stale or differently bound data. Then identify the state owner, all executed writers and the reset condition at the relevant evaluation.

A reset condition that never becomes true differs from a reset assignment that is skipped. A state cleared and then set again by a later writer differs from a state that never cleared. Capture intermediate observations when execution order is relevant.

The HMI binding guide helps check what the display represents, while the PLC troubleshooting tutorial provides an evidence-based investigation structure. Retain the initial state and exact input sequence so another learner can reproduce the apparent fault.

In software practice, change one cause at a time and repeat the failing sequence. Then test simultaneous inputs and held requests. A correction that works only after releasing every input may not address the original failure.

06

Practise the models with reviewable evidence

Use the scan-cycle highlighting feature for related program-observation practice. Compare the observed value before and after the relevant logic executes, within the supported exercise.

The PLC alarm-management learning page is a companion for distinguishing condition, acknowledgement and history. Confirm the actual supported behaviour rather than assuming that every native latch block or controller lifecycle is emulated.

Keep the six-row run-memory comparison, the set/reset ordering example, both priority tables, the three-row lost-fault counterexample and the ten-row replacement trace. The Boolean calculations were independently checked in software; this is separate from native compilation or physical validation.

Ask a reviewer to explain why each unexpected-looking result occurs. The fourth-row seal-in restart and the second-row lost fault are especially useful because both expose an incorrect verbal explanation of otherwise simple logic.

Choose South African latching training by the test cases

When comparing PLC courses in Johannesburg, Pretoria, Durban, Cape Town or another South African location, ask whether learners test simultaneous set and reset, held buttons, startup inputs and multiple writers. Request individual feedback on the predicted state sequence.

Confirm the actual software, controller family, access arrangements and assessment format. The South African PLC training guide supports comparing those details. These city references describe training-search contexts and do not imply branches operated by this website.

A useful assessment requires the learner to state what the bit means and when it may clear. Recognising an SR or RS symbol is helpful, but the stronger evidence is a correct explanation of the entire state contract.

Why does a latch return immediately after reset?

Check whether its set condition remains true and whether a later assignment writes it again. The behaviour may follow the implemented priority exactly. Compare the state definition with the executed sequence before changing instructions.

Does a seal-in always prevent automatic restart?

No. The basic model restarts when Start is held and permission returns. A fresh-request requirement needs explicit input-history or rearming logic, with the held-input case included in verification.

Should every latch use a one-shot on its set input?

No. Choose level or event semantics from the state definition. The flawed edge-set example loses a fault under held reset; the replacement fault memory deliberately uses the active fault level with priority over reset.

What proves that my latch implementation is correct?

Evidence must match its specified initialisation, set and reset rules, simultaneous priority, execution order and lifecycle scope. Keep expected and observed traces, including cases that should not clear or restart the state.