My wish : Inputs debouncing

[BoA]

I have a button connected to one of io inputs, and trigger set on it. I noticed that tigger macro is executed more than once, and I suspect this is because lack of debouncing on inputs.

Second option would be to ignore trigger in case it is actually executed.

G4 S1 at the end of trigger macro does not help at all.

[A Former User]

@BoA said in My wish : Inputs debouncing:

Second option would be to ignore trigger in case it is actually executed.

you could perhaps start the macro with a M581 P-1 Tn to disable it immediately, ** if ** that is fast enough. (if needed you could dwell and re-enable it at the end of the macro as well)

[whopping pochard]

It does seem like there ought to be debounce enabled in the software! A very quick search on GitHub showed debounce on rotary encoder input and fan rpm input, but none that I could see associated with basic switch inputs.

There are also debounce ICs if you want to hit it with the hardware hammer.

[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