Due to an increase in the use of solid-state sensors like proximity switches, you’re less likely to see this Ladder Logic Programming Pattern, but the Debounce pattern still comes in handy on many projects:
Debounce
The Debounce pattern is useful when you’re dealing with “dry contact” inputs that might be prone to “bouncing”. On circuit closure the contacts can bounce, which may cause the input to oscillate between the on and off states temporarily. The input can also oscillate when when the contacts open because of arcing. Electrical noise from nearby high current conductors can actually induce electrical pulses in your low voltage inputs that might fool your logic into thinking the input is in the opposite state for a very brief duration.
The Debounce pattern is a variant of the State Coil pattern. In this case we use a delay on timer as the Trigger of the coil. This timer “makes sure” that the input is really on before we change the state of our Memory coil. The coil then seals itself in. The delay off timer is used to make sure that the input is really off before we allow the seal in circuit of the coil to be broken.
The setpoint times for the timers can be modified to suit the situation. If the Debounce pattern is being used to reject electrical noise, then the timers can probably be shortened to a few milliseconds, but if the problem is mechanical contact bounce then 50 or 100 ms (or even longer) might be necessary.
The Debounce pattern has some disadvantages: first, it delays the response time of the machine when reacting to this input. We want most machines to run as fast as possible, and we want to avoid unnecessary delays. Second, it consumes timers, which is more of a concern on older PLCs which have limited resources. Third, it complicates the logic.
Some programmers have gone so far as to add a Debounce to every single input on the machine. Due to the disadvantages I just listed, I would consider blindly adding Debounce logic to be an anti-pattern. I suggest you only use this pattern when you know you need it, or where there’s a high likelihood of needing it based on past experience.
In most cases Debounce logic can be avoided with some simple alternatives. First, use solid state and/or good quality sensors and switches where possible, which are less likely to bounce. Second, route high current wires on the machine in such a way that they don’t run in parallel with the low current control wiring. Third, check to see if your input cards have a filter function that you can turn on or adjust. The filter can be used to filter out high frequency (short duration) pulses from spurious electrical noise.
The Debounce pattern is often combined with the Input Map pattern.
More Patterns of Ladder Logic Programming.
You can simplify this DE-bounce logic and you won’t be sacrificing time the machine responds.
Use the button to start a Time off Timer. Using a One Shot will eliminate a problem if the operator holds the button down but actually not needed as the timer timing bit examine off instruction takes care of that.
(Button ) (One Shot) Timer Timing Time Off Timer
—] [———–——-(ONS)————————]/[———-———-TOF —–
Off Timer Enable Bit
—-—] [—————————–(Item controlled by button)
The timer starts as soon as the operator presses the button and as long as it is timing a bounce will not be recognized.
The ONS (One Shot)and the timer timing bit will allow the the timer to start timing immediately even if the operator holds the button down.
Set the timer for the lowest value that makes sense for the particular operation. I use 1 second defined as .01 time base x 100.
This does what you are suggesting much more efficiently.
David
@David – This isn’t equivalent.
Your logic creates a debounced one-shot when you press the button. The original logic can work for a maintained button (such as a “Jog” button) where the signal needs to stay on for as long as the operator holds the button in.
Also, remember a contact can bounce both during the initial press, and during the release. Using your logic, if the operator holds the button for 2 seconds, and then the contact bounces on the release, it’ll trigger a second one-shot signal, which is almost certainly not what the operator is expecting, and it will only happen once the switch becomes bouncy.
Furthermore, the original logic prevents electrical noise (like a single scan where the input is high) from triggering the output, because it has to be “really on” for the TON duration before turning on the output. Your logic triggers the output immediately, which means noise on the line could cause it to trigger the equipment.
Signal bounce can and does occur in proximity switches quite often. The switch might be mounted in a way that detecting the ferric surface is right on the borderline between being detectable and not detectable. Corrosion in connector pins, loose connections, corrosion on the surface the sensor is detecting, damaged cables, all of these are things I have personally seen cause Proximity switches to send a “bouncy” signal.
One quick question: why feed the raw input to both timers and then use state logic? Wouldn’t the exact same behaviour be accomplished with a simple TON->TOF cascade?
Input to TON produces Delay On. Delay On to TOF produces Debounced Input directly, no other logic needed.
Maybe I’m missing something here?
@Mislav No, it wouldn’t. I’d delete the comment if I could. 🙂
It would just delay the output’s drop to zero, but it wouldn’t ignore short drops, which is the whole point.
@Mislav – your comment highlights a very common mistake when implementing a debounce (that I’ve made before too) so I’m going to leave your comment here. You’re correct: the point of the debounce is to make sure the state changed, not just to delay the state change.
Is it possible that in your figure there is a little mistake?
The way it is now, as soon as the input drops to zero, even briefly, it will reset both delay timers and the debounced input will become zero immediately?
I think both the input contact in the second rung and the delay of timer in the third rung needs to be NC for this to work properly?
@Sven – the second timer is a delay-off timer, which functions differently. It turns on immediately when the input turns on, but stays on for (in this case) 100 ms after the input turns off. You are correct that if you want to write this with only delay-on timers, then you’d have to have one timer checking how long it’s been on, and another checking how long it’s been off.
@Scott
I totally missed that! Thank you for explaining!
Pingback: TechTalk – RSLogix 5000 : What is Debouncing & How To Add In PLC Logic – Xybenertics
I use this circuit often for analog devices as well (such as an analog level switch) or for large tank levels switches.
Often the water is turbulent and having the timers ‘de-bounces’ the actual liquid waves in the tank tripping a switch on / off.
The logic posted is not ideal. I can’t speak for other PLCs, but Allen-Bradley PLCs will reset the debounced bit on the transition into RUN mode. This means you will have to wait for the “Debounce ON” timer to time out before the output bit is again turned on. This might cause unintentional actions.
Also there may be an issue with alarming. In a tank with several probes, for instance, each probe having different debounce times, you could trigger “illogical level” alarms, when no such state exists.
The way I do it is to have 2 Timer ON, each driven by the opposite polarity of the probe or input being debounced. The Timer’s DN bits then Set, and Reset a RETENTIVE output, so that on a PLC restart you are always going to see the debounced state that the input was in before. No unintentional states can prevail.