Re: [Emc-users] switch debounce experiment

[Erik Christiansen]

On 26.03.19 10:38, Chris Albertson wrote:
> A very basic question, unlike the hards ones being discussed here but,
> important I think.
> 
> How are people handling switch debouncing on home and limit switches?
> 
> Always in the past, I have treated the microswitch is a SPST device that is
> either open or closed.
> The common terminal is pulled up to Vcc voltage and when the switch closes
> it connects to ground.
> 
> But all my switches have three terminals.

OK, it's about 40 years ago now, but when I did hardware debouncing, it
was with a pair of cross-coupled 2-input NAND gates making a flip-flop,
a pull-up on each switch-connected input, and switch common to ground.
NO and NC went to the two FF inputs. That gave two debouncers per 7400
(74HC00 these days). That _will_ give latency in the nanosecond range,
and very sharp risetimes. N.B. If driving more than a few inches of
wire, buffer the output with a spare gate, otherwise line reflections
can flip the flop, as feedback is from the output. A tri-state buffer
was best practice on a line in the metre range.

It could also be done with two inverters, cross-coupled with resistors,
which then serve as the pull-ups. That gives 3 debouncers per package,
with no extra discrete components. (Or two with an output buffer each.)

Since then it's been software debouncing for me, including a specified
algorithm for the first generation of 2.048 Mb/s PCM trunk 30 channel
pair gain systems introducing digital telephony to Australia. Since it
was debouncing 10 PPS 60:40 rotary dial pulses, mark:space distortion
was an issue - though far less critical than a homing stop. Heck, that
was back in '81 - '82. Those trailblazing systems will be decommissioned
as superseded long ago now. The first used an 8085, the single-chip,
single voltage, version of the 3-chip 8080, yet handled the signalling
protocol with only 62.5 uS per channel on average.

> I did some experiments using my
> digital oscilloscope.   The normal
> method causes a long series of "bounces" that continue for some number of
> milliseconds the new method
> makes a near-perfect single pulse square wave.  I see oscillation for only
> about 10 nanoseconds when the switch
> closes and no bounce at all when it opens.
> 
> Common terminal goes to the computer and uses a 10K pull-up.   NC terminal
> goes to Vcc and NO to ground.  I place a 0.1 uF cap from common to ground.
>I notice the cap can "ring" and go below ground.   So I place a small
> diode from common to the ground to protect the uP from negative volts.
>   All the passive components are soldered directly to the switch terminals.

Yes, the fall time is short, but with a high switch current for nS, The
effect on contact life is uncertain, though it could melt the
micro-roughness peak which makes first contact. That then probably smoothes
out, and later contacts are over a surface area which happily absorbs
the nanojoules of energy. A switch replacement after a few years
would not be a great burden, if needed, but a 100 ohm discharge resistor
would allay any concerns, I figure.

> Yes, I know a switch can be de-bounced in software but this introduces
> latency as the software has to keep checking the state of the switch.
>  Reduced latency very much increases the accuracy of the microswitch.
> 
> If you have a digital scope you can try rig up some experiments.   Again
> the only "trick" is to use all three terminals on the switch.

Software can also respond on the first bounce, but your capacitor acts
as a noise filter on the input - without introducing delays, when
shorted by the switch. Can't do that in software. Time is the price of a
virtual solution.

> Yes, I foresaw all kinds of problems but as it turns out in practice I get
> nanosecond level latencies.
> 
> Perhaps everyone already is doing this and I was the last to think of it.
> The switch still actually bounce but in this case, bouncing does not cause
> a change of state.

No, the slow rise time, due to the pull-up timeconstant sees to that -
without introducing any latency.

Yes, it is too easy to forget the hardware path these days.

Erik


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] switch debounce experiment

[Gene Heskett]

On Tuesday 26 March 2019 14:20:58 Bruce Layne wrote:

> On 3/26/19 1:38 PM, Chris Albertson wrote:
> > Yes, I know a switch can be de-bounced in software but this
> > introduces latency as the software has to keep checking the state of
> > the switch. Reduced latency very much increases the accuracy of the
> > microswitch.
>
> Like Steve Ciarcia said in Byte magazine, circa 1978, my favorite
> programming language is SOLDER.  I usually prefer the hardware
> solution as the fastest and often most reliable solution.  However,
> rather than increased responsive time when debouncing a switch in
> software, an intelligent debounce algorithm can greatly reduce the
> response time. For a home or limit switch, you don't really care when
> the switch contacts become stable in the new state.  What you want to
> know is the moment the stable condition changes.  I'd debounce that
> limit switch activation by acting on the initial state change and then
> set a timer to ignore any subsequent bounces.  I definitely wouldn't
> wait for switch contacts to stabilize before acting on the new state. 
> That could be the difference between a machine crashing or not.
>
> Of course, hardware can implement the same debounce strategy, but it's
> easier to wire a bare switch and debounce it in software... even for
> an old hardware guy like me.
>
Unforch, our debounce doesn't work like that, for that, see man 9 edge, 
but it may trip on noise if your grounding layout is poor.
>
>
>
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] switch debounce experiment

