QUERY_BUTTON unreliable

Basic Information:

Printer Model: Voron 2.4 with Toolchanger
MCU / Printerboard: BananaPi CM4 IO (4GB) / Bigtreetech SKR V1.4 / Makerbase Mks Robin Nano V3 / Generic STM32F072

klippy.zip (1.6 MB)

Console_Output.txt (3.8 KB)

Relevant_Sections.txt (8.4 KB)

I have a Macro called _HOME_T0 which basically picks up a Toolhead and than Homes the toolhead to Z=0.

inside the Z-homing procedere I have a runtime check, which querys a button which detects if a tool is present or not. If the tool is presend the tool gets homed, if the tool for whatever reason is not present I do a “safe” homing on a custom position to at least home the carriage without a tool.

the problem is that for whatever reason when calling the macro first time, the inital “tool atached” pin is registered, however the release is not. which means after letting go of the tool, the button is registered as “pressed” even if its not.

Calling the _HOME_T0 Macro a second time everything works.

the funny thing is if I call that macro over and over again, every second time the latest release of the pin does work.

If I just call the macro over and over again it basically goes like this this:

  • Printer startup

  • _HOME_T0 → Tool Pickup → switch registers as pressed, tool homes tool stores → switch registers as pressed (when it is actually released)

  • _HOME_T0 → Toolhead reports switched as pressed, my macro throws a warning (disabled the M102 command inside the check) → Tool Pickup → switch registers as pressed, tool homes tool stores → switch registers as released (which is fine this time!)

  • _HOME_T0 → Tool Pickup → switch registers as pressed, tool homes tool stores → switch registers as pressed (when it is actually released)

  • and so on and so on…

for convienence I stripped out the macros in question and attached them in a second file as well as the klippy.log

I also attached the console Output.

I have absolutely no clue what can be possily wrong.

Help would be appreciated

  • cad435

Have you written the macro yourself or did you download it from somewhere out of the nowhere?

I have written the macro myself, as well as nearly all of my other macros to get up and running with klipper. And gaining a bit of experience.

I am rather experienced with C/C++, had my fair trouble with jinja2 (expression evaluation before actually running code was fairly new to me), but managed to get everything working as intended so far

1 Like

That’s odd. My initial response would be that it sounds like an issue with macro Jinja2 order of execution, but it sounds like you are already aware of those issues. I don’t know what otherwise would cause the symptoms you describe.

The reporting of the button state can be found in klippy/extras/gcode_button.py. The code is fairly simple, so it is not clear how it could be reporting stale values (outside of Jinja2 order of execution issues).


Any suggestion on how to debug that?

I would think the first step is to take the GCODE-commands and look at the microcontroller commands sent as discribed in " Translating gcode files to micro-controller commands"

(Debugging - Klipper documentation)

You could go down to the low-level mcu commands, but I’d guess whatever issue you are having is in the host code. You might be better suited by sprinkling calls to logging.warning() debugging to gcode_button.py, gcode_macro.py, and gcode.py to trace order of execution. The log messages will then show up in the klipper log file.


I was able to reproduce this issue. I have put up a proposed fix at: Fix possible ordering issue if a callback blocks in button handler by KevinOConnor · Pull Request #6440 · Klipper3d/klipper · GitHub


Uhhhh, happy to hear!

Thanks for looking into it!

Are there any tutorials out on how to use the experimental branch?

I’d be more than happy to test this in action.

  • cad435

Typically I ssh into the machine and run something like:
cd ~/klipper ; git fetch ; git checkout origin/work-buttons-20231229 ; sudo service klipper restart


Kevin, thanks for the quick fix. I believe I’m hitting this same issue. Been trying to resolve it for days. I just switched to the work-buttons-20231229 branch, but I get the following error when I restart klipper:

Repeat unhandled exception during run
Traceback (most recent call last):
  File "/home/dburket/klipper/klippy/klippy.py", line 225, in run
  File "/home/dburket/klipper/klippy/reactor.py", line 292, in run
  File "/home/dburket/klipper/klippy/reactor.py", line 340, in _dispatch_loop
    timeout = self._check_timers(eventtime, busy)
  File "/home/dburket/klipper/klippy/reactor.py", line 158, in _check_timers
    t.waketime = waketime = t.callback(eventtime)
  File "/home/dburket/klipper/klippy/reactor.py", line 48, in invoke
    res = self.callback(eventtime)
  File "/home/dburket/klipper/klippy/extras/buttons.py", line 82, in <lambda>
    (lambda c=callback, bt=btime, s=state: c(bt, s)))
TypeError: 'float' object is not callable

Oops. I have updated that PR and rebased it. Hopefully it should be fixed now.


Thank you! That seems to have fixed the issue for me. I’m seeing consistent button behavior now.

I can also confirm this works reliably in the same setup where I first discovered this issue!

Thank you very much! :slight_smile:

When can we expect this fix will be transfered into main branch?
(sorry if this is a stupid question)

Happy new year!

  • cad435

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.