How to Implement PLC Debounce Logic with TON Timers in OLLA Lab

To fix mechanical contact bounce in ladder logic, engineers often use a Timer On-Delay (TON) instruction as a software debounce filter. By setting the preset time slightly longer than the physical bounce duration—typically 20 to 50 ms—the PLC can ignore transient state changes and act only on a stable input.

Mechanical inputs do not switch cleanly, even when the ladder looks clean. A limit switch, pushbutton, or relay contact can physically bounce for roughly 10 to 50 ms before settling, and a PLC scanning every 1 to 10 ms can interpret that one actuation as several separate transitions.

Ampergon Vallis metric: During a 1,000-cycle stress test in OLLA Lab’s simulation mode, a raw mechanical-style limit switch input produced an average of 3.4 false state changes per actuation under injected bounce conditions; applying a 50 ms TON filter removed those false transitions in the simulated sequence without observable sequence delay at the machine level. Methodology: n=1,000 input actuation cycles in a single debounce lab scenario, baseline comparator = unfiltered raw boolean input, time window = one test session on 3/24/2026. This supports the value of TON-based debounce in a controlled simulation workflow. It does not claim universal field performance across all hardware, scan times, or sensor technologies.

That distinction matters. Syntax is not the same as deployability, and noisy inputs are where that confusion usually gets expensive.

Mechanical contact bounce is a physical effect, not a programming mistake. When metal contacts inside a switch or relay change state, they often vibrate briefly before reaching a stable open or closed condition. In a 24 VDC control circuit, that produces a rapid series of momentary ON/OFF transitions rather than one clean edge.

The practical problem appears when the PLC is faster than the hardware. If the input device bounces for 30 ms and the controller scans every 5 ms, the program may read that single press as multiple state changes. The PLC is not malfunctioning; it is doing exactly what it was asked to do, just faster than the mechanics can behave cleanly.

This matters most in logic that reacts to edges or counts events, including:

• box counting on conveyors
• state-machine step advancement
• lead/lag alternation triggers
• fault latching
• start/stop pushbutton logic
• proof-of-position feedbacks from limit switches

A noisy contact can create:

• false counts
• premature sequence advancement
• duplicate commands
• race conditions between rungs
• nuisance alarms
• intermittent commissioning failures

Why does the scan cycle make bounce visible?

The scan cycle creates the conflict between physical settling time and logical interpretation. In a standard PLC scan, the controller reads inputs, executes logic, updates outputs, and repeats. If the input image captures several bounce transitions across successive scans, the program can treat them as legitimate changes.

This is why debounce is not cosmetic cleanup. It is a timing control measure that hardens logic against known electromechanical behavior before that behavior reaches the rest of the program.

A TON instruction filters bounce by requiring the input to remain continuously TRUE for a defined time before the output becomes TRUE. If the input drops out before the preset time expires, the timer resets and the output never turns on.

That is the core mechanism. A bouncing input repeatedly interrupts the timer, so the elapsed time never reaches the threshold. Only a stable signal survives long enough to pass through.

In IEC 61131-3 terms, the TON behaves as a deterministic software gate:

- unstable input: timer starts, resets, starts again, never qualifies - stable input: timer runs continuously to preset - qualified state: output bit turns TRUE and can be used by downstream logic

A useful correction here: debounce is not the same as adding delay everywhere. Good debounce adds a small, bounded qualification delay only where the input physics require it.

Standard IEC 61131-3 TON parameters

For debounce logic, the TON parameters should be understood operationally:

- IN (Input): the raw sensor or switch signal entering the timer Example: `Raw_Sensor_Input`

- PT (Preset Time): the minimum continuous TRUE duration required to accept the signal Example: `T#50ms`

- Q (Output): the debounced, stable boolean used by the rest of the program Example: `Sensor_01_Debounced`

- ET (Elapsed Time): the accumulated time while `IN` remains TRUE; it resets immediately if `IN` goes FALSE before reaching `PT`

