IEC Set Reset Flip Flop: SR, RS and Priority Rules

An IEC set reset flip flop stores a Boolean state between evaluations. A set request makes the state true, a reset request makes it false, and the design must specify which request wins when both are true. That simultaneous-input rule is called dominance or priority. It should be verified from the actual instruction, not guessed from the order of two letters.

The naming difference matters: the cited CODESYS Standard library calls its set-dominant block SR and its reset-dominant block RS. Siemens' cited STEP 7 V21 bit instructions use SR for reset priority and RS for set priority. A migration that copies the mnemonic without checking the truth table can therefore reverse the intended conflict result.

This South African learning reference uses a fictional notification flag to explain state, priority and reset behaviour. It is not an emergency-stop circuit or a machine restart design. This site has a commercial connection to PLC Simulator; educational practice does not establish a safety function or native controller verification. The illustrations are conceptual study scenes.

Specify the stored state before choosing a block

Name what true means. “An unread notification is pending” is clear enough to test. “Latch” alone does not identify whether the bit represents a request, an active condition, an acknowledgement or permission for another action. Those meanings can require different reset conditions even when their implementation uses the same Boolean operation.

For the teaching model, S is a request to set the stored state Q and R is a request to clear it. Each evaluation reads S, R and the old Q, then produces the new Q. When S and R are both false, the old state is retained. This persistence between evaluations is the memory property being studied.

A set-dominant model uses NewQ = S OR (OldQ AND NOT R). A reset-dominant model uses NewQ = NOT R AND (OldQ OR S). These are model equations using generic names, not a universal native call declaration. They make the simultaneous-input behaviour explicit.

S	R	Set-dominant result	Reset-dominant result
False	False	Old Q	Old Q
True	False	True	True
False	True	False	False
True	True	True	False

Test the hold row with both old states. A model that always returns false when both inputs are false is ordinary combinational logic, not the intended stored-state behaviour. Also test the conflict row from both old states; dominance determines its result independently of the old Q.

Beckhoff publishes the corresponding Boolean implementations for its Tc2_Standard SR block and RS block. The complete input truth table is a better portability check than a diagram label alone.

Map native names and parameter meanings carefully

The following table describes the particular documented implementations linked here. It is not a claim that every library using SR or RS has an identical interface, initialisation rule or storage mechanism. Inspect the actual instruction selected in the project.

Documented implementation	Set-priority form	Reset-priority form
CODESYS Standard 3.5.18	SR, SET1 and RESET	RS, SET and RESET1
Beckhoff Tc2_Standard	SR, SET1 and RESET	RS, SET and RESET1
Siemens STEP 7 V21 cited bit instructions	RS, R and S1	SR, S and R1

CODESYS documents SR as set dominant with Q1 output and RS as reset dominant with Q1 output. Its example parameter names differ from the generic S and R notation used in this article. Use the CODESYS SR reference and CODESYS RS reference when writing calls for that library version.

Siemens' V21 SR documentation explicitly gives R1 priority over S. With both inputs true, the specified operand is cleared. Its RS documentation instead gives S1 priority over R, setting the operand when both are true. Check the Siemens SR instruction and Siemens RS instruction.

When reviewing a converted project, record the required conflict result beside the native block and test it. Renaming a tag from SR to RS does not prove that its implementation changed. Conversely, a changed mnemonic can preserve the intended behaviour when the destination platform names its blocks differently.

02

Worked notification example: a new event races with clear

Define a fictional display flag called Pending. True means there is a notification the exercise still considers pending. NewEvent requests that Pending be set; ClearEvent requests that it be cleared. Both requests are supplied as accepted events for this exercise, and the initial Pending value is false.

Policy A gives a new event priority. If NewEvent and ClearEvent arrive together, Pending remains true so the new notification is represented. Policy B gives clearing priority and ends that evaluation with Pending false. Either policy can be implemented mathematically, but the product requirement must choose deliberately.

Evaluation	NewEvent	ClearEvent	Policy A: new event wins	Policy B: clear wins
1	False	False	False	False
2	True	False	True	True
3	False	False	True	True
4	True	True	True	False
5	False	False	True	False
6	False	True	False	False

Evaluation 4 is the decisive conflict case. Evaluation 5 shows its lasting consequence: with neither request active, each policy keeps its own previous result. Testing only separate set and clear requests would miss the difference.

This example stores whether something is pending, not how many events occurred. Two new events before a clear still produce only one true Boolean state. If the application needs an event count, identities or a queue, a single latch cannot preserve that information.

