IEC One Shot Instruction: R_TRIG, F_TRIG and ONS

An IEC one shot instruction detects a transition in an observed Boolean signal. A rising-edge detector identifies an observed change from false to true; a falling-edge detector identifies true to false. Names such as R_TRIG, F_TRIG and ONS are useful starting points, but correct behaviour also depends on when the instruction executes and how its previous-state memory is maintained.

For South African PLC learners, the important distinction is between detecting an observed transition and capturing every physical event. A one-shot cannot reconstruct a pulse that never appeared in its input samples. It also does not automatically debounce a pushbutton or deliver a brief event reliably to a slower consumer.

This guide uses explicitly defined Boolean and sampling models, not native controller execution results. This site has a commercial connection to PLC Simulator; its educational tools do not replace vendor software or verify arbitrary native edge instructions. The illustrations are conceptual study scenes rather than vendor screenshots or customer evidence.

What a rising or falling edge means

Start with two observations: the saved previous value and the value read during the current invocation. In the teaching model, a rising event is current true and previous false. A falling event is current false and previous true. After evaluating both, save the current value for the next invocation.

The order matters. If the model overwrites previous with current before comparing them, the comparison loses the old state. Likewise, if another independent detector changes the same saved state, the result no longer describes one signal's own observation history.

Previous observation	Current observation	Rising event	Falling event
False	False	False	False
False	True	True	False
True	False	False	True
True	True	False	False

This truth table defines the model after an initial previous value has been supplied. It does not specify every vendor's startup or prescan behaviour. Native instructions may initialise their storage deliberately to suppress an initial event, so a first execution requires its own test.

An edge is also different from a level. A held-true button can remain true for many observations while generating only one observed rising event. A level condition is appropriate when an action should remain enabled; an edge condition is appropriate when the application needs a single event at a transition. Choose from the requirement rather than adding one-shots to every rung.

Worked sequence with both edge directions

Set the model's initial previous value to false. Supply six consecutive observations: false, true, true, false, true and false. Invoke the model once for each observation. The expected results contain two rising events and two falling events.

Invocation	Observed input	Saved value before evaluation	Rising	Falling
1	False	False	False	False
2	True	False	True	False
3	True	True	False	False
4	False	True	False	True
5	True	False	True	False
6	False	True	False	True

The held true value at invocation 3 does not create another rising event. The false observation at invocation 4 is important: it establishes the low state from which invocation 5 can be recognised as a new rise.

For an event-counting exercise, increment a separate teaching total on each model rising event. The total after these observations is two. If instead the total increments on every true observation, it becomes three. This comparison isolates edge-triggered counting from level-triggered accumulation without assuming a native counter's own execution rules.

Do not automatically put an extra one-shot before every vendor counter. First check whether that counter already counts transitions, how reset is handled and what its enable input means. Additional gating can alter which transitions the counter sees. The PLC counter reference covers the need to verify the selected counter's contract.

02

One invocation is not a universal pulse duration

Vendor descriptions often use “one scan” or “one cycle” for a one-shot output. To interpret that correctly, identify the task, call schedule and point where the result is read. A result computed once per regular task execution has a different observation context from an instance called conditionally or more than once during a task.

In the teaching model, every call computes a new event result and updates the saved input. Call the same detector twice with true after a saved false: the first call reports a rise, and the second reports no rise. A consumer reading only after the second call sees the latter result.

That does not mean an instance can never intentionally be called more than once. It means each call contributes to the same observation history. For two independent input signals, use independent saved state or independent detector instances so one signal does not overwrite the other's history. The function block and instance-state reference explains how an instance keeps its own data between calls.

Also define what a consumer reads when no call occurs. In a model where an output variable changes only when assigned, skipping the detector leaves its stored value unchanged. A previously true result can remain stored even though no new event has been evaluated. Whether a particular native instruction clears, retains or otherwise handles a conditionally executed output needs inspection in that environment.

Separate an event's occurrence from its temporary Boolean representation. If several consumers must react, arrange when they read the event or publish a request with acknowledgement. Re-running the same detector independently at each consumer is not a substitute for a defined event-delivery method.

Conditional calls can hide the rearming observation

Suppose the physical or upstream signal has observations false, true, false, true. An always-evaluated rising-edge model starting from false detects two rises. Now call the detector only during the two true observations. The first call reports a rise; the second sees saved true and current true, so it reports none.

