An ONS instruction can work exactly as designed while the output beside it appears never to energize. The apparent contradiction comes from scan timing: ONS passes a false-to-true transition for one program scan, while an OTE writes its destination from the rung condition every time the rung is evaluated. Put them in series and the destination is true for one scan, then false again.

That pulse may be entirely valid for incrementing a counter, recording an event, or requesting a state transition. It is usually the wrong command for a physical starter, valve solenoid, or operator indication that must remain active until another condition ends it.

The green online highlight can be missed when the true state lasts for only one task execution.

What ONS and OTE actually promise

Rockwell Automation defines ONS as an instruction that makes the remainder of a ladder rung true for one scan when the incoming rung condition changes from false to true. Its storage bit remembers whether the preceding logic was already true. That storage bit belongs to the edge detector and should not be shared casually with another one-shot.

OTE has a different contract. It sets its destination bit when the rung condition is true and clears the bit when the rung condition is false. Rockwell’s Studio 5000 bit-instruction reference distinguishes one-scan enabling with ONS from the maintained and retentive behaviors of OTE, OTL, and OTU.

On the scan that detects the rising edge, the ONS allows rung continuity and the OTE destination becomes true. On the next scan, the input may still be true, but the ONS blocks continuity because the edge has already been consumed. The OTE then clears its destination. The result is a legitimate one-scan pulse, not a failed coil.

Why the pulse disappears from view

Logix task execution and the engineering workstation’s online refresh are separate processes. A periodic task may execute many times between screen updates. The output can therefore turn on and off between two visible refreshes even though the processor executed both states correctly.

A physical output introduces another boundary. The controller updates its output data, the communication module transfers data on its schedule, and the connected device has an electrical and mechanical response time. A pulse that exists in the controller image for one scan may be too short to reach or actuate the field device reliably. The exact behavior depends on task period, module update, network arrangement, output hardware, and load—not on a universal millisecond threshold.

For diagnosis, count edges in an internal tag, latch a temporary diagnostic bit that requires a deliberate reset, or trend the event at a rate appropriate to the task. Do not extend a production command merely to make it visible without first considering what that extended command could operate.

Choose the pattern from the required state behavior

Use a one-scan pulse for an event

ONS is appropriate when the downstream instruction should execute once: incrementing a count, copying a recipe, capturing a timestamp, initiating a message, or asking a state machine to move to its next state. In that design, the one-scan tag is an event, not an equipment command.

Name it accordingly—Start_Request_Pulse is clearer than Pump_Start. The state or equipment routine should accept the request, check permissives, establish ownership, and create the maintained run command.

Use a seal-in equation for a maintained non-retentive command

If a start event must hold a run bit until stop, fault, or interlock logic becomes true, a sealed state equation can drive one OTE. The command remains true because the state bit participates in its own maintaining condition, not because the ONS remains true.

Place stop, fault, mode, and permissive conditions so their priority is unambiguous. Avoid drawing a branch that bypasses the very interlock intended to stop the equipment. A single output owner is easier to review than several rungs writing the same BOOL.

The one-shot should request a state change; maintained logic should own the equipment command.

Use OTL and OTU only with explicit reset ownership

An OTL sets a bit and an OTU clears it. This can be a clean event-to-state pattern, but every set path needs a reviewed reset path. Define what happens on first scan, mode change, download, processor restart, loss of feedback, and transition into a faulted state. Never assume that an operator stop button is the only condition that must unlatch the command.

For complex equipment, a state machine is normally clearer than scattered latch and unlatch instructions. It provides one place to define Idle, Starting, Running, Stopping, and Faulted behavior, along with the transitions that are allowed between them.

A fault-first troubleshooting sequence

First confirm the logic ahead of ONS actually transitions from false to true. If it is already true when the routine begins executing, there may be no new edge to pass. Check whether the routine is continuously scanned, conditionally called, or placed in a task that is inhibited.

Second, verify that the ONS storage bit is unique. Reusing one storage tag in two locations couples the edge history of unrelated rungs and can suppress expected pulses.

Third, cross-reference the OTE destination. Another OTE, OTL, OTU, produced tag, alias, or external write can change the same bit later in the scan or in another task. Rockwell’s OTE documentation specifically warns about operands being overwritten. Establish one owner for the final command and let other routines request changes through separate tags.

Fourth, separate controller state from physical state. Observe the command tag, module connection status, output data, field voltage, interposing relay, starter input, and device feedback as different points in the signal chain. A correct tag does not prove field power, and an energized output LED does not prove the actuator moved.

Finally, remove forces and temporary diagnostic latches after testing. Document the test method so maintenance personnel do not inherit a service-only bit that silently changes production behavior.

Application example: pump lead selection

A lead/lag routine may generate a one-shot when Pump 1 becomes the selected lead unit. That edge should not be wired directly to the physical output. It should request a start from the pump equipment module. The module then checks automatic mode, permissives, trip state, minimum-off timing, process demand, and availability before asserting a maintained run command.

Feedback should move the state from Starting to Running, while a start timeout creates a failure response. Stop demand and faults should move the state toward a controlled stop or immediate trip according to the process design. This separation prevents a fleeting selection event from becoming the only thing holding a motor command.

For another example of turning Boolean intent into maintainable ladder structure, see the corrected guide to three-switch XOR and odd-parity logic. Controller and I/O options can also be reviewed through PLC and PAC systems.

The design test is ownership

Editorial view: the recurring mistake is not misunderstanding a one-shot; it is allowing an event bit to masquerade as an equipment state. Edge detectors answer “did this transition occur?” State logic answers “what should the machine be doing now?” Keeping those questions separate produces code that is easier to commission, safer to restart, and far less vulnerable to duplicate-coil edits.

Frequently asked questions

Does an ONS energize the following OTE?

Yes, for the scan in which the incoming rung condition changes from false to true. On the following scan, the ONS blocks the rung until its input condition first returns false and then rises again.

Why can’t I see the OTE turn on online?

The one-scan pulse may begin and end between engineering-workstation refreshes. Use an internal event counter, a controlled diagnostic latch, or an appropriately configured trend to prove that the edge occurred.

Should I replace the OTE with an OTL?

Only if retained state is the actual requirement and every unlatch condition is explicitly designed. For many equipment commands, a state machine or seal-in equation with one OTE owner is easier to audit.

Can two ONS instructions share the same storage bit?

They should not. The storage bit records edge history. Sharing it couples the two instructions and can cause one rung to suppress the other’s expected pulse.

Can a one-scan OTE drive a physical output?

The controller can write that state, but the pulse may not be transferred or held long enough for the module and field device to respond. Physical commands should be based on a defined maintained-state requirement.