A one-shot, sometimes called an edge-detect or transition instruction, watches a bit and produces a pulse exactly one scan long the moment that bit changes state. A rising-edge one-shot fires on a false-to-true transition; a falling-edge one-shot fires on true-to-false. Depending on the platform you will see it as ONS, OSR, OSF, or as function blocks named R_TRIG and F_TRIG. The whole point is to turn a condition that stays true into a single, momentary event, so an action happens once per transition instead of over and over on every scan the condition holds.
One-Shot / Edge Trigger in one line: A one-shot or edge-detect instruction outputs true for exactly one program scan when its input transitions from false to true (rising edge) or from true to false (falling edge). It converts a level condition that stays on into a single-scan pulse, so downstream logic executes once per transition rather than repeatedly while the condition remains true.
An ordinary contact is level-sensitive: it passes power for as long as its condition is true. That is exactly what you want for most logic, but it is wrong whenever an action must happen once per event. If you tie a counter's increment or a data capture directly to a level condition, the controller will re-execute it on every single scan the condition stays true, adding thousands to a count or overwriting a snapshot continuously while a switch is held. The action fires far more often than the real-world event it was meant to track.
An edge-detect instruction solves this by remembering the input's previous state. Internally it compares the input now against the input on the last scan, and only asserts its output during the one scan where the input just went from false to true. On every subsequent scan, even though the input is still true, the one-shot's output is false again, because the transition has already happened. It rearms only after the input returns to false, ready to fire on the next fresh rising edge.
This memory of the prior state is why a one-shot needs its own storage bit and why you must not share that storage bit between two one-shots. If two edge instructions use the same status bit, one will consume the transition the other is watching for, and the logic becomes intermittent. Giving each one-shot its own unique bit is the small discipline that keeps edge detection reliable, and it is a frequent source of bugs when overlooked.
A rising-edge one-shot fires on the false-to-true transition, which is the common case: an operator presses a button, a level crosses a limit, a permissive becomes satisfied. In ladder dialects this shows up as ONS or OSR, and in IEC-style function blocks as R_TRIG, whose output Q goes true for one execution when its input goes from false to true. Use the rising edge when you want to act at the instant a condition first becomes true.
A falling-edge one-shot fires on the true-to-false transition instead, which is useful when the meaningful event is something ending: a run command dropping out, a permissive being lost, a piece of equipment stopping. This is OSF in ladder dialects and F_TRIG in function-block form. Choosing rising versus falling is simply a question of whether the moment you care about is the onset of a condition or its release, and both are single-scan pulses in their respective directions.
Across brands the names differ but the behavior is the same one-scan pulse tied to a transition. Because the pulse lasts only a single scan, you rarely wire it straight to a physical output, where a one-scan blip would be too brief to be useful. Instead the one-shot drives internal logic: it seeds a latch, bumps a counter, or triggers a move, and that downstream logic holds the resulting state for as long as needed. The one-shot's job is to mark the instant, not to sustain the result.
The most common field use is making a counter count once per event. If you feed a level-sensitive condition straight into a CTU it will increment every scan the condition holds; putting a rising-edge one-shot in front means it increments exactly once each time the condition first becomes true. This is how you correctly tally discrete events like arrivals, cycles, or completions without the count exploding while an input sits on. Any place a count seems wildly too high, a missing one-shot is the usual culprit.
Alarm latching is another natural fit. When a measurement crosses a limit, you often want to record the moment it first happened - to capture the process values at that instant and to set an alarm that stays up until acknowledged, even if the measurement dips back under the limit. A rising-edge one-shot on the limit-exceeded condition fires once, at the moment of the excursion, seeding the latch and grabbing the snapshot. Without the one-shot, the snapshot would be overwritten on every scan the limit stayed exceeded, losing the crucial first-event data.
The same pattern drives one-time data captures generally: recording a totalizer reading at the exact moment a batch ends, freezing a set of readings when a trip occurs, or stamping a value once per stroke. In distributed oil and gas monitoring these single-event captures become the records that a cloud SCADA platform historizes and an engineer later reviews. Firing a snapshot exactly once per transition, rather than continuously, is what makes those records meaningful rather than a smear of repeated identical entries, and it is one of the quiet reasons edge detection appears throughout well-written control code.
A rising-edge one-shot produces its single-scan pulse when the input goes from false to true, so it marks the moment a condition first becomes true. A falling-edge one-shot pulses when the input goes from true to false, marking the moment a condition ends. You choose based on whether the event you care about is the onset of a condition or its release; in IEC form these are R_TRIG and F_TRIG.
Because a level-sensitive condition stays true for many scans, and if you wire it directly to a counter, the counter increments on every one of those scans. The count then climbs far faster than the real events you meant to tally. Placing a rising-edge one-shot in front of the counter makes it add exactly once each time the condition first becomes true, which is the count you actually want.
A one-shot detects an edge by comparing the input's current state against its stored previous state, so it needs a dedicated bit to hold that history. If two one-shots share the same storage bit, one instruction will alter the state the other relies on, and both will behave intermittently. Assigning every edge-detect instruction a unique, unshared bit keeps transition detection reliable.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.