So you want some speed, huh?

Before we get into the how to do this, I want to explain what this does at a basic level to make sure it's even worth your time. This allows you to independantly control the acceleration of the X/Y axies on your CoreXY, Cartesian, or (untested) CoreXZ printer. If you aren't one that wants to get more speed, aren't even close to the limits of what you can print with your printer currently, or just don't like to tune your printer, please stop reading now. Hope you have a wonderful day!

Ok, you still with me? Let's get going then.

What does this involve doing at a high level?

Don't run away scared as it is actually quite simple to set up. We'll be pulling in a new file into klipper that offers you a new set of kinematics in software. By default, it won't change anything at all, and just adds new functionality to the defaults, and we'll go through the basics of what you can do with it if you choose to play further with it, but you won't need to understand much of how it actually works to get easy gains.

Second, we are going to install a gcode post processor. This is just a bit of code that you won't have to have any clue how it works. We'll go through how to install it so your slicer does all of the heavy lifting for you!

Third, we will add a few special comments to your start gcode in the slicer so the post processing code knows what to set your accelerations to. It's mostly copy paste, and just change numbers, and is no harder than setting up per feature acceleration in your slicer that you are already using.

Getting new kiematics!

If you have ever used a quickdraw probe, or installed macros from someone else, this is quite similar. We'll be grabbing a file, and saving it to ~/klipper/klippy/kinematics/. If you prefer a command line, here are some instructions for each kinematics.

Command line install method

For this, you'll want to SSH into your printer (usually a pi), and run the correct command for your printer. Don't worry if you run the wrong one as it won't hurt anything. You'll just want to make sure you also run the correct line to make sure you have the file you'll need.


curl --output ~/klipper/klippy/kinematics/


curl --output ~/klipper/klippy/kinematics/


curl --output ~/klipper/klippy/kinematics/

GUI method.

For this you'll want to use the file explorer in your printer's file manager. Navigate to the ~/klipper/klippy/kinematics folder. Click one of the following links for COREXY COREXZ CARTESIAN copy all of the text, and save it to a file named or depending on which link you clicked. The instructions are also in the file if you ever forget, or want some more information.

Using your new kinematics.

So you grabbed the files for your new kinematics, but they aren't doing anything. We need to do some basic setup. For each machine, basic setup instructions are found in the files your downloaded. You don't have to understand any of the scary code, but it tells you in the comments how to switch over to the kinematics for your recpective machine. The important bit is switching from corexy or whatever your kinematic is, to limited_corexy. That simple change is all that is actually required, but there's more options to play with if you so choose.

For normal klipper style docs, you can read them for

Now for the slicer side.

I'll be explaining this in terms of SuperSlicer, but it should translate easily to most modern slicers, including PrusaSlicer and OrcaSlicer.

We'll want to grab the file from here and save this on your computer with the slicer. This is just a text file, so you can click SAVE_AS in your browser or CTRL-S on Windows/Linux, and CMD-S on Mac if it just shows up as text. Open up the file with a text editor. I've included the instructions in there, and will link to the help page for PrusaSlicer here as well. I haven't used OrcaSlicer, but the process should be similar as they all share the same base and are just tweaks to the same core slicer. You'll notice if you have read the file as instructed, we'll need to add some special comments to the start gcode of the section in the slicer. This absolutely must be done in the slicer and not the firmware at this time because it post processes locally, not on the printer.

Custom gcode

Under Printer Settings -> Custom Gcode -> Start Gcode we'll want to add some special comments at the top.

; Settings for the post-processing script "" that go into the Start GCode section in SuperSlicer.
; Accelerations are specified in the X_ACCEL / Y_ACCEL / Z_ACCEL format.

; ACCEL: 8000/8000/1000      for First Layer
; ACCEL: 30000/15000/1000    for Travel
; ACCEL: 45000/16000/1000    for TYPE:External perimeter
; ACCEL: 45000/16000/1000    for TYPE:Overhang perimeter
; ACCEL: 45000/16000/1000    for TYPE:Internal perimeter
; ACCEL: 45000/16000/1000    for TYPE:Top solid infill
; ACCEL: 60000/25000/1000    for TYPE:Solid infill
; ACCEL: 60000/40000/1000    for TYPE:Internal infill
; ACCEL: 30000/20000/1000    for TYPE:Bridge infill
; ACCEL: 30000/20000/1000    for TYPE:Internal bridge infill
; ACCEL: 45000/16000/1000    for TYPE:Thin wall
; ACCEL: 45000/16000/1000    for TYPE:Gap fill
; ACCEL: 8000/8000/1000      for TYPE:Skirt
; ACCEL: 30000/30000/1000    for TYPE:Support material
; ACCEL: 30000/30000/1000    for TYPE:Support material interface