The missing low observation explains the result. Persistent previous-state memory is not itself a defect; the detector needs memory to compare observations. The issue is that the chosen call schedule never presented the intervening low state to that instance.

Invocation supplied to the conditional detector	Input seen	Saved value before call	Rising event
First selected call	True	False	True
Second selected call	True	True	False

An event-driven task is not automatically unsuitable for edge detection. Determine what causes the task to execute and which input states it can observe. If each task invocation already represents a separately identified event, a state-edge detector may be unnecessary or may need a different signal contract.

A common alternative is to evaluate the detector regularly and gate the use of its result separately. That preserves input observations, but it also makes a policy choice: edges occurring while permission is false may be discarded. If such events must be retained, store pending work explicitly rather than expecting a disabled consumer to remember a vanished pulse.

Use the PLC scan-cycle and execution-order guide to connect instruction calls, input updates and downstream reads. The useful question is when the relevant data was observed, not just how often the overall controller nominally scans.

03

Gating before and after edge detection changes the event

Compare two fictional requirements. Design A detects a rising edge of Signal AND Enable. Design B detects a rising edge of Signal continuously, then accepts that event only when Enable is true. These expressions can behave differently even if both contain the same two input tags.

Consider Signal already true while Enable is false. Design A observes a false combined condition. When Enable changes to true, the combined condition rises, so A generates an event. Design B has already observed Signal rise while disabled; changing only Enable does not create another Signal edge.

Observation	Signal	Enable	Edge of combined condition	Signal edge accepted by Enable
1	True	False	False	False
2	True	True	True	False
3	False	True	False	False
4	True	True	True	True

Both detectors in this example start with saved false, and Design B is evaluated at every observation. The first Signal edge exists at observation 1, but B's acceptance gate discards it. This is why the right-hand column is false there.

Neither design is universally correct. A requirement might intentionally treat enabling an already-active request as a new actionable condition, or it might require a fresh press after enabling. Write that choice in the acceptance criteria. For operator requests, also decide whether a rejected or disabled press needs feedback.

This distinction is particularly useful when diagnosing an unexpected count after changing a mode or enabling a routine. Inspect the complete condition entering the edge detector, including permissives, rather than looking only at the physical input tag.

A short pulse can disappear between observations

Use a fictional sampler that reads at exactly 0, 10 and 20 milliseconds. A signal is high from 3 milliseconds up to, but not including, 7 milliseconds. All three samples are false. A rising-edge model receiving only those samples correctly reports no rise because it never observed the high state.

Change the high interval to 3 through just before 13 milliseconds. The samples become false, true, false. The model now reports a rise at 10 milliseconds and a fall at 20 milliseconds. Those are detection times in this idealised model, not measurements of a PLC's input delay or timing accuracy.

Fictional high interval	Samples at 0, 10 and 20 ms	Observed rising events
3 ms to before 7 ms	False, False, False	0
3 ms to before 13 ms	False, True, False	1

There is no general rule that a too-fast signal loses “every other” edge. The observed pattern depends on the signal timing and observation schedule. Input filtering, module updates and task scheduling add further requirements in an actual installation; measure and document the entire relevant path.

If the application must capture events shorter than the normal observation interval, investigate suitable input capture, counting or event facilities for the exact hardware. Check their supported pulse width, frequency, filtering and operating limits. A software one-shot added after an already-missed event cannot recover it.

Do not interpret these millisecond values as recommended settings. They were chosen to make the sampling counterexample obvious. The design evidence for real equipment must come from its requirements, hardware documentation and appropriate tests.

04

One-shot detection is not pushbutton debounce

A bouncing input can supply several observed low-to-high transitions for one physical press. An edge detector can report each observed rise accurately while the application still counts more events than the operator intended. Detecting changes and deciding which changes represent one valid press are different tasks.

For a simple Boolean counterexample, the observations false, true, false, true, true contain two rises even if the exercise labels them as one bouncing press. A held-high test alone would not reveal that behaviour. Include a bounce-like observation sequence in the test sheet.

A debounce policy needs its own acceptance definition, such as requiring a stable state according to a specified method. Any time threshold must match the input and application requirements. Avoid choosing an arbitrary universal delay or implying that an ordinary debounce routine establishes a safety function.

For HMI or network requests, consider whether the issue is contact bounce at all. Repeated messages, retries or a persistent request bit may require identifiers and acknowledgement rather than a physical-button filter. Document which system owns the request and when it is considered consumed.

