Bistables & Edge DetectionBeginnerIEC 61131-3

R_TRIG Rising Edge in PLC: One-Scan Pulse Example

Quick answer
R_TRIG compares the current CLK state with the state stored from its previous execution. Q is TRUE for one task execution only when CLK changes from FALSE to TRUE. A sustained TRUE input produces no additional pulses. Each independently monitored signal needs its own persistent R_TRIG instance.

The R_TRIG (Rising Edge Trigger) function block detects a FALSE-to-TRUE transition on its input (CLK). The output (Q) is TRUE for exactly one PLC scan cycle when the rising edge occurs, then returns to FALSE. R_TRIG is one of the most important function blocks in PLC programming, used to trigger actions on signal changes rather than signal levels. Applications include counting pulse inputs, triggering one-shot operations, detecting button presses, and synchronizing events.

Reviewed 2026-07-25

Parameters

Inputs

Name	Type	Description
CLK	BOOL	Input signal to monitor for rising edge

Outputs

Name	Type	Description
Q	BOOL	TRUE for one scan on rising edge of CLK

How R_TRIG rising-edge detector works scan by scan

Read the waveforms and state table together. The diagram shows the sequence; the table states what the program should observe at each execution.

R_TRIG one-scan pulse diagram

Each FALSE-to-TRUE transition of CLK produces one Q pulse exactly one task execution wide. Holding CLK TRUE does not produce more pulses.

Blue is the input, green is the boolean output, and amber is elapsed time or current count. Transitions are shown at task executions; real timing resolution depends on the controller and task.

State table

Moment	Input	Internal state	Output	Engineering meaning
Stable low	CLK = FALSE	Previous CLK = FALSE	Q = FALSE	The detector is armed for a rising edge.
Rising edge	CLK changes FALSE → TRUE	Previous CLK was FALSE	Q = TRUE for this execution	Trigger the one-time action on Q.
Held high	CLK remains TRUE	Previous CLK = TRUE	Q = FALSE	A level is not counted repeatedly.
Return low	CLK changes TRUE → FALSE	Previous state is updated	Q = FALSE	The detector is ready for the next rising edge.

Ladder and Structured Text examples

Increment once for each button press

|----[ Start_PB ]----[ R_TRIG StartEdge ]----|
|----[ StartEdge.Q ]--------( Event_Pulse )--------|

Event_Pulse is true for one scan even if Start_PB remains pressed. Mechanical bounce can still create multiple real edges, so debounce the physical input when necessary.

IEC-style Structured Text call

VAR
    StartEdge  : R_TRIG;
    StartPB    : BOOL;
    EventPulse : BOOL;
END_VAR

StartEdge(CLK := StartPB);
EventPulse := StartEdge.Q;

Call the instance once, in a predictable place, on each intended task execution. Do not reuse StartEdge for another signal because its stored previous state belongs to StartPB.

Vendor compatibility

A shared mnemonic does not guarantee an identical interface or state machine. Confirm the instruction help for the controller, firmware, language and library version used on the project.

Platform	Instruction	What maps cleanly	Caveat to verify
Siemens TIA Portal	R_TRIG or positive-edge contact/instruction	Detects a 0 → 1 transition and stores prior state	The edge-memory instance/tag must not be shared with an unrelated signal.
Rockwell controllers	ONS/OSR in Logix; R_TRIG is available on some Micro800 toolchains	Produces a one-scan event from a false-to-true condition	Prescan and storage-bit rules differ by instruction and controller family.
CODESYS / IEC libraries	R_TRIG	CLK and Q standard trigger interface	Skipping calls or recreating the instance changes the stored-history model.

Failure modes and edge cases to test

CLK is already TRUE on the first execution

The initial Q result can depend on instance initialization/prescan rules. Test startup explicitly.

The physical pulse is shorter than the input/task update

R_TRIG cannot detect an edge the task never samples; use hardware capture or a faster task when required.

The instance call is skipped

Stored history is not updated during the skipped interval, so the next observed transition may not match field timing.

One instance monitors two signals

The signals corrupt each other’s previous-state memory. Allocate one instance per signal.

Evidence and review status

R_TRIG interface and rising-edge behavior were checked against the current CODESYS Standard library. Vendor equivalents and instance rules still need confirmation in the target platform.

Technical review date: 2026-07-25

Critical behavior

Q is true for one invocation when CLK is true now and was false at the previous invocation.
Each monitored signal needs independent edge memory; reusing one instance can couple unrelated events.
If the block is not called on a scan, its stored previous state and the next observed edge can behave differently from a continuously called instance.
A pulse shorter than the input-update and task periods can be missed before R_TRIG sees it.

Verification checklist

1Call the instance on every intended task execution.
2Test CLK sequences 0→0, 0→1, 1→1 and 1→0.
3Confirm Q lasts exactly one task execution.
4Use separate instances for separate input signals.

Worked test

Prove the one-scan output

Call StartEdge(CLK := StartPB) once per cyclic task.

1Scan 1: StartPB = false.
2Scan 2: StartPB = true.
3Scan 3: keep StartPB = true.
4Scan 4: set StartPB = false.

Expected result: StartEdge.Q is true only on scan 2. It is false on scans 1, 3 and 4.

Technical sources

The target controller's version-specific instruction help remains authoritative.

R_TRIG Standard function block
CODESYS Development
R_TRIG function block
ABB Automation Builder — Current vendor library declaration and example

Platform-Specific Implementation

Siemens (TIA Portal)

Use R_TRIG instruction or P (positive edge) contact in TIA Portal ladder logic.

Allen-Bradley (Studio 5000)

Use ONS (One-Shot) instruction or OSR (One-Shot Rising) in Studio 5000.

CODESYS

Standard R_TRIG in Standard library. Each instance tracks its own edge state.

Common Applications

Button press detection
Counter input conditioning
One-shot event triggering
Pulse counting
State machine transitions

Common Mistakes to Avoid

Assuming Q stays TRUE for more than one scan
Not creating a separate R_TRIG instance for each signal
Calling R_TRIG multiple times per scan for the same instance

Frequently Asked Questions

What is R_TRIG (Rising Edge Detection) in PLC programming?

Detects FALSE-to-TRUE transition, outputs single-scan pulse on rising edge. The R_TRIG (Rising Edge Trigger) function block detects a FALSE-to-TRUE transition on its input (CLK). The output (Q) is TRUE for exactly one PLC scan cycle when the rising edge occurs, then returns to FALSE.

What are common applications of R_TRIG (Rising Edge Detection)?

R_TRIG (Rising Edge Detection) is commonly used for: Button press detection, Counter input conditioning, One-shot event triggering, Pulse counting, State machine transitions.

How do I use R_TRIG (Rising Edge Detection) in different PLC platforms?

Siemens: Use R_TRIG instruction or P (positive edge) contact in TIA Portal ladder logic. Allen-Bradley: Use ONS (One-Shot) instruction or OSR (One-Shot Rising) in Studio 5000. CODESYS: Standard R_TRIG in Standard library. Each instance tracks its own edge state.