CTAXTRAP move complete: hold E/R on until Success or Error

What E/R does during a CTAXTRAP move

The manual's wording for E/R (Enable/Reset) is: "When this input logic is ON the specified Pulse Output will be enabled & the Pulse Output Device will begin to move." The instruction is not edge triggered. It never samples a rising edge and then runs on its own; the move runs for exactly as long as E/R stays ON. Release it mid-move and the pulse output leaves move mode, the axis stops where it stands, and no Success or Error result appears, because the instruction never finished. A 3-second move needs E/R held for all 3 seconds, not just the first scan.

Eight CTRIO2 instructions need this held enable: CTAXDYNP, CTAXJOG, CTAXLIMT, CTAXTRAP, CTDYNPOS, CTDYNVEL, CTRUNPOS and CTRUNVEL. When E/R enables an output, the feedback bit turns ON with it; on output 0 the element is the output's .OutputEnabled feedback. That bit follows the enable. Completion for CTAXTRAP is a separate report: the instruction sets Success when the move reached its target and Error when it failed, and one of the two ends every commanded move.

Symptoms and what each one points to

Each symptom below maps to one condition. Work down the list and the rung to correct usually names itself.

• The axis stops mid-travel with no Success and no Error. That is an abort. E/R went OFF while the move ran, so the fault is in whatever dropped the enable: a permissive, a mode transition, or a state change in the sequence.
• The sequence advances the moment the move starts. Completion is wired to the enable feedback, the output's .OutputEnabled bit or the matching element for your output. That bit turns ON at the start, when the output is enabled, so a sequence watching it steps immediately.
• The sequence hangs on a move that already ended or never began. Completion is wired to a signal this instruction never produces. The common case is .AtPosition on a CTAXTRAP rung: .AtPosition is the arrival watch for the dynamic-position instructions CTAXDYNP and CTDYNPOS, where it reports each .GotoPosition request.
• The next move never starts. E/R was released after the last completion and nothing re-establishes it, or the last Success or Error result was never consumed by the sequence.
• An ST143 driver error appears when CTAXTRAP executes. That fault sits in the output's driver setup, ahead of any E/R timing question. The page on resolving a CTRIO2 ST143 driver error when executing CTAXTRAP works through that fault.

Example: one held enable for a program with four motion rungs

The inputs. A program you inherit has four motion rungs on CTRIO2 outputs: one CTAXTRAP positioning move that travels for 3 seconds at 20,000 pulses per second, two dynamic-position rungs, one on CTAXDYNP and one on CTDYNPOS, and one CTAXJOG rung for manual jog. The rung list is the scenario's starting point; the behavior of each instruction comes from the module's own documentation.

The rule in words. Every instruction in the eight-name list needs E/R ON for as long as its mode is active, and each group reports its end its own way. The four finite-move instructions, CTAXLIMT, CTAXTRAP, CTRUNPOS and CTRUNVEL, set Success or Error. The two dynamic-position instructions, CTAXDYNP and CTDYNPOS, request each move with .GotoPosition and report arrival on .AtPosition. CTAXJOG holds jog mode until E/R goes OFF. CTDYNVEL takes each new speed by writing its Frequency parameter and leaves velocity mode when E/R goes OFF.

The arithmetic. The four rungs sort as 1 CTAXTRAP + 2 dynamic-position + 1 jog = 4, which uses three of the four documented behaviors in the eight-instruction list. The enable requirement is identical across all four rungs, so one active-motion state bit can drive E/R for every rung at the same time. On the CTAXTRAP rung that means the state bit stays set for the full 3-second travel time, and a 10 ms drop anywhere inside it would abort the move.

The result. A single held enable covers the whole program, and the completion watch changes per rung: Success or Error on the CTAXTRAP rung, .AtPosition on the two dynamic-position rungs, and the jog button state on the CTAXJOG rung, which ends when E/R is allowed to drop.

The decision. Sort every motion rung in the program against the eight-name list. If a rung uses one of those instructions, hold E/R for the whole mode and release it only on that instruction's documented end signal; anything copied between modes gets its completion test re-checked before it runs.

Checks before you rewrite the rung

1. Confirm which instruction actually drives the output. Routines get copied between motion modes; a dynamic-position routine uses .GotoPosition and .AtPosition, and a trapezoid routine uses Success or Error. Fixing shared logic against the wrong instruction leaves the sequence waiting forever or stepping early.
2. List every condition that can remove E/R: permissives, mode transitions, sequence-state changes, and any rung that resets or overwrites the enable coil later in the scan.
3. Run one test move with three signals visible together: E/R, the output's .OutputEnabled bit, and the instruction's Success and Error parameters. The healthy pattern on a 3-second move is E/R ON for all 3 seconds, exactly one of Success or Error at the end, and .OutputEnabled ON until you release the enable afterwards.
4. Treat the test as motion: an E/R drop stops the axis abruptly, so run it under the cell's normal safe procedure with people clear of the travel path.

To keep those signals in view at the cell during tests, displaying 16 PLC input and output bits on one screen lays out the panel side of it.

The fix: hold E/R with an active-motion state

The fix is to make the enable last exactly as long as the move. Give the sequence a state bit that means this output is in a move: the start request sets it, and the instruction's Success or Error result clears it. Drive E/R from that state and keep the machine permissives in series with it, so a genuine interlock drop still stops the axis through the documented abort path. If an interlock opens, find why before the next cycle; forcing the enable back ON hides a machine condition that will bite again.

Keep the operator's start request separate from the enable state. The request explains why the sequence entered motion; the state shows whether the output is still enabled. An HMI button can set the request through a command bit, and making an HMI button turn on a PLC output through a command bit walks through that handshake. The level-versus-pulse mistake shows up on screens as well, where a button output stays on only while its rung is true; the fix for an HMI button output that only stays on while pressed is the same error one layer up.

Branch on the result. Success means the axis arrived, so the sequence transitions in its intended order and then releases E/R. Error means it did not, so handle that path as a fault and keep the two paths separate, so a fault can never be read as an arrival. For a wall board that shows axis status to the whole shift, that is a display job, not a logic job, and shop-floor signage displays are what we build for that side of it.

Recommendation: Drive E/R from a held active-motion state and keep it ON until CTAXTRAP reports Success or Error; rewrite any rung that pulses E/R at the start or drops it on the first step transition, and check the pattern with E/R, .OutputEnabled, Success and Error watched together before the machine runs parts.

Questions