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.

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

Posted by: @j2n-d4l

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

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

For the height, in printer.cfg, .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 . 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 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  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.

One concrete thing to change for a height-modified XL: - 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 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.

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 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!

TinkerAtlas isn't first and foremost a repo site though. It's a social platform for makers, with additional tools like project hosting (KlipperXL being one example), printer maintenance tracking, and soon giveaway tools for maker streamers, among other things. I'm trying to build a good home for our community. Nothing sketchy about it, there's no spam, and digest emails can be adjusted to whatever frequency you want or unsubscribed from entirely.

As for needing an account to download, that's because TinkerAtlas is a community platform, not just a file host. It's the same reason you need an account on GitHub or Printables to interact with projects there.

I've been working on it every single day since I started in July 2025, no days off. We're still in beta because I keep finding features I want to build.

On YouTube you asked if I was the author of this project. I'm not, I said as much. RacOutlaw is a friend of mine and I wanted to help him get the word out about KlipperXL. You also asked whether the TinkerAtlas link was more of a promotion rather than pointing to the original GitHub location. I said it was hosted on TinkerAtlas because as far as I knew, that was the original location. The GitHub repo was supposed to be a private backup, not the public-facing home for the project.

Posted by: @jsawyer

With the recent supply chain attacks, etc. any repository that is not one of the established ones is looked at with some suspicion.

TinkerAtlas also feels kind of pushy. You can't download without joining and when you do join there is a fair amount of spam that comes with it.

It didn't help that when I posted a reply to the video asking if they were or were associated with the creator, the response was that they were in the process of rebranding and did not say anything about you or an association to you.

Picking a tool takes more time then stock fw (printer pauses after each move)...

I also submitted some issues to the tracker : https://github.com/racoutlaw/KlipperXL/issues and some of them were resolved by @racoutlaw. Enclosure fan is not controlable (I haven't found the right PIN or method).

Here is a video showing that extruder buttons work on KlipperXL:
https://youtu.be/lyLMGDZ9RaY?si=EENXh_Bsb95wbDHx