For software debounce, `ET` is the tell. If it keeps collapsing back to zero during a noisy transition, the filter is doing its job.

What preset time should you use for debounce?

The preset time should exceed the expected bounce duration but remain short enough not to impair machine response. For many mechanical contacts, a practical starting range is 20 to 50 ms, then adjusted based on device behavior, scan time, and process sensitivity.

Use a shorter preset when:

• the device is relatively clean
• the machine requires fast response
• the input is not safety-critical and is easy to observe

Use a longer preset when:

• the contact is mechanically rough or aged
• the environment is electrically noisy
• false transitions create sequence faults or count errors
• the process can tolerate a slightly slower qualification

The right number is not guessed. It is observed, tested, and justified.

The standard structure is simple: place the raw input on a rung that drives a TON, then use the timer’s `Q` output as the only accepted version of that signal elsewhere in the program.

That separation is important. The raw input belongs at the boundary. The debounced bit belongs in the sequence.

Rung 1: The debounce timer `|---[ Raw_Sensor_Input ]---------------------[ TON: Debounce_Timer, PT: 50ms ]---|`

Rung 2: The action logic using the clean signal `|---[ Debounce_Timer.Q ]---------------------( Motor_Start_Sequence )------------|`

This is the minimum viable debounce pattern.

Why should downstream logic use the debounced bit instead of the raw input?

Downstream logic should use only the debounced bit because mixed usage defeats the filter. If one rung uses `Raw_Sensor_Input` and another uses `Debounce_Timer.Q`, the program now contains two competing interpretations of the same device.

That creates avoidable inconsistency:

• one part of the sequence reacts instantly
• another waits for qualification
• event order becomes scan-dependent
• troubleshooting becomes less clear

A cleaner pattern is:

• raw input enters one filter rung
• filtered result is named clearly
• all sequence logic references the filtered tag

A compact engineering evidence pattern for debounce validation

If you want to demonstrate control judgment, document debounce work as engineering evidence rather than screenshots. Use this structure:

Example: conveyor photoeye or mechanical limit switch driving a count or sequence transition.

Example: one physical actuation produces one logical event and no duplicate transition.

That is what simulation-ready should mean in practice: you can prove, observe, diagnose, and harden control logic against realistic behavior before it reaches a live process.

1. System Description
2. Operational definition of correct behavior
3. Ladder logic and simulated equipment state Show the raw input, TON rung, debounced output, and the machine state affected by that output.
4. The injected fault case Introduce bounce or rapid toggling on the raw input.
5. The revision made Add or tune the TON preset, then route sequence logic to the filtered bit.
6. Lessons learned State what changed, why it worked, and what process risk it removed.

You test debounce logic safely by injecting unstable input behavior, watching the timer response, and confirming that only the filtered bit is allowed to drive the sequence. OLLA Lab is useful here because it provides a browser-based ladder editor, simulation mode, and variable visibility without requiring live hardware.

In operational terms, the platform acts as a bounded validation environment. It lets you compare what the input is doing, what the timer is doing, and what the machine logic is allowed to believe.

Step-by-step debounce test workflow in OLLA Lab

1. Create or open a ladder project Build a simple sequence with one raw boolean input and one output action.
2. Add the TON debounce rung Use the raw input as `IN`, assign a preset such as `T#50ms`, and create a clear filtered tag from `Q`.
3. Route the action logic through the filtered output Do not let the raw input drive the machine action directly.
4. Run simulation mode Start the logic and open the Variables Panel.
5. Toggle the raw input rapidly Simulate bounce by switching the input on and off in quick succession.
6. Watch `ET` in real time Confirm that the elapsed time starts accumulating, then resets when the input drops before reaching `PT`.
7. Confirm `Q` remains FALSE during noise The debounced output should not turn TRUE until the input stays stable for the full preset duration.
8. Hold the input TRUE long enough to qualify Verify that `Q` turns TRUE only after the timer reaches preset.
9. Observe the downstream machine state Confirm that the output or sequence transition occurs once, not multiple times.

