My wish : Inputs debouncing

[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

[alankilian]

@fcwilt I will be happy to review your merge request for input debouncing.

Seriously, you seem to be the person for the job and many people could use this feature.

[fcwilt]

@alankilian said in My wish : Inputs debouncing:

@fcwilt I will be happy to review your merge request for input debouncing.

Seriously, you seem to be the person for the job and many people could use this feature.

Color me confused.

I made no request for de-bouncing.

I simply tried to make clear that what the OP, @BoA, seems to need, de-bouncing, was not hard to implement.

I have always assumed it was already implemented as mechanical switches are a common element used with these boards.

It seems it may not be and, if that is the case, I find that quite curious.

Frederick