Also decide what the clear request refers to. Clearing all pending work differs from acknowledging one displayed record. If a user clears an older notification while a newer one arrives, a record identifier may be more appropriate than one shared clear bit. The simple model deliberately does not solve that broader message-handling problem.

Use descriptive names in the worksheet, such as NewEventWins, rather than relying solely on a platform-specific block name. A reviewer can then compare the selected native instruction against the intended policy without assuming the same naming convention.

A held set request can reassert after reset

Reset priority answers what happens while reset is true. It does not necessarily require the set input to return false before another set can occur. This distinction is visible in a three-step sequence using the reset-dominant teaching equation.

Start from Q false. With S true and R false, Q becomes true. Keep S true and make R true: reset wins and Q becomes false. Now release R while leaving S true: Q becomes true again. No new rising edge of S was needed by this level-evaluated model.

Evaluation	S	R	Reset-dominant Q
1	True	False	True
2	True	True	False
3	True	False	True

If the requirement is a fresh request after clearing, specify the rearming or event-acceptance rule separately. Changing the dominance mnemonic alone does not add that rule. Test held requests, request release and a subsequent new request as distinct cases.

An event pulse and an active condition have different meanings here. NewEvent may be deliberately true for one accepted invocation; ConditionActive may remain true until a process condition changes. Connecting one in place of the other can change when a cleared flag reappears.

The one-shot and edge-detection reference explains how observed transitions can create event requests, including the limitations of conditional calls and short pulses. Adding an edge detector still requires a documented startup and acceptance policy; it is not an automatic fix for every held-input problem.

03

Separate condition, acknowledgement and pending indication

A notification example is useful because it reveals how several meanings can be accidentally packed into one bit. ConditionActive describes whether the source condition currently exists. Acknowledged describes whether a relevant user action has been recorded. Pending describes what the interface still needs to present or process.

Clearing a display flag does not make the underlying condition disappear. Conversely, a condition returning to normal does not necessarily mean that a user has acknowledged its occurrence. Decide which combinations the interface needs to represent before selecting a latch arrangement.

For a richer exercise, use two independent fields: one describing the observed condition and one describing acknowledgement of the current notification. Write the required display states before coding. Avoid claiming that a single set/reset instruction implements a complete alarm-management policy.

A reset path should be reachable under the intended conditions, but “reset must execute every scan” is not a universal design rule. What matters is that accepted reset requests are handled reliably and that the scheduling and ownership are understood. An event-handling design and a cyclic level-evaluated design can use different mechanisms.

If a reset is rejected because the condition is still active, show that decision to the user where appropriate. Silently ignoring a request can make an operator think the interface or input failed. Keep the result of the request distinct from the stored state being displayed.

Separate set and reset writers have execution order

Consider a fictional ordinary Boolean variable Q with two sequential statements. The first statement sets Q when S is true. The second clears Q when R is true. With both requests true and both statements executed in that order, Q ends false. Reversing their order makes Q end true.

That end-state comparison resembles the two dominance policies, but separate writes expose intermediate states. In the set-then-clear model starting false, a consumer placed between the statements reads true even though the final value is false. Moving the consumer changes what it observes.

Model order with S and R both true	Value after first write	Value after second write
Set, then clear	True	False
Clear, then set	False	True

This is a bounded sequential example. It does not establish a universal “last rung wins” rule across multiple tasks, skipped routines, external writes or different execution contexts. Identify every writer and every relevant reader before reasoning about the observed result.

Where a single next-state calculation clearly expresses the requirement, it can make priority easier to review. The implementation still needs suitable scheduling and ownership. Putting the logic into one named block does not automatically make unrelated consumers observe a coherent application state.

Read the contacts and coils reference for the difference between an ordinary coil and a stored set/reset action. Inspect native execution semantics rather than treating all graphical output symbols as interchangeable.

04

Allen-Bradley latch and dominant instructions

Rockwell's OTU instruction clears the specified data bit when its rung condition is true. Its execution table does not clear the bit merely because that rung is false. Paired latch and unlatch logic therefore needs explicit write ownership and execution-order review. See the Studio 5000 OTU reference.

For explicit dominant instructions, Rockwell documents SETD and RESD; the reset mnemonic is RESD, not RSTD. The cited pages show Function Block and Structured Text forms and state that these instructions are unavailable in Ladder Diagram. Their structure fields and execution lifecycle are different from simply writing a CODESYS SR call. See SETD and RESD.

The native execution tables include first-run and enable behaviour. Review those alongside the normal input-priority rule; a normal-operation truth table is not a complete startup specification. Record the selected controller, software version and instruction form when capturing test evidence.

