Improving Cura for Klipper and Smooth Motion Firmware 🏃

[MariMakes]

When developing Cura 5.4 we spend quite some time resolving unwanted microsegments that would show up on curved surfaces. These would result in drops in printed part quality. It was not something that would show up on all 3D printers but for 3D printers that run on Klipper, Smooth Motion, or Jerk Limited firmware. This should now be resolved in Cura 5.4 stable.

We see that there is a rise in 3D printers that are running Klipper firmware. As UltiMaker employees we focus on the motion controller that our UltiMaker printers use. So we are less exposed to the finer details of Klipper. But we are interested and want Cura and Klipper to work smoothly together.

Our amazing community member @jjgraphix worked on a plugin that already covers a lot.
We highly recommend checking them out here: https://github.com/jjgraphix/KlipperSettingsPlugin

But we've also seen feature requests on Github and on our Forums that mention things like this;

1. The start gcode should be able to contain references to settings material_print_temperature_layer_0
2. The start gcode should be able to contain {
3. Retraction Prime Amount should be zero

We cannot make any promises that we can resolve them all, but leaving a comment would help us understand what we can do better and what has priority.

What can we do to make Cura better for Klipper printers?

[pedrolamas]

I personally maintain Fluidd (Klipper web interface) and regularly contribute to Klipper, Moonraker (Klipper API server), and even Mainsail (another Klipper web interface).

I use Cura exclusively as my go-to slicer when I want to print in "Klipperized" printer, and have used quite a few hacks to make it compliant with Klipper (most of those hacks are currently pinned posts on the #cura channel in the Klipper Discord server so anyone can use them)

I also have a Cura script that "prepares" gcode for Klipper: https://github.com/pedrolamas/klipper-preprocessor

Here are some things to consider:

Output Moonraker compatible metadata

Cura could automatically include print metadata so that Moonraker can read it.

Currently, users can it manually following this procedure

Output SET_PRINT_STATS_INFO

Klipper includes a SET_PRINT_STATS_INFO command that allows the slicer to pass the layer count and current layer index to Klipper. This information ss then used by the frontends and Klipper macros.

Right now, this can be achieved with my script above!

Improved object markers

Having better object markers would allow for improved single object cancellation support!

Right now, one can cancel an object on Klipper, but the object support will still print, as there is no way to know that link the 2 of them... improving on this would be great not only for Klipper but also for everyone as this also affects the way object cancellation works in Octoprint and others.

[vic131313]

I agree to the improved object markers and agree that not printing supports for a cancelled object is definitely needed

[PhilBaz]

I'm a Cura Klipper user. My thoughts are.

1. Pedro's script klipper pre processor is essential. So any functionality from there that can be directly integrated into Cura would be good.

2. Many people are using dynamic bed mesh that takes the size of the print and only probes for a mesh in the are used by the print. Currently this requires a script in Cura but perhaps this info can be supported natively? See below.

https://gist.github.com/ChipCE/95fdbd3c2f3a064397f9610f915f7d02
https://raw.githubusercontent.com/ChipCE/Slicer-profile/master/cura-slicer/scripts/KlipperPrintArea.py

[MariMakes]

Quick update on our side.
We might have a fix for this issue. 🎉
It's a bit hard for us to test. Can you please try it out and let us know if it resolves your issue?
You can download it here. https://github.com/Ultimaker/Cura/releases/tag/5.6.0-beta.1

[d3dorsett]

FYI: KAMP and GCode Preview work correctly for me in Cura 5.6.0, with fluidd (klipper on a rooted Creality K1 Max using Guilouz Installation Helper Script).

Note: My K1 Max profile - https://github.com/d3dorsett/Creality-K1-Max-Cura-Profile/blob/main/UltiMaker%20Cura%20Creality%20K1%20Max%20Profile.pdf

[Ergonomicmike]

I'm a newbie hobbyist (1 year now) with only an Ender 3 v2. (Now moderately modified. But still on Marlin.) But since you asked...

Whatever you do for Klipper, please keep it simple, like Cura is already. Continue to keep it so that my mom can easily use it. (Which covers me as well.)

For example, although Prusa 2.6.0 has arguably leap-frogged Cura in features/enhancements - and so is "better," I still use Cura because I like the way that Cura has "compartmentalized" the multitude of settings. (E.g., putting all the filament settings in one place, independent of the model. (Making it more ergonomic to use.))

So whatever you do, please don't clutter Cura when you add Klipper stuff. It should be transparent (invisible) to those of us using Marlin. (So perhaps a plug-in that users have to add themselves?)

Next, is Klipper support really necessary? Although I don't need Klipper for what I do, I've thought about it. But when I watch the (hour long) videos on how to run Klipper, my eyes glaze over. I'm reminded why Linux has never caught on.

I am NOT going read a "ton" of (arcane?) documentation nor hack my way through a bunch of code to run Klipper. (While I can modify config.h for Marlin and build a "custom" firmware, hacking at Klipper and jumping through a great many hoops compiling is too much for me.) So however you add support for Klipper firmware, please simplify it.

But is post-processing for Klipper truly important right now? With the recent additions of LA and IS to Marlin, I don't need Klipper. My Benchy time is already down to 1 hour, from 1:43. And for those who do need the scripts/tweaks for Klipper, they have demonstrated here that they already know what to do. So there doesn't seem to be an urgent need at this time.

Certainly if UltiMaker goes Klipper, and perhaps if a majority of new printers come stock with Klipper someday, then you'll have to offer a solution. But for now, while I'm glad that you all are looking ahead, I suggest spending your resources on continuing to improve the ease of use of Cura for the majority of your users.

[MariMakes]

That's a super interesting take 😊 , one I was definitely not expecting when putting out this request for information

[pedrolamas]

Granted, the "entry ticket" to Klipper is not for complete beginners and it does require some initial extra investment (as it needs an extra computer like a raspberry pi to run Klipper), but one should not reduce Klipper features to just to Input Shaping and Pressure Advance as that is not the full story...

For example, compare what work a simple hardware modification in a Marlin printer (like adding a BL-touch, a new screen, etc.) requires me to edit the Marlin code to change some obscure flag that enables this new hardware support, recompile the code, and then manually flash the new firmware to the printer...
In Klipper I just edit a text configuration file, make some modifications to the text, click "save and restart" and that is it and I am ready to continue printing!

Regarding investing in better Klipper support in Cura, I personally prefer to use Cura to slice the models I print in my Klipperized printer because I get considerable quality with a lot less stringing, but given the number of "hacks" I need to have to make it work and even then, there are a few unresolved issues... most Klipper users will just use some other slicer than going through this extra pain, as other slicers have better Klipper support.

In my opinion, there is value in improving Klipper support in Cura, and I do believe that it would also help for non-Klipper processes (like specific object cancellation, which is currently quite bad in both worlds)

[PhilBaz]

Ill be substantially less diplomatic than Pedro here and say that this comment fundamentally misses the context of what is actually being proposed or discussed here. For instance which klipper feature do you wish not to clutter the Cura interface with? The answer is....this doesn't make sense.

For more of my unsolicited(?) opinion continue reading below.

klipper is progress for 3d printing more than an alternative to marlin. This may seem trite, but for anyone who has used it, this much is obvious.

The cost of klipper is small, in truth we have a pi shortage. Its not exactly the same thing. If not for the pi shortage a pi zerow2 for $15. Solutions and work arounds for pi are already numerous.

[Ergonomicmike]

That's a super interesting take 😊 , one I was definitely not expecting when putting out this request for information

Agreed. More of a "Management" take than an Engineering take. (I'll blame Old Man/Fatherly thinking.) Would rather see the team fix existing issues in Cura than introduce new ones.

Since I don't know anything about Klipper, I don't know why it's necessary for a slicer to tailor its output for different firmwares. Nor is this the place for me to learn. (Am going to guess, as a minimum, to add certain G-codes that are Klipper specific that are not supported in Marlin.)

But obviously it is necessary - or, at least, desirable - since Prusa has a setting for G-Code Flavor. And since you're asking for technical input.

Since, as you said, there's already a Plug-in in process to preprocess, I'm still thinking (Managerially as well as a little bit Engineeringly) that a Plug-in for Klipper preprocessing is the best (least intrusive) way to go at this time.

I'll bow out now, since I'm already in way over my head.

[hypersmc]

#14679.

I use klipper and one of the things that keep me away from using cura now is that nonsense of using "EXCLUDE_OBJECT_DEFINE NAME=NOMESH"
While yes your own controller boards and so on may ignore it. Klipper with KAMP won't. Klipper will out right hate that and cancel the print. By having that weird "nomesh" thing we need to manually remove ALL of them in the gcode to make it work with klipper & KAMP

[d3dorsett]

FYI: KAMP and GCode Preview work correctly for me in Cura 5.6.0, with fluidd (klipper) using Guilouz script on a Creality K1 Max.

[Sineos]

@MariMakes and Cura Team:

Would you be so kind to share some more information on the new Fluid Motion settings, e.g. what they effectively try to achieve and how one would tune them, respectively validate the results?

[Firemansorensj]

How do I set up Cura to work with my new Wanhao D12/500 pro max?

[pedrolamas]

@MariMakes I see that there is a new 5.6.0-beta.1 and it bring improved variable handling on the start g-code - thank you for that!!

I would however like to enquire if there has been any improvement on the multi-part markers on the g-code? The existing Cura comments on the g-code are all that we have right now, but this is insufficient to allow for proper part cancellation on a multi-part print...

[freakydude]

As my predecessors have already written here, I would like to see the following list of things (sorted by personal priority)

1. Connect & upload directly to Moonraker
2. Add a klipper g-code output mode
   1. Basic g-codes supported by klipper (https://www.klipper3d.org/G-Codes.html) including G2-G3 - arc or circle moves.
   2. Disable slicer options required for Marlin, but solved by klipper kinematics. (https://www.klipper3d.org/Slicers.html)
   3. Support advanced g-code commands (https://www.klipper3d.org/G-Codes.html#additional-commands) where Cura Slicer has options or may introduce them (e.g. acceleration, pause, pressure advanced).
3. Native support of the Klipper ecosystem
   1. Better time estimation like (https://github.com/Annex-Engineering/klipper_estimator) and synchronisation with local Cura acceleration/speed settings.
   2. Print statistics & thumbnail support (https://docs.mainsail.xyz/overview/slicer/prusaslicer)
   3. Exclude (failed) objects including support structures (https://www.klipper3d.org/Exclude_Object.html)
   4. Timelapse support (https://github.com/mainsail-crew/moonraker-timelapse/blob/main/docs/configuration.md)

I would be very happy. I have only used Prusa (sometimes OrcaSlicer) for a long time. However, I often find that the many parameters are often implemented incorrectly. With Cura, I have not noticed any comparable errors, e.g. with overhang and bridging or travel routes through the support structures. Less is more.

Let's go, Cura team ;-)