QUERY_BUTTON unreliable

General Discussion
1

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
2

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

3

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
4

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

-Kevin

5

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)

6

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.

Cheers,
-Kevin