RE: Prusa XL with Klipper
One thing I missed in my edit window. I didn't say we were rebranding, what I said was that we moved servers (I also upgraded the tech stack btw.), which is why the site is a lot faster now. Either way, I'd love to see you over there sharing your projects and checking out the tools I'm building. More makers on the platform makes it better for everyone. 🙂
RE: Prusa XL with Klipper
Thank you for the quick response. This is to keep you informed of the work in progress. I did solve some of the issues, and feel getting closer.
1. led effects: Solved. The led strips are not connected at the moment, because of the new height, the cables are too short. But Following your advices, I added the [include led_effects.cfg] in printer.cfg and it doesn't throw errors about it anymore 🙂 So, first point closed! 👍
2. The filament detector (bypassed 🙃 ): as it is not calibrated yet (will discover how to later 😏 ) So as suggested, disabling did the trick. I did with command:
$ M591 S0 // Filament runout detection DISABLED $ SHOW_FILAMENT_SENSORS // Filament runout detection: DISABLED // Tool sensors (load/unload confirmation): // T0: has_filament raw= 683 cal=nins=3674 ins=407 // Side sensors (PRIMARY runout detection): // T0: no_filament raw= 3362 cal=nins=1374 ins=772 // T1: not_calibrated raw= 2801 cal=NOT CALIBRATED // T2: not_calibrated raw= 2745 cal=NOT CALIBRATED // T3: not_calibrated raw= 1713 cal=NOT CALIBRATED // T4: not_calibrated raw= 2015 cal=NOT CALIBRATED
3. The print... Now the terminal log is much more readable 🧐 !
echo: Starting print - Bed:85.0C Tool:T0 Temp:230.0C // Bed area: (152,142)-(208,218), 6/16 bedlets enabled // Bedlet grid (* = enabled): // Y 0- 90: . . . . // Y 90-180: * * * * // Y180-270: . * * . // Y270-360: . . . . // Bed target: 85.0C (adaptive: 6/16 bedlets) echo: Homing XY... // Run Current: 0.74A Hold Current: 0.65A // Run Current: 0.74A Hold Current: 0.65A // Run Current: 0.65A Hold Current: 0.65A // Run Current: 0.65A Hold Current: 0.65A echo: Picking T0 for probing... // T0 already picked! // T0 hotend target: 150C echo: Waiting for bed 85.0C and T0 probe temp 150C... // Waiting for bed to reach 85.0C (adaptive: 6/16)... // Bed at 83.2C (enabled avg) // T0 heating to 150C... // T0 reached 149C (target 150C) echo: Homing Z with loadcell... // Run Current: 0.74A Hold Current: 0.65A // Run Current: 0.74A Hold Current: 0.65A // Run Current: 0.65A Hold Current: 0.65A // Run Current: 0.65A Hold Current: 0.65A // T0 already picked! // LOADCELL_PROBE: trsync-based continuous motion // fast=125.0g, slow=125.0g, speed=5.0mm/s // Enabling loadcell... // Taring loadcell... // Tare offset: 733598 (14085.1g) // === PHASE 1: Fast approach === // Threshold: 125.0g (raw=-6510) // === FAST: Z355.00 -> Z-9.00 @ 5.0mm/s === // CONTACT at Z=322.1450 // Backing off 2.0mm... // Re-taring for slow probe... // === PHASE 2: Slow approach === // Threshold: 125.0g (raw=-6510) // === SLOW: Z324.14 -> Z-9.00 @ 0.5mm/s === // CONTACT at Z=322.7475 // PROBE COMPLETE: Z=322.7475 echo: Z homed via loadcell probe echo: Bed mesh (4x4) for area (151.758,141.758) to (208.242,218.242) !! Loadcell triggered before probe - check tare !! Loadcell triggered before probe - check tare echo: Print cancelled // T0 hotend target: 0C // Bed area cleared - all 16 bedlets at 85.0C // Bed target: 0.0C (all 16 bedlets) // T0 fan: 0/255 (0%) // Dwarf 1 target temp set to 0.0C // Extrude below minimum temp // See the 'min_extrude_temp' config option for details !! Extrude below minimum temp // Extrude below minimum temp // See the 'min_extrude_temp' config option for details !! Extrude below minimum temp
If I read it correctly, it seems that the minimal temp error is just a consequence of a failed probing and print cancellation.
This part of the log seems to point the problem:
// Taring loadcell... // Tare offset: 733598 (14085.1g) // === PHASE 1: Fast approach === // Threshold: 125.0g (raw=-6510) // === FAST: Z355.00 -> Z-9.00 @ 5.0mm/s === // CONTACT at Z=322.1450 // Backing off 2.0mm... // Re-taring for slow probe... // === PHASE 2: Slow approach === // Threshold: 125.0g (raw=-6510) // === SLOW: Z324.14 -> Z-9.00 @ 0.5mm/s === // CONTACT at Z=322.7475 // PROBE COMPLETE: Z=322.7475 echo: Z homed via loadcell probe echo: Bed mesh (4x4) for area (151.758,141.758) to (208.242,218.242) !! Loadcell triggered before probe - check tare
Either the Z axis direction is reversed or not correctly calibrated at 0 when on top... Since Z axis is goint in the right direction and numbers going from 355 (not the full size) to 322, the second guess is more logic. I'll figure out the z calibration issue and come back
The klippy.log is not giving more info except that the first exception has triggered the next ones.
Traceback (most recent call last):
File "/home/pi/klipper/klippy/extras/puppy_bootloader.py", line 565, in run_probe
epos = phoming.probing_move(self._endstop, pos, speed)
File "/home/pi/klipper/klippy/extras/homing.py", line 275, in probing_move
raise self.printer.command_error(
"Probe triggered prior to movement")
gcode.CommandError: Probe triggered prior to movement
...
During handling of the above exception, another exception occurred:
gcode.CommandError: Loadcell triggered before probe - check tare
...
During handling of the above exception, another exception occurred:
gcode.CommandError: Extrude below minimum temp
Good day!
RE: Prusa XL with Klipper
Your Z-calibration hunch is right. The first Z-home probe actually succeeded (contact at 322.7475), so your loadcell and probing hardware are working. The issue happens specifically when bed mesh starts — it's triggering as soon as the next probe begins, before any motion.
One concrete thing to change for a height-modified XL: - [stepper_z] position_max — raise this to your actual Z travel. Stock is 360; if your build is taller, match that.
Do NOT change position_endstop (must stay 0 — the comment in your printer.cfg explains why: Z=0 = nozzle at bed surface with loadcell probing). Do NOT change position_min beyond -9 unless you know why.
Quick diagnostic: try setting [bed_mesh] horizontal_move_z to 5 (from default 0.5). If bed mesh probes succeed, Z-reference is fine and the issue is a small tare drift between Z-home and mesh-start. If it still triggers, there's a bigger Z-reference issue to hunt down.
Your successful Z-home contact tells me the sensor works — we're narrowing down to what specifically changes between probe #1 and the first bed-mesh probe.
RE: Prusa XL with Klipper
Great news! The first print is out with klipper and actual KlipperXL flavour ! There was some issues with the Z probing and I had to change small things in the macros.
For the height, in printer.cfg, [stepper_z].position_max is set to 720. But unfortunately, the value 370 is the default value at some places (e.g.: LOADCELL_PROBE) or hardcoded to 355 in [homing_override]. This is not an issue at the moment because the bed is not often below 5-10 cm. But yeah, you're right 🙂
I also noticed that the LOADCELL_PROBE is not lowering enough the bed (my setup) and it can hurt in some cases. This happens when BED_MESH_CALIBRATE is done more than once in a row. To avoid that, I added a little backoff before and after the command execution. I suspect it may be due to the modified hardware setup. I had to put some spacers because of the change of threaded rod and nut.
Thoses HW changes also has impact on the bed calibration and level. The plate is not competely at level and toolhead is about 5mm closer than unmodified printer when hitting the top. So the safe clearance must be greater for this setup.
I think, PRUSA_Z_LEVEL canbe improved a little to avoid having a very long crash duration potentially equivalent to the "whole" distance when the bed is quite near to the top. I don't remember how Prusa FW behaves, but i think, in calibration sequence, that it does a Z homing (with loadcell) first and then a Z-level. It's also possible that there is a check on current level limit.
I also changed cmd_TOOL_PAK to be able to use single non-dockable toolhead and using "dwarf" property set to 1 from [extruder] section to signify the use of only one dwarf :
def cmd_TOOL_PARK(self, gcmd):
...
# around line 7260
if not parked and self.static_dwarf :
self.gcode.respond_info(
f"Static Tool is not dockable [extruder] dwarf: 1. ")
return
...
@racoutlaw many thanks for your support on this. I surely have to improve the hardware and your KlipperXL project was a really good push for this. Only drawback, I think it quite difficult to debug and follow actions (cfg, py, overrides, variable read ...) but it is how klipper is made.
Have a nice week.
RE: Prusa XL with Klipper
Great to see it printing! And nice catch on the two hardcoded values in KlipperXL:
1. LOADCELL_PROBE MAX_Z defaults to hardcoded 370 (puppy_bootloader.py:6471) — should read stepper_z.position_max dynamically. 2. SET_KINEMATIC_POSITION Z=355 hardcoded in homing_override (printer.cfg:283) — same fix, should reference position_max.
Will look into both later down the road and see what can be done to make modified-height builds work out of the box. If you want to share the exact changes you made + your BED_MESH_CALIBRATE backoff tweak, I'll keep them on hand for whenever I circle back.
Your cmd_TOOL_PARK change + dwarf: 1 flag in [extruder] for single-non-dockable-tool setups is a nice idea too — KlipperXL currently assumes 5 dockable tools. Worth considering for a future update if I get to it.
On your PRUSA_Z_LEVEL thought — current level crash window is the full probe travel. A max-delta clamp would be safer on modified builds. Something to look at down the road.
Debugging the multi-layer stack (cfg → macros → py → override → variables) is rough — that's more Klipper's architecture than anything easy to fix. Glad you pushed through.
Thanks for the detailed report — real-world use like yours is exactly what surfaces these issues.
RE: Prusa XL with Klipper
Great news! The first print is out with klipper and actual KlipperXL flavour ! There was some issues with the Z probing and I had to change small things in the macros.
@j2n-d4l , please post your modifications on github: https://github.com/racoutlaw/KlipperXL/issues
so everybody following the project can see them
RE:
Shameless plug: My main issue with Klipper is the need to restart on code changes, losing homing state which is particularly annoying in a toolchanger.
Enter "KlipperHotload" - my project - to (re)compile Python code on the fly. For what I need, it's a gamechanger, I will probably stop using GCODE files and code everything I do in Python.
In a nutshell (see README in above link) it provides one macro - I picked the letter "U" as it's not used in GCODE -
U PATH={CONFIG}/myCodeDir FILE=myCodeFile.py FUN=myFunction SOME_ARG_TO_FUN=123 SOME_OTHER_ARG=456
...to run a given function from a given file, passing arguments (where {CONFIG} interpolates to the directory of printer.cfg).
There are a few tricks built in to assist with keeping GCODE concise, e.g. PATH and FILE may need to be set only once, the last value becomes default.If only a single function is required, it collapses to
U SOME_ARG_TO_FUN=123 SOME_OTHER_ARG=456
...or if I don't need arguments just
U
which is arguably as short as it gets 🙂
Speaking of "short", the whole package is essentially a single ~200 line file in klipper/klippy/extras plus tests directory.
I hope it's useful...
RE: Prusa XL with Klipper
New KlipperXL feature: LED Stroboscope for belt tension tuning
Just shipped a stroboscope feature that uses the XL's side LED strip white channel to visualize belt vibrations — similar to the belt tension tool in stock Prusa firmware. Handy for tuning the X and Y belts evenly.
What it does
When you pulse a bright LED at the same frequency a belt is vibrating, the belt's movement appears to "freeze" in place — you can actually see the standing-wave pattern on the belt. Sweep the strobe frequency until the pattern stops moving, and you've found the belt's resonance frequency.
How to use it
Two new button macros show up in Fluidd/Mainsail:
- STROBE_BELT — starts the strobe at 75 Hz / ~14% duty (Prusa defaults). Stops any running LED effects automatically so they don't fight the strobe. - STROBE_OFF — stops the strobe and restores the idle LED effect. No FIRMWARE_RESTART needed.
Override the defaults for sweeping: STROBE_BELT FREQ=90 STROBE_BELT FREQ=120 DUTY=40
Direct commands also available: STROBE_START FREQ=75 DUTY=35 / STROBE_STOP.
What the frequency tells you about your belts
Pluck a belt (or let the motors run at a slow steady speed that excites belt vibration). Sweep the strobe frequency from ~60 Hz upward. The frequency where the standing wave on the belt appears frozen = that belt's resonance frequency.
- Higher frequency = tighter belt - Lower frequency = looser belt - Both X belts (or both Y belts on dual-motor axes) should resonate at the same frequency — that's the goal. - If one is noticeably higher than the other, that belt is tighter — loosen it or tighten the other side.
Prusa's reference range for the XL is 60–130 Hz at 13.7% duty (35/255), which matches what this implementation defaults to.
Behind the scenes
The strobe uses the STM32's TIM13 timer running autonomously — once started, the MCU handles timing with no host involvement, so Klipper's Python-side load has no effect on strobe jitter. PG14 (SPI6 MOSI) is bit-banged for the WS2812 data, with the PE9 hardware mux ensuring the signal reaches the LED strip and not the display. On stop, the pin mode is restored so regular LED effects resume working immediately.
Install: pull latest KlipperXL, run the install script, flash the new klipper.bbf. Buttons appear after a FIRMWARE_RESTART.