Proposal: Button Debounce

Features
25

Yes, I have the v1.1 board and the sensor with the metal body, but I have seen issues too.

Just for clarity and the discussion about debouncing:

Debouncing:
In my understanding, this refers to either:

  • Killing events that appear too close to each other or too frequently, but are essentially a wanted event.
  • Suppressing unstable events, e.g., during a switching / toggling process, where some time is needed until a stable new condition is reached.

False positives:
Contrary to debouncing, here I’m trying to suppress false positive events that are, for example, caused by too sensitive probes. This means the probe / sensor is causing an event, although the condition does not actually exist.

While I think the code proposed by @garethky and @Arksine is handling both, my understanding is that the MagnetoX is rather suffering from the second type.

26

can you test it out?

1 Like
27

I can try, although my MagnetoX is suffering from this very rarely and I do not know a way to reproduce it reliably. Maybe @EmperorArthur has the old version of the filament switch, which is more susceptible.

1 Like
28

I have a newer version of the printer, so doubt it. It did come from the factory with this macro to stop the behavior, which I’ll disable.

I can, but it may take me a day or two. Checking to make sure mainline works right now. Peopoly “fixed” a CAN issue by just commenting out the “too far in the past” check.

Edit: I was wrong about why, and it seems they had a good reason to do so.

29

This is absolutely not related to any CAN issue. This is related to the extreme step-rates in combination with the external stepper drivers, i.e. the linear motors.
Not the most elegant solution, but likely no other solution available currently.

1 Like
30

So it looks like they are using a button and NOT a filament_switch_sensor:
[gcode_button runout_sensor]

They actually have a filament_switch_sensor that they defined here, but its commented out. So that’s not going to be fixed by the patch unless your config looks different from this one.

31

Yes. That’s why I started this thread in the first place.

I’ll be commenting out the button and macro code, and uncommenting the filament_switch_sensor.

@Sineos Huh. Not the thread for it, but I’d love to discuss that further.

2 Likes
32

I took a look at applying the debounce wrapper to gcode buttons. They have different startup behavior. If you hold a button down and restart klipper the gcode for the button will run on startup. Seems like the most compatible course of action is to emit the debounced events with the time of the initiating button event, not the time it actually runs.

33

Updated branch, you can now debounce gcode buttons and filament switch sensors.

34

@garethky

I’ve modified my sensor so it false triggers if the filament is bent the wrong direction relative to the toolhead, and have been testing your original changes for the last few days.

Using the config below the only negative I’ve noticed is the printer pauses for a few seconds when runout does occur, and that may be something else. Other than that it works great!

[filament_switch_sensor Runout_Sensor]
pause_on_runout: False
runout_gcode: M118 Filament Runout Triggred！
insert_gcode: M118 Filament Inserted!
event_delay: 0.001
debounce_delay: 3
switch_pin: ^MAG_TOOL:gpio29

@Sineos you can replicate the behavior on your printer by replacing the 6mm ball bearing in the sensor with a 5mm one. Just make sure you don’t actually have the sensor triggering pauses as it’s too temperamental for normal use.

2 Likes
35

There should be a 3 second delay between removing the filament and the M118 Filament Runout Triggred! command running. That’s the debounce_delay: 3. Is that what you are seeing?

filament_switch_sensor comes with a built in pause_delay of 0.5s. So that’s an additional half a second before it will run the macro.

Do those two things explain what you are seeing?

36

The 3 seconds is working as expected. Removing and reinserting the filament during the 3 seconds causes the M118 to not trigger.

I mean the toolhead itself stops moving when the M118 is triggered during a print. My suspicion is that is a bug unrelated to the current change, but I will need to revert and perform additional testing.

Edit:

I’ve rigged the sensor to be so finicky that it triggers once every few minutes during printing, even with a 3 second debounce. Since the sensor has a light tied directly to the hardware, I can see the code working as expected and ignoring smaller false triggers.

I will see about capturing some video of the behavior.

37

filament_switch_sensor calls PAUSE, so that’s what stops the toolhead.

38

Per the config document, it shouldn’t when pause_on_runout: False.

I’m referring to a ~1 second pause, not my PAUSE macro being executed.

1 Like
39

This is expected behavior. The runout helper always appends an M400 to the end of the gcode command, so the “pause” you are seeing is a wait for all moves to complete. This is done to guarantee that no additional switch events are triggered while the runout_gcode is executing.

3 Likes
40

Ahh, that makes sense. It should probably be documented in the configuration section, but it answers my confusion here.

@garathky

I have confirmed the latest patch does work for the runout sensor.

2 Likes
41

Ok, I posted a PR:

3 Likes