My wish : Inputs debouncing

A Former User

might help to be specific about board and pin in use + type of switch.

the duet2 has filter caps on all the endstop inputs, duet3 lists them as DNP

BoA

@bearer It is DUET3, pin is io8.in
Button type - GQ30PF-11E/G/24V/S - NC contacts used for io pin, and NO for PSU "priming" before M80 executed.

fcwilt

@BoA said in My wish : Inputs debouncing:

@bearer It is DUET3, pin is io8.in
Button type - GQ30PF-11E/G/24V/S - NC contacts used for io pin, and NO for PSU "priming" before M80 executed.

Firmware version?

It's hard to believe that the firmware doesn't de-bounce the inputs - it's simple code.

Frederick

BoA

@fcwilt Firmware 3.2 - running standalone

@fcwilt said in My wish : Inputs debouncing:

It's hard to believe that the firmware doesn't de-bounce the inputs

Perhaps it does. It is a big button, perhaps more bouncy than others. Not sure. But I have trigger executed twice with one push. I might have some spare time this weekend to hook a scope on the pin and see what is going on exactly if that would help.

fcwilt

@BoA Thanks for the info.

It's possible that, if there is de-bounce code, it made an assumption about how long the bouncing would last. There's a trade off - the more bouncing you code for the slower the response time.

It would be interesting to see how your button performs.

Frederick

dc42

AFAIR, changes on an input pin that activates a trigger are already disabled until the trigger macro has finished executing, because that was the intention. But I could be mistaken.

alankilian

@fcwilt said in My wish : Inputs debouncing:

It's hard to believe that the firmware doesn't de-bounce the inputs - it's simple code.

Weeeellllll........ Not simple at all in fact.

Here are two articles about debouncing:
http://www.ganssle.com/debouncing.htm
http://www.ganssle.com/debouncing-pt2.htm

As @fcwilt says, it's a tradeoff between response-time and repetition rate and how long the bounce lasts.

Still, I think it should be possible to implement without using up too much RAM or CPU time.

There's some simple debouncing in the filament monitor code, but it's not configurable.

BoA

@dc42 It looks like it is queued somehow.

My current trigger macro:

M300 P200
if state.gpOut[1].pwm < 1
	M42 P1 S1.0
else
	M42 P1 S0.75

G4 S5

if state.gpOut[1].pwm < 1
	M81 S1
else
	M80

so it should not trigger more often that ~5s, and trigger should not be active when macro executing. Meanwhile I just tested by just pressing button twice - second time about 1s after. And I got a first "beep", and after about 5s second "beep".

So it looks that condition for trigger are checked during macro execution, and second trigger event is somehow queued.

A Former User

@BoA said in My wish : Inputs debouncing:

@dc42 It looks like it is queued somehow.

i recall seeing someting similar ages ago

fcwilt

@alankilian said in My wish : Inputs debouncing:

There's some simple debouncing in the filament monitor code, but it's not configurable.

I thought you said debouncing wasn't simple

Frederick

BoA

I connected scope and that are the results.
Pressing button - nice a smooth (this is NC, so disconnecting contacts very good behavior)

But releasing button (where contacts meeting again) is.. well... not good, but below 1ms in total.

o_lampe

What, if you use the NO button pin? (if available).
The bouncing is filtered at the begin of a macro, as somebody mentioned.

dragonn

Could you just add a capicator parallel to the button?
Sometimes the best solution is doing it in hardware

o_lampe

@dragonn said in My wish : Inputs debouncing:

Could you just add a capicator parallel to the button?
Sometimes the best solution is doing it in hardware

An RC combo would be best

A Former User

@o_lampe said in My wish : Inputs debouncing:

An RC combo would be best

there is already series resistance on the inputs, and a footprint for a cap if so inclined

BoA

I know this can be fixed in hardware, and I know how. The point was to fix it is SW which do not change input pin characteristics. And debouncing is not a rocket science to implement.

Also I am not very happy with though that I would have to take board out just to solder small cap, or even less happy to connect cap. hanging on wires.

But this is wish list, so... that is my wish (granted or not).

dragonn

@BoA said in My wish : Inputs debouncing:

And debouncing is not a rocket science to implement.

That depends on you application architecture, many embedded system without RTOS use something like a simple event loop and implementing debouncing in isn't so simple as it sounds. RRF works on RTOS but it started without it so probably most of the system is a event loop.
It can be of course done, they are many ways to do it. I just wanted to say that something simple from user stand point isn't often so simple in the software

fcwilt

@dragonn said in My wish : Inputs debouncing:

implementing debouncing in isn't so simple as it sounds.

Why do you feel that way?

I developed the firmware for embedded process control systems for many years and the de-bounce code was quite straightforward.

Frederick

dragonn

As I said in the case when using an event loop, you can not just stop in and loop for some cycles and do nothing in the time if you have other things with still need to run. So you need some extra variables for tracking that your are in a debounce state, for how long and when you started and check them in every loop.
I am not saying it is hard, I wanted just to point out that probably is not a "5 minutes" job.

fcwilt

@dragonn said in My wish : Inputs debouncing:

I am not saying it is hard, I wanted just to point out that probably is not a "5 minutes" job.

You are correct - it is a 6.5 minute job.

But with a RTOS it really is a piece of cake - a timed event and two variables per input and your good to go.

Frederick