Going forward....

[rewolff]

Let me document my thoughts about going forward with 3D printing in general. But first Klipper is already a HUGE step in what I've been privately thinking for myself for the last few years.

Klipper should start implementing 3rd degree polynomials for the movement functions. These can describe jerk-free movements. But also they can describe smooth curves. So the suggestion to support S-curves would build nicely on top of this.

This then opens up the option of g-code commands issuing a (3rd degree) curve instead of a bunch of short segments for curved parts of my objects.

Once that works, we can start to work on an STL++ format that does not describe the object as triangles, but that describes the object as patches of 3rd degree splines. (this is upward compatible: You can always transform the triangles to the patches!) One of these days someone will have to do the complicated math to intersect those patches with the slicing plane, but from then on, smooth objects will actually be printed with smooth curves.

[lenne0815]

Problem with that is to gain any meaningful user base / support the first step would be educating people on why something as abstract as a motion planner is important for them.

Klipper has done the groundwork to bring this "idea" to a lot more machines then before so i hope itll reach a point where many people know about it.

The discussion on this topic for 3D printing is utterly lacking right now, i personally was stunned once i learned what "jerk" in marlin means and again very surprised once i learned how smoothieware handles it, how could it even be possible in the 3D printing space that only a tiny fraction of machines does machine movement halfway properly if alternatives already existed for a long time ?

My personal mission is now to spread the word and it worked out seemingly successful so far, my prognosis ( if we a really lucky ) is that we see chinese machines bundling Raspi3s mid to end 18, this has happend in the sla space were NanoDLP became the de facto standard in a short timeframe.

Popularity would hopefully lead to more programmers helping / expanding klipper.

And i think at that stage tackling the even more advanced approaches to machine movement become feasible, it would be horrible to see klipper fail this early due to feature creep ( even though it looks like kevin has a really good grip on that right now )

[rewolff]

Yes! I agree that "feature creep" should not happen and that certainly klipper should not become "buggy" due to not-for-everybody features.

I just wanted to mention that: If you implement "third degree functions" well enough for the requested feature: "jerk free movements", then "arbitrary curves" suddenly become easy. When you're not aware of this possible path, then the implementation of the "jerk-free" feature may hamper the curve implementation.

But looking ahead towards "curved paths" (actually already necessary for delta printers, right?) things might even be simpler to implement. The step from "quadratic" position wrt time to cubic is not complicated. And it suddenly solves a bunch of problems in a uniform way.

[lenne0815]

I think i know what you mean; toolpath deviation like Linuxcnc and Mach do ?

[KevinOConnor]

On Fri, Dec 29, 2017 at 02:23:35PM +0000, Roger Wolff wrote: Yes! I agree that "feature creep" should not happen and that certainly klipper should not become "buggy" due to not-for-everybody features. I just wanted to mention that: If you implement "third degree functions" well enough for the requested feature: "jerk free movements", then "arbitrary curves" suddenly become easy. When you're not aware of this possible path, then the implementation of the "jerk-free" feature may hamper the curve implementation. But looking ahead towards "curved paths" (actually already necessary for delta printers, right?) things might even be simpler to implement. The step from "quadratic" position wrt time to cubic is not complicated. And it suddenly solves a bunch of problems in a uniform way.

That isn't how Klipper works. Klipper calculates the precise clock time that each step should occur at, those clock times are compressed, they are sent to the micro-controller, and then the micro-controller executes that schedule. There's some further details on this in docs/Code_Overview.md. So, there's nothing preventing the use of arbitrary curves in the software today. It is true that the compression algorithm finds a series of quadratic functions to represent the steps - but this is just a detail of the compression. It doesn't place any limit on the stepper movement or kinematics.

…

-Kevin

[lenne0815]

If i understood it correctly and it describes toolpath deviation, wouldnt it be much more elegant to offload that into the slicer ?

Cnc gcode generators usually have "smoothing" features which should amount to a very similar outcome as if done firmware wise, but are much more predictable since the actual deviations can bee seen before running them on the machine. ( especially troubleshooting is hard if its done in firmware, had my fair share of failures as mach3 had a totally different idea how a 2d toolpath should look like with and without toolpath deviation than i had ;) )

[KevinOConnor]

I'm closing this in favor of the existing issue #57