This is where OLLA Lab becomes operationally useful. You are not just drawing a rung; you are validating the rung against a behavior model and checking whether the logic survives a realistic fault pattern.

What should you watch in the Variables Panel?

The Variables Panel should be used to correlate raw input behavior, timer state, and sequence response. For a debounce test, monitor at least:

• the raw boolean input
• the TON `ET` value
• the TON `Q` output
• the downstream output or state bit
• any counter or step-transition bit that would be vulnerable to double-triggering

The key observation is straightforward: if the raw input chatters but `Q` stays stable until the signal qualifies, the debounce logic is working as intended.

What does this prove, and what does it not prove?

A simulation-based debounce test proves that the ladder structure and timing logic behave correctly under the injected conditions. It helps validate cause-and-effect, timer reset behavior, and sequence robustness before hardware is involved.

It does not prove:

• field wiring quality
• actual sensor health
• EMC performance
• safety integrity
• final site commissioning readiness by itself

That boundary matters. Simulation is where you remove logical errors cheaply. Site work is where the remaining real-world issues appear.

Software debounce is appropriate when the problem is a discrete input that changes state too noisily for the scan cycle and the application can tolerate a small qualification delay. It is especially practical for standard mechanical contacts in non-safety sequence logic.

Use software debounce when:

• the input device is mechanical
• false transitions are intermittent but reproducible
• you need transparent timing behavior in the PLC program
• you want the filter to be visible, adjustable, and testable

Consider hardware filtering or alternate sensing when:

• the noise source is electrical rather than mechanical
• the signal path is badly wired or poorly shielded
• the application requires very fast edge detection
• the controller or I/O module already provides configurable input filtering
• the function is safety-related and requires design within the appropriate safety framework

A TON is not a universal cure. It is a standard fix for a specific class of problem.

The most common mistake is filtering too late. If the raw signal is allowed to increment a counter, advance a sequencer, or latch a fault before the debounce block, the damage is already done.

Other common mistakes include:

• using the raw input in some rungs and the filtered bit in others
• choosing a preset time without observing the actual behavior
• setting the preset so high that machine response becomes sluggish
• applying debounce to every input indiscriminately
• confusing contact bounce with analog noise, wiring faults, or scan-order bugs

A practical rule is simple: filter at the boundary, name the filtered bit clearly, and use it consistently.

A debounce fix should be documented as a bounded logic revision tied to an observed fault mode. Good documentation makes the reasoning reviewable by another engineer, technician, or integrator.

Include:

• the affected device tag and physical function
• the observed symptom
• the scan-time context if relevant
• the chosen timer preset and why
• the revised ladder structure
• the test method used
• the acceptance criterion
• the result after revision

For example:

- Device: `LS_101_InfeedStop` - Observed symptom: duplicate step advance during single mechanical actuation - Revision: added TON debounce, `PT = T#40ms` - Acceptance criterion: one actuation produces one sequence transition - Validation: simulated rapid toggling in OLLA Lab, observed `ET` resets and single qualified `Q`

That is the level of evidence that survives handoff.

Mechanical bounce is a hardware fact, but false triggering is a logic design choice. A TON-based debounce rung is the standard software method for requiring a signal to remain stable before the PLC accepts it, and in many applications a 20 to 50 ms preset is a sound starting range.

The larger point is not just how to place the timer. It is how to validate the behavior. An engineer who is prepared for commissioning can show the raw signal, the filter behavior, the downstream effect, the injected fault, and the revision that removed it. That is the difference between knowing ladder syntax and being ready to trust logic near a live process.

- Up (Pillar Hub): Explore Pillar guidance - Across: Related article 1 - Across: Related article 2 - Down (Commercial/CTA): Build your next project in OLLA Lab

- IEC 61131-3 (Programmable Controllers, Part 3) - NFPA 79 Electrical Standard for Industrial Machinery - Omron Technical Guide: Relay and switch contact bounce basics - Cherry MX switch technology resources