Do not replace a native instruction solely because a tutorial uses another name. Establish the existing requirement, check the current behaviour and compare a proposed implementation against the same cases. A translation should preserve the required state transitions, including conflict and initialisation cases.

Memory between calls is not a power-retention guarantee

A latch retains state between evaluations in the model. That statement does not specify what happens after a download, warm restart, cold restart, power interruption or memory reinitialisation. Those behaviours depend on the actual controller, storage declaration and application lifecycle.

Create a restart worksheet that names the relevant event, expected initial state, source of that state and conditions for accepting later requests. If a state is intentionally restored, explain how its validity is established. A restored true bit may describe an old condition or request that is no longer current.

If a state is intentionally cleared on startup, verify that a still-active set request does not immediately restore it contrary to the requirement. The held-input sequence above shows why clearing a stored Boolean once is not the same as requiring a fresh accepted event.

Separate software indication from physical action. A displayed pending notification can be restored for operator context without authorising equipment to resume. The application should identify what each restored state means and which further conditions are required before it influences another operation.

For South African learners considering power-recovery examples, use the actual project's restart requirements and available equipment documentation. Do not treat a generic load-shedding story as evidence that one latch pattern handles every restart safely.

05

Why this is not an emergency-stop design

The exercises here manipulate a notification flag. Choosing reset priority alone does not specify an emergency-stop function, feedback monitoring, fault response or prevention of unexpected restart. A Boolean result also does not demonstrate that physical energy has been removed.

Keep machinery safety design within an appropriate risk assessment, architecture and validation process. This reference is useful for understanding stored state and priority; it does not supply the information needed to validate a safety-related control function. Continue with the safety PLC introduction for that distinction.

This boundary matters when reviewing course material. An example labelled “emergency-stop latch” can look authoritative while omitting the surrounding requirements. Prefer a clearly bounded teaching flag for learning the truth table, and assess safety functions separately using the required equipment and evidence.

Build a meaningful set/reset test sheet

Check all eight combinations of old Q, S and R for each model. Then check sequences, because a memory element's result depends on previous evaluations. Include set, hold, clear, conflict, hold after conflict and a held set with reset release.

Use an independent expected-result method. For example, derive the current state from the most recent decisive input pair, applying the selected conflict priority. Compare that result with the step-by-step equation implementation. Two copies of the same equation are weaker evidence if the equation itself was transcribed incorrectly.

For separate writers, check both execution orders and a reader between them. For native testing, record declarations, instruction form, initialisation conditions and observed outputs. Keep the mathematical-model checks separate from native startup, task scheduling and physical-equipment evidence.

Use PLC program-testing practice to organise test cases and counterexamples. Confirm the current exercise coverage; educational simulation does not establish a target controller's retention or safety behaviour.

Questions about SR, RS and reset priority

Is SR always set dominant?

No. The cited CODESYS and Beckhoff libraries use SR for set priority, while the cited Siemens STEP 7 bit instruction named SR gives reset priority. Check the actual input names, documented truth table and simultaneous-input result before choosing or translating a block.

Does reset dominance require a fresh start afterwards?

Not by itself. In the level-evaluated teaching model, a held set request becomes effective again when reset is released. A fresh-request requirement needs an explicit acceptance and rearming policy, with startup and held-input cases included in the tests.

Why does a cleared flag immediately return?

Inspect whether the set condition remains active, whether another writer sets the flag, or whether the routine is processing the same request repeatedly. Clearing Q changes stored state; it does not remove the input condition or consume an external request unless the application explicitly does so.

Will a latched bit survive a PLC restart?

The model's memory rule does not answer that. Check the target's storage and lifecycle behaviour and test the relevant restart or download. Document whether restored state is still meaningful and whether later input evaluation can immediately change the initial value.

What should a South African PLC course assess?

Ask for a complete truth table, a conflict sequence and a migration example where native names differ. A learner comparing training in Johannesburg, Pretoria, Durban or Cape Town can request the same evidence. The assessment should distinguish a Boolean learning exercise from a validated machinery safety function.

06

Make the priority visible to the next reviewer

Keep the state meaning, conflict policy, native mapping and test results together. A comment such as “new notification wins if clear arrives simultaneously” is more informative than “use SR”. It expresses the requirement in terms that remain understandable across engineering systems.

For additional expression practice, explore Structured Text learning resources, checking the available exercises and access terms. Label portfolio evidence with its actual environment and scope.

A clear set/reset implementation accounts for normal inputs, simultaneous requests, held levels, call order and initial state. Those details make the stored behaviour reviewable and prevent a familiar mnemonic from hiding an unintended priority rule.