Resetting CLICK PLC Outputs Before the Off-Delay Timer

Brian Holt8 min read
AutomationDirectHMI ProgrammingTroubleshooting
Licensed PE Working through this on a live machine? A Maine-licensed engineer can take it from here — included with IMD hardware, by the hour for everything else. Book an engineer

A running off-delay timer answers to one thing: its own enable rung. Once that rung goes false and the accumulator starts counting, nothing else in the program can cut the count short. That is why Y4 holds until the full 10 seconds elapse even though the PLC is clearly reading X1, X2 and X3 — those sensors are latching their own outputs, but they have no electrical path to the timer's output bit. The timer is not broken. It is the wrong instrument to hang the output on.

Drop the Off-Delay Timer Off the Output Rung

The quick fixes that get tried first on this machine, and why each one fails:

  • Paralleling the other sensor contacts into the timer rung. That only re-enables the timer. The output bit is still governed by the accumulator, so the output goes back on instead of going off.
  • One off-delay timer per output. Four timers, four accumulators, same behaviour four times over — and now the four outputs have no mutual exclusion at all.
  • Driving the output with an OUT coil off the timer bit. An OUT coil re-solves from its own rung every scan, so it fights the sensor rung. The output either chatters or never latches. Rung 9 in particular has to be a RST of Y4, not an OUT.
  • Reaching for an interrupt. Interrupts exist for high-speed input events measured in microseconds. A 10-second — eventually 2-minute — idle window runs fine at scan resolution.

What restores production is nine rungs: four to set the outputs, one timer, four to reset the outputs. The sensor latches its output with a SET. A separate rung clears it with a RST driven by the idle timer OR'd with the three other sensors.

Symptom What is actually happening Fix
Output holds until the timer expires; new sensor ignored Output is driven by the timer's own bit; nothing else can force it Latch with SET, clear from a separate RST rung
Output flickers or never latches OUT coil re-solving every scan against the set rung Replace OUT with the SET/RST pair
Two outputs on at once Reset rungs missing the other sensors' contacts OR all three other inputs into each reset rung
Output never comes on for one sensor That sensor's own contact is in its own reset rung Exclude the setting sensor from its reset OR block
Output blips off for one scan on a new target Timer rung placed after the reset block, timer bit still true Move the timer rung between the set and reset blocks
Dead spot between sensors, no output at all Overlapping prox fields turn two inputs on; each reset rung cancels the other output Space the sensors so the fields do not overlap

Check: put the CLICK software online, open Data View, and watch the output bit while you trip a second sensor. If the output does not move until the accumulator reaches setpoint, you have confirmed the diagnosis and can start rewriting.

Build the Four Set Rungs First

Each prox sensor latches its own output and does nothing else. Keep these four rungs at the top of the program.

RUNG 1   X1 ─────────────────( SET Y1 )
RUNG 2   X2 ─────────────────( SET Y2 )
RUNG 3   X3 ─────────────────( SET Y3 )
RUNG 4   X4 ─────────────────( SET Y4 )

Before you write anything else, confirm the I/O map matches the physical order of the sensors on the machine. If the sequence runs X1 → X2 → X3 → X4 along the travel but the wiring puts the fourth sensor on X1, either swap the field wiring or swap the addresses in the rungs — do not try to correct it later in the reset logic. The same applies to output numbering: if a spare output is being skipped, renumber now.

Check: with the reset rungs not yet written, wave a target past each sensor in turn. Each output should latch and stay latched. Four outputs on at once at this stage is correct.

Add One Idle Timer Between the Set and Reset Blocks

One shared timer covers all four outputs. Enable it with the four inputs in series as normally-closed contacts — that rung is true only when no sensor sees a target, so any sensor anywhere on the machine zeroes the accumulator and restarts the idle window.

RUNG 5   X1    X2    X3    X4
        ─┤/├──┤/├──┤/├──┤/├──[ TMR  T1 ]
                              On-Delay
                              SP = 10 s   (120 s in production)

Use an on-delay timer here rather than an off-delay one. An on-delay done bit is true exactly when the idle condition has persisted for the setpoint — no inverted contact, no polarity to second-guess. If you prefer the off-delay form, enable it with the four inputs in parallel and drive the reset rungs from a normally-closed contact of the timer bit; verify the polarity in Data View before you trust it.