Native instruction details to check

Siemens R_TRIG

Siemens' STEP 7 V21 FBD reference describes comparing CLK with the previous query saved in the specified instance. It reports Q for the detected positive transition. The important project checks are the instance, the condition supplied to CLK and the schedule of calls. The reference's cycle description should be read in that execution context. See the Siemens R_TRIG documentation.

CODESYS R_TRIG and F_TRIG

The CODESYS Standard library documents R_TRIG and F_TRIG as function blocks with Boolean CLK input and Q output. Its examples call the instance and then read Q. They provide a useful syntax reference, but they do not establish every target's startup, retention or scheduling policy. Consult the CODESYS rising-edge block and falling-edge block for the cited library version.

Rockwell ONS, OSR and OSF

Rockwell's version 38 ONS reference defines the transition of rung-condition-in and states that its storage bit retains the condition from the last execution. During prescan, that bit is set true to prevent an invalid first-scan trigger. An always-true condition with ONS is therefore not a generic startup pulse recipe. See the Studio 5000 ONS reference.

OSR and OSF expose separate storage and output bits for rising and falling events respectively. Use the exact instruction's execution rules and keep its storage under the intended ownership. See the OSR operand reference and OSF operand reference.

05

Test startup, repeated calls and independent signals

Start the mathematical model with previous false, then repeat with previous true. For a first observed true, the former reports a rise and the latter does not. For a first observed false, the latter reports a fall. These differences demonstrate why an unspecified initial state leaves an incomplete test case.

Native startup testing should identify the controller mode transition, instance initialisation and retention settings. Do not use a generic edge on an always-on tag as proof that defaults will be loaded exactly once under every restart condition. Initialisation and controlled recovery need explicit requirements.

For independent-signal testing, call two separate model instances with interleaved inputs and verify that each matches its own history. Then deliberately reuse one saved-state variable and show a failing case. Explain the state interference instead of claiming the second detector will always fail in exactly the same way.

Record where each consumer reads the event. A slower task may never read a short-lived true value, while a stored pending request can remain available until acknowledged. Select the interface from the delivery requirement and verify it independently of the edge detector.

Use PLC program-testing practice to organise expected observations and deliberate counterexamples. Check the current educational scope; the product is not evidence that these native timing and startup cases have been executed on your controller.

Questions learners ask about one-shots

Why does my R_TRIG work only the first time?

Check whether the instance ever observes a false CLK after the first true. Conditional calls may hide the rearming observation. Also inspect shared state, repeated calls and the consumer's read point. A persistent high input naturally produces only one observed rise until a low state is observed.

Why do I get an event when enabling a mode?

Inspect whether the detector watches a combined condition containing that enable. The combined condition can rise even when the physical input has not changed. Decide whether the requirement is an edge of the complete permitted request or a physical signal edge accepted only while permission is already true.

Can a one-shot count every fast sensor pulse?

Only events represented in the detector's observations can be detected by that model. Short pulses can occur entirely between observations. Establish the input acquisition and event-capture requirements before selecting hardware or task settings; adding edge logic alone does not establish reliable pulse capture.

Should a falling-edge output be true at startup?

That depends on the instruction's initialisation and the application contract. The teaching truth table requires an explicit previous value, and native blocks have their own startup behaviour. Test the relevant mode transitions instead of extrapolating startup results from normal repeated operation.

What should I ask a PLC training provider in South Africa?

Ask learners to demonstrate a held input, a rearming low observation, a missed short pulse and an enable-gating difference. Whether studying in Gauteng, Durban or Cape Town, request the assessed controller and software version. A course should explain the observation history rather than promise that one-shots solve every counting problem.

06

Build an edge-detection portfolio example

Keep a table of calls, input observations, saved state and expected event results. Include at least one deliberately incorrect call schedule and explain the lost information. Pair the Boolean model with clearly labelled native evidence if you have access to the required engineering environment.

For further expression and state practice, explore Structured Text learning exercises, checking current access and exercise coverage. Describe this as educational practice, not a customer installation or a recognised qualification.

An effective one-shot review accounts for the observed signal, initial state, invocation schedule and event consumer. With those details visible, R_TRIG, F_TRIG and ONS become understandable tools within a defined design rather than unexplained fixes for missed or repeated events.