Duet3D Logo Duet3D
    • Tags
    • Documentation
    • Order
    • Register
    • Login

    My wish : Inputs debouncing

    Scheduled Pinned Locked Moved
    Firmware wishlist
    9
    34
    1.9k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • fcwiltundefined
      fcwilt @BoA
      last edited by

      @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

      Printers: a E3D MS/TC setup and a RatRig Hybrid. Using Duet 3 hardware running 3.4.6

      BoAundefined alankilianundefined 3 Replies Last reply Reply Quote 0
      • BoAundefined
        BoA @fcwilt
        last edited by 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.

        fcwiltundefined 1 Reply Last reply Reply Quote 0
        • fcwiltundefined
          fcwilt @BoA
          last edited by 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

          Printers: a E3D MS/TC setup and a RatRig Hybrid. Using Duet 3 hardware running 3.4.6

          1 Reply Last reply Reply Quote 0
          • dc42undefined
            dc42 administrators
            last edited by

            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.

            Duet WiFi hardware designer and firmware engineer
            Please do not ask me for Duet support via PM or email, use the forum
            http://www.escher3d.com, https://miscsolutions.wordpress.com

            BoAundefined 1 Reply Last reply Reply Quote 0
            • alankilianundefined
              alankilian @fcwilt
              last edited by

              @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.

              SeemeCNC Rostock Max V3 converted to V3.2 with a Duet2 Ethernet Firmware 3.2 and SE300

              fcwiltundefined 1 Reply Last reply Reply Quote 0
              • BoAundefined
                BoA @dc42
                last edited by

                @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? 1 Reply Last reply Reply Quote 0
                • A Former User?
                  A Former User @BoA
                  last edited by

                  @BoA said in My wish : Inputs debouncing:

                  @dc42 It looks like it is queued somehow.

                  i recall seeing someting similar ages ago

                  1 Reply Last reply Reply Quote 0
                  • fcwiltundefined
                    fcwilt @alankilian
                    last edited by

                    @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

                    Printers: a E3D MS/TC setup and a RatRig Hybrid. Using Duet 3 hardware running 3.4.6

                    1 Reply Last reply Reply Quote 1
                    • BoAundefined
                      BoA
                      last edited by BoA

                      I connected scope and that are the results.
                      Pressing button - nice a smooth (this is NC, so disconnecting contacts very good behavior)
                      8dcf8603-e8a4-4fb2-ba1e-8aa1b2aa0dbb-obraz.png

                      But releasing button (where contacts meeting again) is.. well... not good, but below 1ms in total.
                      3dcb8f55-aadd-4f03-ab44-34c86774141f-obraz.png

                      1 Reply Last reply Reply Quote 0
                      • o_lampeundefined
                        o_lampe
                        last edited by

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

                        1 Reply Last reply Reply Quote 0
                        • dragonnundefined
                          dragonn
                          last edited by

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

                          o_lampeundefined 1 Reply Last reply Reply Quote 1
                          • o_lampeundefined
                            o_lampe @dragonn
                            last edited by

                            @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? 1 Reply Last reply Reply Quote 0
                            • A Former User?
                              A Former User @o_lampe
                              last edited by

                              @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
                              77e35c48-8120-41e4-9891-b1fee8f6562a-image.png

                              1 Reply Last reply Reply Quote 0
                              • BoAundefined
                                BoA
                                last edited by 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).

                                dragonnundefined 1 Reply Last reply Reply Quote 0
                                • dragonnundefined
                                  dragonn @BoA
                                  last edited by

                                  @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 😜

                                  fcwiltundefined BoAundefined 2 Replies Last reply Reply Quote 0
                                  • fcwiltundefined
                                    fcwilt @dragonn
                                    last edited by

                                    @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

                                    Printers: a E3D MS/TC setup and a RatRig Hybrid. Using Duet 3 hardware running 3.4.6

                                    1 Reply Last reply Reply Quote 0
                                    • dragonnundefined
                                      dragonn
                                      last edited by

                                      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.

                                      fcwiltundefined 1 Reply Last reply Reply Quote 1
                                      • fcwiltundefined
                                        fcwilt @dragonn
                                        last edited by

                                        @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

                                        Printers: a E3D MS/TC setup and a RatRig Hybrid. Using Duet 3 hardware running 3.4.6

                                        alankilianundefined 1 Reply Last reply Reply Quote 0
                                        • alankilianundefined
                                          alankilian @fcwilt
                                          last edited by

                                          @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.

                                          SeemeCNC Rostock Max V3 converted to V3.2 with a Duet2 Ethernet Firmware 3.2 and SE300

                                          fcwiltundefined 1 Reply Last reply Reply Quote 1
                                          • fcwiltundefined
                                            fcwilt @alankilian
                                            last edited by

                                            @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

                                            Printers: a E3D MS/TC setup and a RatRig Hybrid. Using Duet 3 hardware running 3.4.6

                                            1 Reply Last reply Reply Quote 0
                                            • First post
                                              Last post
                                            Unless otherwise noted, all forum content is licensed under CC-BY-SA