<p>Cura's solution can be found in the "Jerk Control" settings.</p>

<p>Short analogy; when driving, and a corner is coming up, you basically have two options to take the corner smoothly; you can take the corner with a wide turning radius, or you can slow down. Taking a neighborhood street corner at highway speeds just doesn't work even if there's nobody else on the road; you'll very likely overshoot the corner, if you're in a RWD car you'll likely lose the back end and fishtail (or worse), and the occupants of the car, yourself included, are going to be thrown around violently, to no-one's real advantage other than to say you took that turn at 70.</p>

<p>Back in 3D printing land, something similar applies; as the extruder approaches a sharp corner, it will be disadvantageous all around for the extruder to try to maintain 70mm/s around what's basically an instantaneous turn. Your jerk (stopping the moving axis) and acceleration (starting the non-moving axis) settings are going to exceed the physical capabilities of your steppers and drive belts, making the corner less accurate (and in the extreme, losing steps causing layer shifts), and if your belts are not <em>perfectly</em> tensioned, and really even if they are, you'll get "ringing" (the 3D equivalent of fishtailing as you straighten out after the apex of a turn while driving).</p>

<p>The first option, cutting the corner, is your corner-to-arc replacement; rather than try for an instantaneous turn, just soften that corner by enough that you're within what's possible for the stepper motors in terms of acceleration. This keeps the speed and surface quality high, but necessarily reduces the accuracy of the print to the model.</p>

<p>So instead, Cura encourages the second option; slow down before the turn. Enabling Jerk Control and tweaking the associated settings lets the Cura slicer reduce head speed gradually as the extruder approaches a sharp corner, thus reducing the torque required to stop motion in one axis and start it in another, to something the steppers can actually accomplish at a rate you'd call "instantaneous". This keeps the corners sharp and avoids ringing along straight lines after a corner, at the cost of a slower overall print speed (though not as much as reducing overall print speed to the speed at which the extruder will take corners).</p>