[Gene Heskett]

On Tuesday 26 March 2019 13:38:32 Chris Albertson wrote:

> A very basic question, unlike the hards ones being discussed here but,
> important I think.
>
> How are people handling switch debouncing on home and limit switches?
>
We have a debounce module you can put in series with the swtches output. 
very handy where there is a fast base thread, but not so usefull with 
the much slower servo thread. It function is to block a switch status 
change until so many of the threads have passed. With a 1 millisecond 
servo thread, the switch has generally well settled, but in a 30 
microsecnd base thread, it might take a noisy switch 3 or more thread 
cycles to have 3 alike.

> Always in the past, I have treated the microswitch is a SPST device
> that is either open or closed.
> The common terminal is pulled up to Vcc voltage and when the switch
> closes it connects to ground.
>
> But all my switches have three terminals.  I did some experiments
> using my digital oscilloscope.   The normal
> method causes a long series of "bounces" that continue for some number
> of milliseconds the new method
> makes a near-perfect single pulse square wave.  I see oscillation for
> only about 10 nanoseconds when the switch
> closes and no bounce at all when it opens.
>
Chuckle, you need a slower scope. t=rc is generally greater than 10 
nanosecs anyway. The t is self-explanatory, the r is the pullup, and the 
c is a combo of the cable capacitance and its propagation delay at its 
surge impedance.  All of that is generally faster than LCNC anyway so 
its moot 99% of the time, delayed by one thread cycle the remaining 1% 
of the time. Might make .0003" diff to the machine at the speeds the 
machine can move in 1 millisecond.
> Common terminal goes to the computer and uses a 10K pull-up.   NC
> terminal goes to Vcc and NO to ground.  I place a 0.1 uF cap from
> common to ground. I notice the cap can "ring" and go below ground.  
> So I place a small diode from common to the ground to protect the uP
> from negative volts. All the passive components are soldered directly
> to the switch terminals.
>
> Yes, I know a switch can be de-bounced in software but this introduces
> latency as the software has to keep checking the state of the switch.
>  Reduced latency very much increases the accuracy of the microswitch.
>
> If you have a digital scope you can try rig up some experiments.  
> Again the only "trick" is to use all three terminals on the switch.
>
> Yes, I foresaw all kinds of problems but as it turns out in practice I
> get nanosecond level latencies.
>
> Perhaps everyone already is doing this and I was the last to think of
> it. The switch still actually bounce but in this case, bouncing does
> not cause a change of state.


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] switch debounce experiment

[Bruce Layne]

On 3/26/19 1:38 PM, Chris Albertson wrote:
> Yes, I know a switch can be de-bounced in software but this introduces
> latency as the software has to keep checking the state of the switch.
>  Reduced latency very much increases the accuracy of the microswitch.

Like Steve Ciarcia said in Byte magazine, circa 1978, my favorite
programming language is SOLDER.  I usually prefer the hardware solution
as the fastest and often most reliable solution.  However, rather than
increased responsive time when debouncing a switch in software, an
intelligent debounce algorithm can greatly reduce the response time. 
For a home or limit switch, you don't really care when the switch
contacts become stable in the new state.  What you want to know is the
moment the stable condition changes.  I'd debounce that limit switch
activation by acting on the initial state change and then set a timer to
ignore any subsequent bounces.  I definitely wouldn't wait for switch
contacts to stabilize before acting on the new state.  That could be the
difference between a machine crashing or not.

Of course, hardware can implement the same debounce strategy, but it's
easier to wire a bare switch and debounce it in software... even for an
old hardware guy like me.






___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

[Emc-users] switch debounce experiment

[Chris Albertson]

A very basic question, unlike the hards ones being discussed here but,
important I think.

How are people handling switch debouncing on home and limit switches?

Always in the past, I have treated the microswitch is a SPST device that is
either open or closed.
The common terminal is pulled up to Vcc voltage and when the switch closes
it connects to ground.

But all my switches have three terminals.  I did some experiments using my
digital oscilloscope.   The normal
method causes a long series of "bounces" that continue for some number of
milliseconds the new method
makes a near-perfect single pulse square wave.  I see oscillation for only
about 10 nanoseconds when the switch
closes and no bounce at all when it opens.

Common terminal goes to the computer and uses a 10K pull-up.   NC terminal
goes to Vcc and NO to ground.  I place a 0.1 uF cap from common to ground.
   I notice the cap can "ring" and go below ground.   So I place a small
diode from common to the ground to protect the uP from negative volts.
  All the passive components are soldered directly to the switch terminals.

Yes, I know a switch can be de-bounced in software but this introduces
latency as the software has to keep checking the state of the switch.
 Reduced latency very much increases the accuracy of the microswitch.

If you have a digital scope you can try rig up some experiments.   Again
the only "trick" is to use all three terminals on the switch.

Yes, I foresaw all kinds of problems but as it turns out in practice I get
nanosecond level latencies.

Perhaps everyone already is doing this and I was the last to think of it.
The switch still actually bounce but in this case, bouncing does not cause
a change of state.
-- 

Chris Albertson
Redondo Beach, California

___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users