6th-order jerk-controlled motion planning

[burtoogle]

@joergs5 said in 6th-order jerk-controlled motion planning:

@burtoogle the information whether it's a circle is in the original 3d object, so transfering this information parallel to the gcode would be probably easier. Because calculating 3d objects from g-code or stl is not trivial. Your idea would allow printing a circle if the printer is capable of this, while another printer prints linear segments.

Sure, but that requires the slicer to play a part and it would be nice to have a solution that doesn't require help from the slicer.

@RCarlyle said

This gets more complicated when the segment size is small enough (ie similar magnitude as allowable error) such that the rounded trajectory spans more than two segments. Machinekit starts by merging small segments wherever the merged path results in less path-following error than the defined limit. That helps a lot. But it's another source of lost path-following fidelity. Then you have to do some iterative work over a queue to generate the overall rounded path, but I'm fuzzy on the details of how that's done.

Some of that could be a candidate for being pre-processed.

I'm really out of my depth with this stuff, so I can't pursue this any further.

[wilriker]

@joergs5 said in 6th-order jerk-controlled motion planning:

Because calculating 3d objects from g-code or stl is not trivial.

It's not but there is some promising progress made in that area right now: https://github.com/slic3r/Slic3r/issues/23#issuecomment-385288531

Of course this would again make it more slicer-dependent but still an awesome feature if it works as good as described.

---

Anyway, I think this is a little derailing in the regard that we are now discussing about corner-to-curves-conversion instead of the original discussion about acceleration-types, isn't it?

alranel created this issue in slic3r/Slic3r

open Detect arcs and generate G2/G3 #23

[JoergS5]

@wilriker wow, that's really interesting, thank you for the link!!

[wilriker]

@joergs5 Yeah, I was really excited when I found this myself.

[RCarlyle]

The reason why this arc stuff struggles to go anywhere is that there's a chicken-vs-egg problem with the slicer and firmware needing to change at the same time. Implementing G2/G3 arcs in the slicer is borderline pointless when the firmware handles arc commands by breaking them back into facets and running normal straight-line-and-corner motion control on the re-segmented path. (There's some benefit in gcode file size and command stream processing overhead but that's kinda "meh.")

STLs are faceted, and firmwares do everything faceted, so there's no point in slicers making up arcs when the upstream and downstream toolchains don't cooperate.

If you're going to make up arcs, you might as well do it in firmware. The Klipper model (RasPi does slicing AND trajectory planning, RAMPS does step pulses) is probably the easiest way to go on that front, but there are other things you can potentially do, like run a post-processing script between the slicer and firmware to do whatever conversion work you want.

Given the complexity of rounding off corners, I think working on straight-line motion and corner speed determination is pretty low-hanging fruit in comparison. That's my two cents.

[Phaedrux]

@rcarlyle I've been wanting to try playing around with Klipper using the duet as the MCU. Best of both worlds if you will. Best in class electronics and very high steps rates. If klipper succeeds in implementing s curve motion planning before the duet I will probably give it a shot.

[wilriker]

@rcarlyle Regarding whether arcs are making sense or not I was also torn between yes and no but I am now at "yes, they are useful". Let me explain why:

You are right that it seems to be pointless to have a command that defines an arc but the firmware will break it back into lots of linear movements. But there are at least three advantages of this approach I can see

1. Gcode files are smaller (more of a minor side-effect but still there)
2. The firmware usually knows on what hardware is running and it can optimize the breaking the arcs apart based on the capabilities of the processor, i.e. slower processors will have fewer segments compared to faster ones (this is already the case comparing Marlin vs. RRF where RRF uses a significantly smaller segment-size by default)
3. It cannot happen this way that the slicer is doing something strange in the middle of an arc (there are multiple posts in this forum where this happened) preventing the segmented arc being one fluid move. This can lead to lots of shaking, rattling, vibrations that can have a negative effect on print quality

So in my view having the slicer produce G2/G3 commands is desirable even though it seems absurd to have a total workflow where you design arcs in CAD, export them to STL which does not have arcs only to have them being reconstructed in the slicer be broken apart again inside the firmware.

This could in theory also be done in firmware (I mean reconstructing the arcs) but in the most cases the slicer runs on a much more powerful machine and that makes it a much better candidate for this step.

[JoergS5]

@wilriker I see a forth advantage

4. there are 3d printers being able to print arcs directly like printers with robot arms, they can print perfectly with arc g-code if the radius of the arm matches the radius of the g-code arc.

(I happen to be building a scara printer with variable radius.;-))

[dc42]

If G2/G3 arc printing becomes commonplace then I might find a way to generate arc movements without segmenting them.

[Catalin_RO]

@dc42 I use them extensively for CNC milling and all the motion related issues that I have (detailed in other threads!) are related to G2/G3, more specific, to G2/G3 movements followed by a G1. Maybe for 3D printing G2/G3 is not that important as the slicers usually start from a STL model, but CNC usually milling starts from a STEP model or something like that.

I will give just a simple example: if I want a 5mm hole, when made out of segments it will be slightly smaller!

I use extensively FreeCAD and CamBam. While FreeCAD can export both STL and STEP, CamBam really supports only STL. For complex items I tend to extract the edges and do simple profile and pocket operation based on them instead of an actual 3D milling - sometimes it requires less than half of the machining time! But for simple items I just draw 2D shapes in CamBam and then do operations on them with different Z start/stop heights. Either case, CamBam issues a lot of G2/G3 commands.

[JoergS5]

@catalin_ro As Cura 3.4 integrates FreeCad, Openscad etc. (thanks, David!), circles can be translated to g-code directly now, without STL.

[wilriker]

@joergs5 said in 6th-order jerk-controlled motion planning:

@catalin_ro As Cura 3.4 integrates FreeCad, Openscad etc. (thanks, David!), circles can be translated to g-code directly now, without STL.

That sounds great but the problem I see here is that CuraEngine which actually does the slicing part, does nowhere have code to write G2/G3 commands, only G1 and G0.
But maybe that will follow later.

[burtoogle]

@joergs5 said in 6th-order jerk-controlled motion planning:

@catalin_ro As Cura 3.4 integrates FreeCad, Openscad etc. (thanks, David!), circles can be translated to g-code directly now, without STL.

Except that the Cura plugins that provide this function do so by converting the source object to STL and reading that just like any other STL file. So the STL is still there, it's just hidden from the user.

Sorry to say that, at the moment, Cura can only work using polygons made from points and lines and does not have any support for models defined as arcs.

[JoergS5]

@burtoogle, @wilriker good idea to look into the source.

Support for G2/G3 in firmware is IMHO the first step, because the biggest advantage is for CNC users. Cura support in a later version would be kind then.

[RCarlyle]

Minor update -- the Klipper folks testing 6th-order straight-line motion code with corner junction deviations are finding the print quality improvement to be inconsistent. Some folks are actually seeing quality degradation. Might be an artifact of overlaying a bezier curve profile on top of the constant-acceleration entry/exit speeds, but who knows.

[JoergS5]

@rcarlyle said in 6th-order jerk-controlled motion planning:

Klipper folks testing 6th-order straight-line motion

Thank your for your information, could you please provide the link? I want to understand the reasons.

PS. you mean
https://github.com/KevinOConnor/klipper/issues/57
?

dragonnn created this issue in KevinOConnor/klipper

closed S-Curve acceleration? #57