THIS IS JUST AN EXAMPLE! If your machine can't handle these accels, you could damage something, so set it to something reasonable. If you are unsure for now (and you should be), set these to the same accelerations you use already, and keep the same accelerations that you used previously.

Disable acceleration control in the slicer

Yes, I'm serious. Once you are absolutely sure that you have those numbers set to match what you were using in your slicer, or lower if you want to be cautious, you want to disable acceleration control in your slicer. You can optionally leave it enabled, but you will be trying to control accelations from more than one place, and it will likely be more confusing. The post processor will take care of acceleration control, and you should trust the accel limits in your printer.cfg to save you when you mess up.

Before you try to print any gcode with this.

Make SURE that it's post processing. Just slice any random object, and open the gcode file. Use your text editor to search for SET_KINEMATICS_LIMIT in the gcode. If this is in the code in one or more places (it should be there many many times), then you have done everything on the slicer side to get going!

Onto tuning!

Tuning is almost identical to typical tuning. You'll want to do the same pressure advanced tuning, per feature acceleration tuning, and travel accel speed tuning. The only difference is now you have access to control the accelerations of each axis. My calibration macros are found here ard I've created TEST_AXIS_SPEED specifically for per axis tuning. This is a non extrusion test that will move your gantry around and let you test the limits of your machine at different speeds. I've left examples in each macro in there to tell you how to use them, but for the recommended one, you'd run it like this.


That will home the machine, and move it around at 300mm/s, 8k accel on X and 1k accel on Y, and make 10 full iterations of the test. Note that it's built to automatically raise the limit of the machines acceleration for all axies to the limit of X for what klipper "normally" uses. This is because X will be the fastest on all machines supported, so if using that macro, make sure your X_ACCEL is as fast, or faster than Y_ACCEL. If you decide this is wrong, you know enough how to modify the macro to your liking, but most users this will be correct.

Finalizing tuning

Once you have speeds you are happy with, you'll need to do one last thing in order to fully use these accelerations. I've left this information out until now because the included macro is the only things that has been able to break the safe limits that you had in place before, and you want to keep them in place while not printing and the printer is doing basic macros.

In your printer's PRINT_START macro, or your Slicer's Start Gcode macro (only if not using a PRINT_START macro), at the VERY END you want to add the line SET_VELOCITY_LIMIT ACCEL=1111

Replace 1111 with the maximum acceleration you will be printing at on any axis (usually the fastest X acceleration. Remember those are set in the comments described above in the start gcode section of the slicer.

In your PRINT_END macro (or End Gcode section in the slicer if you don't have a PRINT_END macro, add this line.

SET_VELOCITY_LIMIT VELOCITY={printer.configfile.settings.printer.max_velocity} ACCEL={printer.configfile.settings.printer.max_accel} ACCEL_TO_DECEL={printer.configfile.settings.printer.max_accel_to_decel}

You won't ever have to change it, it simply restores your printers limits set in the config. You very likely also want to add this to any PAUSE macro right after saving the SAVE_GCODE_STATE and before any moves as well. IF you have a CANCEL_PRINT macro, you likely want to add it there as well. Any time your printer needs to be interupted from normal sliced operations, it's a good guard to have in place. It's not a requirement depending on your settings and what your machine can do, but it is safer so I've listed all of these things.

Are we done yet?

Yes, that's everything majorly different here. If you followed steps here, you should have gotten to per axis accelerations safely, and without issue. There's much more that you can play with now if you so choose, and there's information in the files provided with instructions, as well as documentation linked above. I'll be doing a follow up post with some tuning tips specific to the limited-* kinematics that may help with some issues I've run into, but they are machine specific, and I want to hear back from the community so I know what others need help with. Feel free to reach out if you are stuck, confused, or just want to talk about this change!

Special shout out to Piezoid for the initial leg work on per-axis. I made very minimal modifications to their code, mostly shutting up the console spew that was useful, and is still there with an optional command, but lagged out the web UI when changing accelerations quickly (and per feature is very quick on small prints)

Also wanted to thank VintageGriffin, wherever they may be found. I wasn't able to track them down, but their post processing script was what I used as a basis for the one here, with little modification just to make it work per axis.

Both of these wonderful people were the ones that did the heavy lifting for what you see here. I simply stepped in and glued it together.