Two setpoint traps when you go from bench to production:

  • Enter 120 on a 1-second time base, not 120000 on a millisecond base. The setpoint field has a finite range; confirm the software accepts the number you typed.
  • Rung order is not cosmetic. Rung 5 must execute after the set rungs and before the reset rungs, so a sensor that closes on this scan clears the timer bit before the reset block reads it.

Check: watch the timer's current-value register in Data View. It should climb only while every input is off, and snap back to zero the moment any target enters a field.

Write the Reset Rungs as an OR of the Other Sensors

Four rungs, one per output. Each one ORs the timer done bit with the three sensors that did not set that output.

RUNG 6   T1 ─┬────────────────( RST Y1 )
         X2 ─┤
         X3 ─┤
         X4 ─┘

RUNG 9   T1 ─┬────────────────( RST Y4 )
         X1 ─┤
         X2 ─┤
         X3 ─┘

Rungs 7 and 8 follow the same pattern for Y2 and Y3. Two rules hold the whole scheme together. First, never put a sensor's own contact into its own reset rung — the output would be set and cleared in the same scan and never appear at the terminal. Second, the reset block sits below the set block, so on a scan where both fire, the reset executes last and wins. That is what you want: a new target takes priority over a stale latch.

Check: trip sensor 1, then sensor 2. Output 1 must drop in the same scan output 2 latches. Then leave every sensor clear and confirm the surviving output drops at the setpoint.

Clear the Dead Spot Between the Prox Sensors

Once the logic is right, a dead band can still appear between adjacent sensors where no output is on. That is not a programming fault. If the sensing fields overlap, two inputs are true at the same time — and by design rung 6 sees X2 and clears Y1 while rung 7 sees X1 and clears Y2. Both outputs go down and stay down for as long as the target sits in the overlap.

Fix it mechanically, not in software:

  1. Move the sensors further apart until the fields no longer overlap. Check the sensor datasheet for the minimum side-by-side spacing for inductive proximity switches — mutual interference and target size both matter.
  2. Re-run the target slowly through the whole travel with Data View open on X1–X4.
  3. Confirm that at most one input bit is on at any position, and that the handoff lands where you want it — mid-way between sensors is the clean result.

Check: one input on at a time through the entire stroke, one output on at a time, no position where all four outputs are off while a target is present.

Run the End-to-End Check

Do this online with Data View showing X1–X4, Y1–Y4, the timer bit and the timer current value.

  1. Trip each sensor in isolation. One output latches; it stays latched with the sensor clear.
  2. Trip sensors in sequence at production speed. Exactly one output on at every step, no overlap, no gap.
  3. Leave the machine idle. The current value climbs to setpoint, the timer bit goes true, every output clears, and the bit stays true until the next target.
  4. Trip a sensor immediately after timeout. The output latches on the same scan and the timer value returns to zero.
  5. Change the setpoint to 120 s and repeat step 3 only — the sequencing logic is unchanged, so there is nothing else to re-test.
  6. Write the rung comments while the logic is fresh, then save the project. The four-one-four rung layout carries the process flow; comments carry the reasoning for whoever opens it next.

Stop and call AutomationDirect technical support if the outputs behave correctly in Data View but the field devices do not follow — that points at output module loading, wiring or supply, not at logic. Stop as well if the timer current value never advances or never clears with the enable rung visibly false, since that is instruction or firmware behaviour rather than something to work around in ladder. Have the project file and a Data View screenshot ready before you call.

FAQ

Can I reset a CLICK off-delay timer before it finishes counting?

No. The accumulator is driven only by that timer's own enable rung; no external contact shortens it. Restart the window by toggling the enable rung, and drive the physical output from a separate RESET rung instead of from the timer bit.

Does a SET coil stay on after the input contact opens?

Yes — that is the point of the SET/RESET pair. The output holds until a RESET coil clears it. Whether it also survives a power cycle depends on the retentive range settings in the project, so verify that before commissioning.

Can one timer serve all four outputs instead of four separate timers?

Yes, and it is the better build. Enable a single on-delay timer with the four inputs in series as normally-closed contacts, then OR its done bit into all four reset rungs. Any sensor anywhere retriggers the idle window.

Does rung order matter when the same output has both a SET and a RESET?

Yes. The scan resolves rungs top to bottom and the last one executed wins for that scan. Keep the four set rungs above the timer and the four reset rungs below it, so a new sensor beats a stale latch.

Can I use an interrupt routine for the idle timeout?

There is no reason to. Interrupts are for high-speed input events; a 10-second or 2-minute timeout is orders of magnitude slower than the scan, so a standard timer instruction in the main program handles it.

Back to blog