My wish : Inputs debouncing
-
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.
-
What, if you use the NO button pin? (if available).
The bouncing is filtered at the begin of a macro, as somebody mentioned. -
Could you just add a capicator parallel to the button?
Sometimes the best solution is doing it in hardware -
@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 -
@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
-
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).
-
@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
-
@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
-
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. -
@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
-
@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.
-
@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
-
I was just razzing you a little bit.
Many people here have said it's not an easy thing to do (myself included) and you said it was simple, so I wanted to put you on the spot a little.
I maintain that it will be a LOT of work to build this feature into this firmware for this application.
- GCODEs for configuring which inputs should have debouncing
- GCODE to configure setting for each input that wants debouncing
- Debouncing code that uses almost no resources and works on many different board types and with many different input pins.
- Safety dealing with everyone's misconfigured debouncing settings.
- Changes to the configurator.
- Testing............ For about half of forever.
-
@alankilian said in My wish : Inputs debouncing:
I maintain that it will be a LOT of work to build this feature into this firmware for this application.
I said that code needed for de-bouncing an input was simple and it is.
I never said or meant to imply that the entire effort to add it to the firmware for the family of boards would be a small project.
JOOC why do you think it would need to be a configurable feature?
Frederick
-
@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.
This is where I mistakenly thought you were saying it was a simple job.
I apologize for my misunderstanding.
It's good to have a variety of people discussing this kind of thing. It makes for a better product for everyone.
You are all a great group of peers.
Thank you for letting me get confused at times. -
@alankilian said in My wish : Inputs debouncing:
Thank you for letting me get confused at times.
We all get confused, make mistakes, make assumptions, read things wrong, etc.
It's just the nature of forums.
Generally we as a group get it sorted in the end.
Frederick
-
@fcwilt said in My wish : Inputs debouncing:
JOOC why do you think it would need to be a configurable feature?
Because there will be different kinds of physical switches with different bouncing characteristics as well as different latency needs.
We talked about debouncing in a thread where a member was building an encoder-based filament monitor and it was quite bouncy and needed a LOT of filtering. There was ANOTHER person with a filament monitor that was not quite so bouncy, AND in addition, produced many more pulses-per-second, so the debouncing needed to be significantly shorter in order not to miss genuine inputs.
I still maintain it's medium-to-difficult complexity job to implement something like this. (As a retired embedded-systems firmware and hardware engineer that is.)
-
@alankilian said in My wish : Inputs debouncing:
Because there will be different kinds of physical switches with different bouncing characteristics as well as different latency needs.
I wonder. Filament sensors aside I would not be surprised to find that real world needs, in most cases, would be served by a fixed set of de-bounce specs.
Some things, like filament sensors, would perhaps be best implemented with dedicated hardware.
As a retired embedded-systems firmware and hardware engineer that is.
So we have the same background - we can actually talk to one another!
Frederick
Printers: A FT-5 with the 713 upgrade bits, a custom MarkForged style, a small Utilmaker style, a small CoreXY from kit and a E3D MS/TC setup. Various hotends. Using Duets (2 and 3) running 3.4.6
-
@dragonn said in My wish : Inputs debouncing:
I just wanted to say that something simple from user stand point isn't often so simple in the software
I know. I have over 13+ years of embedded development in my CV. Bare metal, RTOS, Linux, Qnx and VxWorks.
I am just too lazy to setup RRF build at my home computer after all day of work -
@fcwilt said in My wish : Inputs debouncing:
Some things, like filament sensors, would perhaps be best implemented with dedicated hardware.
Is this because their timing need to be consistent?
