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.
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
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).
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"
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.
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
self.reactor.run()
File "/home/dburket/klipper/klippy/reactor.py", line 292, in run
g_next.switch()
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