<p>Now, I realize that this is the <em>opposite</em> of "increasing corner speed"; jerk control exists to slow the extruder near corners. However, increasing corner speed is rarely what you actually want, for the reasons stated above. If you really want nicely-rounded corners, fillet them in CAD, and then the slicer will generate a sequence of arbitrarily short linear movements (true G2/G3/G5 curve interpolation from the purely polygonal STL geometry has been experimented with, but currently more trouble than it's worth) which limit the change of velocity of the extruder as it rounds the corner, instead of making the rounding an "artifact" of printer limitations. At fine enough detail levels of conversion to an STL, the results are indistinguishable from a true curve.</p>

CC BY-SA 4.0
2020-02-05T21:50:50.990Z
Please explain more about which slicer will generate G2 moves from an STL file composed completely of flat triangles.
Davo
CC BY-SA 4.0
2020-02-05T22:07:59.630Z
@Davo Actually, both Slic3r and Simplify3D have experimented with exactly that. But, I will edit to clarify that what really happens is a sequence of polygonal lines of arbitrarily small length (based on a number of variables in both CAD and the slicer), where each move accomplishes the overall goal of limiting acceleration around the corner.
KeithS
CC BY-SA 4.0
2020-02-06T00:23:19.153Z
I think this answer completely misunderstands/misrepresents what "jerk control" in Cura is. It simply means that Cura will issue gcode commands to set the printer firmware's jerk limits, possibly with different values for different parts of the print (outer walls, inner walls, skin, infill, etc.), rather than leaving the firmware's default setting in place. It does not mean Cura does any alteration of the movement paths or speed to reduce the physical jerk experienced by the toolhead. It's the printer's firmware that actually applies these settings to how it controls the stepper motors.
R.. GitHub STOP HELPING ICE
CC BY-SA 4.0
2021-02-02T09:24:00.630Z
https://github.com/FormerLurker/ArcWelderLib does generate G2/G3 (arcs) from linear ones.
Vincent Alex
CC BY-SA 4.0
2020-01-06T19:42:54.467Z
2020-02-05T22:15:41.373Z
2020-02-05T22:15:41.373Z
KeithS
<p>I realized that with current Marlin I cannot use Junction Deviation with Linear Advance, see <a href="https://github.com/MarlinFirmware/Marlin/issues/15473" rel="nofollow noreferrer"><code>[BUG] Rapid changes of acceleration break linear advance when using Junction Deviation #15473</code></a>.</p>

<p>Yet, it is very much beneficial to not stop at the corners with high acceleration but rather do a small curve. Is it possible on a G-code level? </p>

<p>Is there a feature or plugin in Cura which replaces sharp corners with arcs to remove need for Junction Deviation in firmware? </p>

CC BY-SA 4.0
2019-12-31T01:46:34.200Z
Can you clarify whether you are actually having a problem matching the one described in the linked bug report, or just concerned that you might? I use junction deviation and linear advance, K=0.6 for regular PLA, K=3.8 for flex material, and did not observe this problem whatsoever with the former but might be encountering it with the latter.
R.. GitHub STOP HELPING ICE
CC BY-SA 4.0
2019-12-31T01:47:59.457Z
Also, what junction deviation parameter are you using?
R.. GitHub STOP HELPING ICE
CC BY-SA 4.0
2019-12-31T16:31:00.710Z
@R.. I am the reporter of that bug... With K=2 there issue is very serious. What board do you have? It is possible that it happens only on AVR... Anyways, it is beneficial to make corners a little less sharp.
BarsMonster
CC BY-SA 4.0
2019-12-31T16:31:18.660Z
@R.. I am using JD=0.022
BarsMonster
CC BY-SA 4.0
2019-12-31T16:39:09.850Z
I have an Ender 3, which is an AVR-based board (ATmega 128-whatever). JD=0.022 is rather low; I use JD=0.08 (computed with [formula for converting from comparable classic jerk](https://blog.kyneticcnc.com/2018/10/computing-junction-deviation-for-marlin.html)) which isn't to say you should increase it, just that it's not a problem with your value being excessive.
R.. GitHub STOP HELPING ICE
CC BY-SA 4.0
2019-12-31T17:05:18.637Z
Is there a reason you're not using classic jerk? I switched to JD because classic jerk seems to be the source of nasty layer shifting bugs, but if your setup isn't affected by that, classic jerk might be a solution.
R.. GitHub STOP HELPING ICE
CC BY-SA 4.0
2020-01-01T21:42:05.010Z
@R..GitHubSTOPHELPINGICE Surely I currently live on Classic Jerk, that's the only working solution for me at the moment. But I would still be interested to try to round the corners a little bit.
BarsMonster
CC BY-SA 4.0
2020-01-02T02:53:54.920Z
Junction deviation does not produce round corners. It just performs the math for the allowable instantaneous change in velocity components *as if* it were going around a rounded corner with the configured deviation. See http://blog.kyneticcnc.com/2018/10/computing-junction-deviation-for-marlin.html
R.. GitHub STOP HELPING ICE
CC BY-SA 4.0
2020-01-02T02:54:26.337Z
And I just confirmed that I'm affected by this issue too, even with K=0.6. Uhg. Switching back to classic jerk and hoping I don't hit layer shifts again... If your bounty expires without an acceptable solution I'll run another out of my rep to follow up.
R.. GitHub STOP HELPING ICE
CC BY-SA 4.0
2020-01-03T17:17:41.197Z
@R..GitHubSTOPHELPINGICE Yes, I understand that JD does not produce rounded corners. But I believe automatic rounded corners would be beneficial for all 3d printers (R=0.1-0.2mm)
BarsMonster
CC BY-SA 4.0
2020-01-03T19:12:02.587Z
Short of using the arc movement commands (G2/G3), I'm not sure it would be very helpful. Doing a rounded corner with radius 0.1-0.2 mm is going to involve some utterly tiny segments, which Marlin and other firmware don't really like - they make the planner math a lot more expensive and potentially produce compounding jerk, allowing the cornering to happen *faster* than it's supposed to. The G2/G3 approach may be promising, but I've actually had to omit support for them from my builds to fit Marlin in 128k. :-(
R.. GitHub STOP HELPING ICE
CC BY-SA 4.0
2021-02-02T09:32:15.380Z
see post processing idea here https://github.com/FormerLurker/ArcWelderLib/issues/33
Vincent Alex
CC BY-SA 4.0
2021-02-02T15:14:22.560Z
@VincentAlex ArcWelderLib is awesome, It does most of what I dreamed about. But still as far as I see it does not replace corners with arcs (i.e. it does not change geometry).
BarsMonster
CC BY-SA 4.0
2021-02-03T09:56:59.937Z
@BarsMonster true, I'm also looking for something similar, the easiest would be to do it in 3D model, but that doesnt include infills, bspline fitting from CNC world would give you this, but not written for 3D gcode: https://user-images.githubusercontent.com/4163396/106666173-27fc8c80-659f-11eb-9c45-c443cbf05163.jpg
Vincent Alex
CC BY-SA 4.0
2021-02-03T10:00:29.137Z
@BarsMonster an idea, draw your 2D base in dwg, use a script that rounds the corners, extend it to 3D, and slice that, a lot easier than processing gcode.
Vincent Alex
<marlin><g-code>
Cura's solution to replace corners->arcs to increase corner speed?
BarsMonster
# Cura's solution to replace corners->arcs to increase corner speed?

(Asked by: username_0 on 2019-12-28)

I realized that with current Marlin I cannot use Junction Deviation with Linear Advance, see [`[BUG] Rapid changes of acceleration break linear advance when using Junction Deviation #15473`](https://github.com/MarlinFirmware/Marlin/issues/15473).

Yet, it is very much beneficial to not stop at the corners with high acceleration but rather do a small curve. Is it possible on a G-code level?

Is there a feature or plugin in Cura which replaces sharp corners with arcs to remove need for Junction Deviation in firmware?

**Tags:** marlin, g-code

> **Comments:**
> **username_1**: Can you clarify whether you are actually having a problem matching the one described in the linked bug report, or just concerned that you might? I use junction deviation and linear advance, K=0.6 for regular PLA, K=3.8 for flex material, and did not observe this problem whatsoever with the former but might be encountering it with the latter.  
> **username_1**: Also, what junction deviation parameter are you using?  
> **username_0**: @R.. I am the reporter of that bug... With K=2 there issue is very serious. What board do you have? It is possible that it happens only on AVR... Anyways, it is beneficial to make corners a little less sharp.  
> **username_0**: @R.. I am using JD=0.022  
> **username_1**: I have an Ender 3, which is an AVR-based board (ATmega 128-whatever). JD=0.022 is rather low; I use JD=0.08 (computed with [formula for converting from comparable classic jerk](https://blog.kyneticcnc.com/2018/10/computing-junction-deviation-for-marlin.html)) which isn't to say you should increase it, just that it's not a problem with your value being excessive.  
> **username_1**: Is there a reason you're not using classic jerk? I switched to JD because classic jerk seems to be the source of nasty layer shifting bugs, but if your setup isn't affected by that, classic jerk might be a solution.  
> **username_0**: @username_1 Surely I currently live on Classic Jerk, that's the only working solution for me at the moment. But I would still be interested to try to round the corners a little bit.  
> **username_1**: Junction deviation does not produce round corners. It just performs the math for the allowable instantaneous change in velocity components *as if* it were going around a rounded corner with the configured deviation. See http://blog.kyneticcnc.com/2018/10/computing-junction-deviation-for-marlin.html  
> **username_1**: And I just confirmed that I'm affected by this issue too, even with K=0.6. Uhg. Switching back to classic jerk and hoping I don't hit layer shifts again... If your bounty expires without an acceptable solution I'll run another out of my rep to follow up.  
> **username_0**: @username_1 Yes, I understand that JD does not produce rounded corners. But I believe automatic rounded corners would be beneficial for all 3d printers (R=0.1-0.2mm)  
> **username_1**: Short of using the arc movement commands (G2/G3), I'm not sure it would be very helpful. Doing a rounded corner with radius 0.1-0.2 mm is going to involve some utterly tiny segments, which Marlin and other firmware don't really like - they make the planner math a lot more expensive and potentially produce compounding jerk, allowing the cornering to happen *faster* than it's supposed to. The G2/G3 approach may be promising, but I've actually had to omit support for them from my builds to fit Marlin in 128k. :-(  
> **username_2**: see post processing idea here https://github.com/FormerLurker/ArcWelderLib/issues/33  
> **username_0**: @username_2 ArcWelderLib is awesome, It does most of what I dreamed about. But still as far as I see it does not replace corners with arcs (i.e. it does not change geometry).  
> **username_2**: @username_0 true, I'm also looking for something similar, the easiest would be to do it in 3D model, but that doesnt include infills, bspline fitting from CNC world would give you this, but not written for 3D gcode: https://user-images.githubusercontent.com/4163396/106666173-27fc8c80-659f-11eb-9c45-c443cbf05163.jpg  
> **username_2**: @username_0 an idea, draw your 2D base in dwg, use a script that rounds the corners, extend it to 3D, and slice that, a lot easier than processing gcode.  

---

## 1 answers

### Answer by username_3 on 2020-01-06. Score: 2

Cura's solution can be found in the "Jerk Control" settings.

Short analogy; when driving, and a corner is coming up, you basically have two options to take the corner smoothly; you can take the corner with a wide turning radius, or you can slow down. Taking a neighborhood street corner at highway speeds just doesn't work even if there's nobody else on the road; you'll very likely overshoot the corner, if you're in a RWD car you'll likely lose the back end and fishtail (or worse), and the occupants of the car, yourself included, are going to be thrown around violently, to no-one's real advantage other than to say you took that turn at 70.

Back in 3D printing land, something similar applies; as the extruder approaches a sharp corner, it will be disadvantageous all around for the extruder to try to maintain 70mm/s around what's basically an instantaneous turn. Your jerk (stopping the moving axis) and acceleration (starting the non-moving axis) settings are going to exceed the physical capabilities of your steppers and drive belts, making the corner less accurate (and in the extreme, losing steps causing layer shifts), and if your belts are not *perfectly* tensioned, and really even if they are, you'll get "ringing" (the 3D equivalent of fishtailing as you straighten out after the apex of a turn while driving).

The first option, cutting the corner, is your corner-to-arc replacement; rather than try for an instantaneous turn, just soften that corner by enough that you're within what's possible for the stepper motors in terms of acceleration. This keeps the speed and surface quality high, but necessarily reduces the accuracy of the print to the model.

So instead, Cura encourages the second option; slow down before the turn. Enabling Jerk Control and tweaking the associated settings lets the Cura slicer reduce head speed gradually as the extruder approaches a sharp corner, thus reducing the torque required to stop motion in one axis and start it in another, to something the steppers can actually accomplish at a rate you'd call "instantaneous". This keeps the corners sharp and avoids ringing along straight lines after a corner, at the cost of a slower overall print speed (though not as much as reducing overall print speed to the speed at which the extruder will take corners).

Now, I realize that this is the *opposite* of "increasing corner speed"; jerk control exists to slow the extruder near corners. However, increasing corner speed is rarely what you actually want, for the reasons stated above. If you really want nicely-rounded corners, fillet them in CAD, and then the slicer will generate a sequence of arbitrarily short linear movements (true G2/G3/G5 curve interpolation from the purely polygonal STL geometry has been experimented with, but currently more trouble than it's worth) which limit the change of velocity of the extruder as it rounds the corner, instead of making the rounding an "artifact" of printer limitations. At fine enough detail levels of conversion to an STL, the results are indistinguishable from a true curve.

> **Comments:**
> **username_4**: Please explain more about which slicer will generate G2 moves from an STL file composed completely of flat triangles.  
> **username_3**: @username_4 Actually, both Slic3r and Simplify3D have experimented with exactly that. But, I will edit to clarify that what really happens is a sequence of polygonal lines of arbitrarily small length (based on a number of variables in both CAD and the slicer), where each move accomplishes the overall goal of limiting acceleration around the corner.  
> **username_1**: I think this answer completely misunderstands/misrepresents what "jerk control" in Cura is. It simply means that Cura will issue gcode commands to set the printer firmware's jerk limits, possibly with different values for different parts of the print (outer walls, inner walls, skin, infill, etc.), rather than leaving the firmware's default setting in place. It does not mean Cura does any alteration of the movement paths or speed to reduce the physical jerk experienced by the toolhead. It's the printer's firmware that actually applies these settings to how it controls the stepper motors.  
> **username_2**: https://github.com/FormerLurker/ArcWelderLib does generate G2/G3 (arcs) from linear ones.  

---

