[BUG] JUNCTION_DEVIATION creates unexpected decelerations/accelerations on smooth curves

[ktand]

Bug Description

With Junction deviation enabled the printer decelerates and accelerates unexpectedly on smooth curves. JUNCTION_DEVIATION_MM is set to 0.017. There is no difference if I increase it to 0.2.

In this picture I have marked the locations where the slowdown occurs with arrows. This happens at other locations as well but these are the most obvious.

With CLASSIC_JERK the print is smooth and without unexpected deceleration / acceleration.

Example videos (look at the extruder visualizer when this happens):

With Junction Deviation = 0.017 With Classic Jerk

#define DEFAULT_XJERK 10.0
#define DEFAULT_YJERK 10.0
#define DEFAULT_ZJERK  0.3

My Configurations

LIN_ADVANCE is enabled and LIN_ADVANCE_K is set to 0.1. Settings this to 0 has no effect. S_CURVE_ACCELERATION is enabled.

Configurations.zip

Steps to Reproduce

Print a large curved object like the one in the photo.

Expected behavior: The curve is printed smooth, just like with classic jerk.

Actual behavior: The curve is printed with at least decelerated/accelerated moves.

I'm using Marlin bugfix-2.0.x commit e7a9f17 from March 22nd.

[qwewer0]

17146

Have the same issue. SKR Mini E3 v1.2, Cura/PrusaSlicer/Fusion 360

[CarlosGS]

Yes. I have this same problem (in fact also printing face shields :D).

Differences in setup, producing the same issue:

• You are using Slic3r and I am using Cura.
• Your board is 32 bit (ARMED STM32) and mine is 8 bit (ZUM Mega 3D).
• The STL model is different (I was printing this one).

Similarities:

• The model has arcs that are long and thin.
• S_CURVE: enabled (tested both ON and OFF, same problem).
• Junction deviation: enabled.
• LIN_ADVANCE: enabled (tested both ON and OFF, same problem).

More parameters:

• I have ADAPTIVE_STEP_SMOOTHING enabled (tested both ON and OFF, same problem).

I'm considering switching back permanently to classic jerk since it doesn't have this problem. Your help would be very appreciated!

Maybe related: #15473

[rado79]

Because of this problem, I spent a lot of time testing JD and LA settings. My bottom line is to set JD much higher, certainly based on my other settings. Printing curves like @ktand in the first post with default 0.013 JD creates a lot of stuttering on my machine. Increasing JD to much higher values makes it working as expected. In my case setting JD to 0.07 stuttering gets rarely. Increasing to 0.09 makes stuttering almost gone, except small curves and corners where it does its job as expected.

Here are my config files, maybe to compare settings like acceleration, E-jerk,... Configuration.zip Configuration_adv.zip

[ktand]

I increased JUNCTION_DEVIATION_MM to 0.2, almost 11 times higher, but the problem still occurs.

Den tis 31 mars 2020 kl 19:43 skrev rado79 notifications@github.com:

Because of this problem, I spent a lot of time testing JD and LA settings. My bottom line is to set JD much higher, certainly based on my other settings. Printing curves like @ktand https://github.com/ktand in the first post with default 0.013 JD creates a lot of stuttering on my machine. Increasing JD to much higher values makes it working as expected. In my case setting JD to 0.07 stuttering gets rarely. Increasing to 0.09 makes stuttering almost gone, except small curves and corners where it does its job as expected.

Here are my config files, maybe to compare settings like acceleration, E-jerk,... Configuration.zip https://github.com/MarlinFirmware/Marlin/files/4410644/Configuration.zip Configuration_adv.zip https://github.com/MarlinFirmware/Marlin/files/4410645/Configuration_adv.zip

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/17342#issuecomment-606773983, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEHQ2JDBQG34PUYSMZVYDKTRKITSLANCNFSM4LW33CGA .

[CarlosGS]

I increased it to 0.3mm and the problem still occurs.

El mar., 31 mar. 2020 19:56, Karl Andersson notifications@github.com escribió:

I increased JUNCTION_DEVIATION_MM to 0.2, almost 11 times higher, but the problem still occurs.

Den tis 31 mars 2020 kl 19:43 skrev rado79 notifications@github.com:

Because of this problem, I spent a lot of time testing JD and LA settings. My bottom line is to set JD much higher, certainly based on my other settings. Printing curves like @ktand https://github.com/ktand in the first post with default 0.013 JD creates a lot of stuttering on my machine. Increasing JD to much higher values makes it working as expected. In my case setting JD to 0.07 stuttering gets rarely. Increasing to 0.09 makes stuttering almost gone, except small curves and corners where it does its job as expected.

Here are my config files, maybe to compare settings like acceleration, E-jerk,... Configuration.zip < https://github.com/MarlinFirmware/Marlin/files/4410644/Configuration.zip> Configuration_adv.zip < https://github.com/MarlinFirmware/Marlin/files/4410645/Configuration_adv.zip

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub < https://github.com/MarlinFirmware/Marlin/issues/17342#issuecomment-606773983 , or unsubscribe < https://github.com/notifications/unsubscribe-auth/AEHQ2JDBQG34PUYSMZVYDKTRKITSLANCNFSM4LW33CGA

.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/17342#issuecomment-606780696, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAMPPKS64M6XGUXUT6YIQNLRKIVEDANCNFSM4LW33CGA .

[thinkyhead]

First, be sure to turn off all acceleration and speed tuning in your slicer. Prusa Slicer and Cura are both prone to inserting a lot of parameter changes, and this can sometimes interfere with the planner.

Unfortunately it is not a simple thing to debug dynamic issues of this kind without lots of data collection and isolation of effects. So we will need to gather as much logging as possible to determine root causes.

One thing I would note is that when doing curves you are likely to get a greater variation in linear speeds and constraints on those speeds. If you have your movement speed set very high in the slicer so you can get fast curves, you will also get a lot of places where your printer's maximum constraints come into play to alter the speed. So, you can try setting very high max-accel and max-speed values on the printer to remove those constraints.

Curves with lots of segments are also a bit more demanding, so you may also be hitting computation limits in some cases, and slowing down of the planner to keep the buffer full. If your board has lots of SRAM you can increase the buffer sizes and set the slowdown limit to a smaller proportion.

We did just fix an issue with G2/G3 arcs, but your slicer probably isn't producing those….

[thinkyhead]

One of the settings I saw CH3D point out recently was the "minimum segment length" setting in the slicer. This makes sure not to flood the machine with too many tiny segments, when a minimum length of 0.6mm would do just fine for most applications.

I don't mean to suggest that tuning slicer settings and reducing load on the machine is the ultimate solution for JD (and LA) issues, but it will help in the isolation testing.

[ktand]

These are the acceleration parameters currently set in the slicer. I will set them to 0 so that the printer defaults are used (I will also reset the printer configuration to ensure no parameters has changed) and try another print.

Regarding the slowing down I've tried the following:

• Enabled SLOWDOWN with a SLOWDOWN_DIVISOR of 2. No difference.
• Increase the BLOCK_BUFFER_SIZE to 64, no difference.

I'm printing from SD.

Is there a different how the planner treats segments with JD vs classic jerk enabled, except from generating segments with different acceleration/deceleration? With classic jerk the print is very smooth.

Tried to find a setting regarding minimum segment length but the only settings that I could find are these:

[thinkyhead]

Remember to increase the SLOWDOWN_DIVISOR if you increase the number of buffer lines, otherwise it slows down too soon. With 64, a divisor of 16 should be good.

[ktand]

I tried without SLOWDOWN but with a BLOCK_BUFFER_SIZE of 64, no difference.

[thinkyhead]

Is there a different how the planner treats segments with JD vs classic jerk enabled…?

There is a difference in how much acceleration and deceleration are applied at the segment junctions. And there are more (expensive) calculations done at each segment junction.

Ideally, we'll need to put together a table / graph of the speeds that are being applied at the junctions, comparing classic jerk to junction deviation, and both of those to the best desired speeds.

[CarlosGS]

Hi! Thanks for looking in to this! Is JD applied to each new motion regardless of length?

[thinkyhead]

🌊 Is JD applied to each new motion regardless of length? 🦁

Yes.

[CarlosGS]

OK, thanks. (I didn't put those icons.. new bug report? :p)

[qwewer0]

Tried to find a setting regarding minimum segment length but the only settings that I could find are these:

@ktand Where did you found it? Is it PrusaSlicer? Can't find it on 2.2

[thinkyhead]

Since this has become a duplicate of 17146 I am closing that issue to reduce noise.

[richfelker]

@thinkyhead see my comment on the duplicate issue: https://github.com/MarlinFirmware/Marlin/issues/17146#issuecomment-606901454. Sloppy/low-res slicing is not a solution; it breaks other things.

[ktand]

Tried to find a setting regarding minimum segment length but the only settings that I could find are these:

@ktand Where did you found it? Is it PrusaSlicer? Can't find it on 2.2

@qwewer0 I'm using Slic3r++ 2.2.48

[DaMadOne]

I was in the middle of writing a reply in the other report when @thinkyhead closed it so I'm just copying what I had started to type over there. It's a good idea to consolidate it to one thread anyways.

@swilkens wrote

If this is an issue specifically with the SKR Mini E3 v1.2 and maybe with other SKR boards too, then how can we make sure of it, then solve it? I'm open to ideas.

Build back your original board, use the same firmware options and verify on the original board with the same gcode?

My board is an SKR E3 DIP but that's basically the "same" as the mini I think. I do still have my original creality board but that is different stepper drivers(A4988). This weekend I could try swapping it back in just to test but I'm not sure if I could enable everything without running out of memory on it. Probably not, but i can try.

@CarlosGS @qwewer0 @ktand @rado79 and any others I may have missed. Out of curiosity what stepper drivers and exact main board is everyone using.

SKR E3 DIP v1.1 and all 4 stepper drivers are TMC2209's on my printer.

Like @thinkyhead said we need to start collecting data and logging. To try and get it as consistent across the board we should all decide on or make a fairly quick printing test model that we can all use and a list of what data we should all collect. I'm probably not the best to make those decisions but if someone writes out an almost step by step and what data points to record I'll certainly do it.

It looks like M928 can produce a log of "console and host input" and send it to the SDcard to easily grab. Is that the kind of logging you are talking about @thinkyhead? Also what M111 level would be helpful for this?

[skarcha]

Hi! I don't know if this help, but I'm having same problems. CJ is better but I got unexpected beheaviour on some parts. Two videos:

Junction Deviation 0.013 Classic Jerk

  #define DEFAULT_XJERK 10.0
  #define DEFAULT_YJERK 10.0
  #define DEFAULT_ZJERK  0.3

GT2560 Motherboard with mega1280. All stepper drivers are TMC2208 as standalone.

S_CURVE_ACCELERATION enabled. #define BLOCK_BUFFER_SIZE 32 NO Linear Advance

[CarlosGS]

BQ Zum Mega 3D with integrated DRV8825 drivers

[rado79]

@CarlosGS @qwewer0 @ktand @rado79 and any others I may have missed. Out of curiosity what stepper drivers and exact main board is everyone using.

BTT SKR1.3 and TMC2208/2209, 24V

[ktand]

@thinkyhead

I have now configured the slicer to use the same defaults as the printer's. Unfortunately this didn't help.

#define DEFAULT_MAX_FEEDRATE          { 200, 200, 30, 120 }
#define DEFAULT_MAX_ACCELERATION      { 2000, 2000, 200, 10000 }
#define DEFAULT_ACCELERATION          2000    // X, Y, Z and E acceleration for printing moves
#define DEFAULT_RETRACT_ACCELERATION  2000    // E acceleration for retracts
#define DEFAULT_TRAVEL_ACCELERATION   2000    // X, Y, Z acceleration for travel (non printing) moves

Start of G-code script:

M201 X2000 Y2000 Z200 E10000 ; sets maximum accelerations, mm/sec^2
M203 X200 Y200 Z30 E120 ; sets maximum feedrates, mm/sec
M204 P2000 R2000 T2000 ; sets acceleration (P, T) and retract acceleration (R), mm/sec^2
M205 X10.00 Y10.00 Z0.40 E4.50 ; sets the jerk limits, mm/sec
M205 S0 T0 ; sets the minimum extruding and travel feed rate, mm/sec

Inspecting the G-code file in S3D shows no speed changes in the critical areas. (Not sure I would be able to seem them if there were any though).

Regarding your suggestion:

So, you can try setting very high max-accel and max-speed values on the printer to remove those constraints.

what would be suitable values for max-accel? And for me to be sure I make the right modification, is it the DEFAULT_MAX_ACCELERATION or the DEFAULT_ACCELERATION we're talking about? I've always wondered how the DEFAULT_MAX_ACCELERATION relates to the DEFAULT_ACCELERATION. Is that just a limit or is the DEFAULT_MAX_ACCELERATION used by the planner?

[qwewer0]

@CarlosGS @qwewer0 @ktand @rado79 and any others I may have missed. Out of curiosity what stepper drivers and exact main board is everyone using.

SKR Mini E3 v1.2, TMC2209

[Viking117]

My board is an SKR E3 DIP and TMC2208 UART drivers. But the result is the same.

[Roxy-3D]

Is that a Face Mask holder for a hospital? We are printing some thing very similar to what your pictures shows in Houston. Except ours say "Houston Strong" on them!

[ktand]

@Roxy-3D Yes it is. Link. I've delivered two batches to a local hospital.

[Viking117]

I am in complete confusion. I tried different combinations (turned on and off) of parameters: LIN_ADVANCE S_CURVE_ACCELERATION CLASSIC_JERK But I always got pimples on my model, sometimes even on straight lines. I tried to increase the maximum resolution to 0.8, the result is better but not perfect. Photo in my post on reddit https://www.reddit.com/r/ender3/comments/ft3fse/pimples_when_printing_a_3d_printer/

Is it really necessary to return to the stock board and marlin 1,1,9? (

[CarlosGS]

With PrusaSlicer, in my case the jittering motion happens on the "gap fill" layers (the white traces)

Maybe the cause is that these look like arcs to us, but the gcode is different.

This is an arc in PrusaSlicer:

G1 X42.099 Y31.207 E0.10230
G1 X43.391 Y29.547 E0.17992
G1 X44.569 Y28.161 E0.15551
G1 X45.807 Y26.811 E0.15659
G1 X47.091 Y25.514 E0.15609
G1 X48.420 Y24.268 E0.15574
G1 X49.788 Y23.074 E0.15526
G1 X51.682 Y21.563 E0.20715
G1 X52.647 Y20.832 E0.10354
G1 X54.132 Y19.786 E0.15529
G1 X55.144 Y19.120 E0.10360
G1 X57.732 Y17.530 E0.25974

And this is the parallel arc segment for "gap fill" in PrusaSlicer:

G1 F7056.755
G1 X56.875 Y18.516 E0.00036
G1 F6344.481
G1 X55.363 Y19.465 E0.10529
G1 X54.418 Y20.079 E0.06647
G1 F6581.463
G1 X54.412 Y20.084 E0.00043
G1 F6541.549
G1 X54.359 Y20.120 E0.00367
G1 F6525.710
G1 X52.886 Y21.159 E0.10338
G1 X52.566 Y21.393 E0.02269
G1 F6783.652
G1 X52.560 Y21.398 E0.00046
G1 F6517.417
G1 X51.930 Y21.883 E0.04563
G1 X50.318 Y23.158 E0.11800
G1 F6861.681
G1 X50.312 Y23.162 E0.00039
G1 F6617.866
G1 X50.046 Y23.383 E0.01958
G1 X49.192 Y24.121 E0.06381
G1 F6822.325
G1 X49.186 Y24.126 E0.00041
G1 F6353.068
G1 X48.694 Y24.571 E0.03908
G1 F6333.234
G1 X47.377 Y25.807 E0.10673
G1 X46.932 Y26.241 E0.03670
G1 F6762.339
G1 X46.927 Y26.246 E0.00043
G1 F6512.778
G1 X46.100 Y27.090 E0.06787
G1 X45.896 Y27.307 E0.01709
G1 F6670.677
G1 X45.891 Y27.312 E0.00041
G1 F6227.178
G1 X44.879 Y28.434 E0.09080
G1 X44.120 Y29.307 E0.06950
G1 F6689.505
G1 X44.114 Y29.315 E0.00052
G1 F6283.570
G1 X43.710 Y29.806 E0.03789
G1 X42.420 Y31.449 E0.12439

Video of both gcodes:

[CarlosGS]

The same test but with Cura:

So the jittery arcs in Cura also have segments with uneven length. My guess is that these were being softened by Classic Jerk and are now being noticed.

[CarlosGS]

I have also recorded the PrusaSlicer example (updated previous post), and it shows arc segments of uneven length too. Sorry for the spam but it is looking promising!!

[XBrav]

Not sure if this'll help anybody here. Although the stuttering still occurs on my machine, the extrusion seems far more reliable:

With the SKR E3 series (Mini 1.2, DIP), I found the Z stepper was missing steps (verified by M48, and hearing the probe randomly hit the bed on second deployment). The extruder was also showing very minor inconsistencies, which was revealed when I was running a 0.8 nozzle.

I tried turning on and off Stealthchop, slowing down the probing, etc, and still had issues. On average, the probing was out 0.08 to 0.1.

I recently converted the printer to 24V to see if it was a voltage issue, but the issue persisted. Finally, I changed the motor timings in Configuration_Adv.h to the DRV8825 values:

define MINIMUM_STEPPER_POST_DIR_DELAY 650

define MINIMUM_STEPPER_PRE_DIR_DELAY 650

define MINIMUM_STEPPER_PULSE 2

define MAXIMUM_STEPPER_RATE 250000

Immediately, my M48 dropped to 0.001. The stutters are still there, but the extrusion seems far cleaner.

[thinkyhead]

I've always wondered how the DEFAULT_MAX_ACCELERATION relates to the DEFAULT_ACCELERATION. Is that just a limit or is the DEFAULT_MAX_ACCELERATION used by the planner?

These are just the defaults that you set in the configs. The planner uses the current values. The current values may been loaded from EEPROM or may have been altered by M201 / M204.

• Max Acceleration: All accelerations are clamped to this value.
• Acceleration: The acceleration that will be used for the next move.

Jerk, junction deviation, and move prediction rely on the current acceleration and feedrate values, so it does seem like changing the feedrate or accelerations constantly throughout a move could undermine the planner. It would be good to compare very clean G-code that doesn't change feedrates except when going between feature types (infill vs. walls) to G-code that changes motion parameters more often.

I'm not sure why the G-code above does separate G1 F commands when the F parameter could be on the end of the following line instead. That would make it slightly leaner.

[thinkyhead]

This is worth a read for anyone using 2208 and 2209… https://github.com/MarlinFirmware/Marlin/issues/11825#issuecomment-421809385

[qwewer0]

@thinkyhead Didn't worked for me. https://github.com/MarlinFirmware/Marlin/issues/17146#issuecomment-609656052

[DaMadOne]

This is worth a read for anyone using 2208 and 2209… #11825 (comment)

Hello all! so I read that and what I took away from it was maybe stealthchop was the issue? or am I reading that wrong?

I received a micro-swiss direct drive kit to go with their hot end I already had for my ender 3 pro and installed it. I wen't with 2.0.x bugfix(as of yesterday) just to have the latest and set it up. Calibrated e-steps, flow and k value. Need to tune more but these were what I thought to be important to get me going and testing for this "bug"

Part of me hoped that by switching to this setup and being able to really lower my retraction which I have not REALLY calibrated yet but am running at 1mm @ 25mm/s and am getting decent results. Add that to a much lower k value of 0.08 and I was hoping the issue would go away. *hint... no such luck! :(

I broke out the trusty tux model and sliced out a bit of the middle section and after the first slower layer printed I could immediately hear the familiar sound of the extruder going nuts, but much more subtle now. In the end the "skin" of the tux model ended up looking almost the same as it had with JD/LA enabled before the direct drive as outlined in #17146 OP.

So I thought lets test out this stealthchop theory and printed the same gcode again but in the middle of it I sent an 'M569 S0 E' which I knew put the extruder stepper into spreadcycle mode because I could hear it but I also verified it on the Ender 3 LCD in advanced settings/TMC Drivers and also with M569 after the print was done which showed "E driver mode: spreadCycle"

I printed half the model with stealthchop and half with speadcycle and can't tell the difference. The extruder stutter remained even with spreadcycle.

@thinkyhead. Since I'm using a board with driver sockets I'm willing to order another stepper driver or two and test with them to try and see if this is a TMC2208/9 issue but I would like some input from someone in the know about what to order. A different TMC driver(maybe 5160)? A bog standard A4988? DRV8825? I would even ask if anyone has a few different drivers sitting around who might not have the time or want to test them out to mail them to me and I'll mail them back. I would just ask that the sender REALLY clean them with some IPA and I would do the same before sending them back.

[qwewer0]

So I thought lets test out this stealthchop theory and printed the same gcode again but in the middle of it I sent an 'M569 S0 E' which I knew put the extruder stepper into spreadcycle mode

@DaMadOne Isn't the X and Y axis is the problem here?

[skarcha]

Tested with A4988 drivers. Same issue.

[XDA-Bam]

I can confirm that I have the same issue on the curve on this part from a TeachingTech Thingiverse collection. It only appears around layers 100 to 125 at 0.2 mm LH.

Hardware: Stock Ender 3 Pro Creality 1.1.4 board ATMega 1284 A4988 drivers

Firmware: Marlin 1.1.9 (1.1.x release branch from 05.04.20, NOT the bugfix branch) Current config --> Also tested with different settings: Linear Advance en-/disabled, S-Curve en-/disabled, Adaptive Step Smoothing en-/disabled. Those have no effect on the issue.

Slicer: Cura 4.5, acceleration & jerk control disabled GCode --> I can also confirm the already mentioned inconsistent / quickly alternating segment length on the affected layers in the affected regions of the part. These are visible in the Cura preview. While on non-affected layers, segments in the curve are of about equal length, the segments on the affected layers are alternating short/long/short/long in comparison. However, this does not affect prints with classic Jerk at all. Only prints with Junction Deviation are deteriorated.

[thierryzoller]

Same issue with Sidewinder-X1 - Reducing resolution did not help. Slicing with Cura produces worse results than Slic3r, however both are back to great once I deactivate JD

[XDA-Bam]

I have found a workaround for the issue, which eliminates the problem for my test print: By increasing MIN_STEPS_PER_SEGMENT from the default 6 to 16 (which is 1/2 nozzle diameter for me), the curve becomes perfectly smooth when using JD. I didn't test any lower values, so 10 or 12 steps per segment may already be enough. This is certainly not a fix, because it slightly reduces precision.

[thinkyhead]

It's very interesting that increasing MIN_STEPS_PER_SEGMENT has a positive effect. Certainly we don't want a million blocks with only one step in them, since this makes any acceleration / deceleration turn into a floating point square root party, and there are bound to be other potential pitfalls with many tiny segments.

Once I have more free time I will have to dive into a deeper analysis to see what the MIN_STEPS_PER_SEGMENT change is mitigating, and then figure out an earlier point to apply mitigation.

In the meantime, I would enjoy hearing from others what their experiences are in playing with MIN_STEPS_PER_SEGMENT, and if there are any "magic" thresholds that differ depending on hardware.

[Grogyan]

For me I have to set JD to its lowest possible value of 0.010 Anything higher creates artefacts

[BarsMonster]

I do not see slowdown on SKR PRO during printing of gcode with lots of small segments. But surface quality difference between JD and Jerk is still there. MIN_STEPS_PER_SEGMENT did not changed it much.

I see hardly any differences in surface quality for MIN_STEPS 6 and 16. MIN_STEPS 16 has slightly less "noise" on the surface, but still very far from JERK quality.

Jerk surface quality is better with all MIN_STEPS values (16, 6, 1).

[XDA-Bam]

@BarsMonster You're using different hardware than me. Are 16 steps also equivalent to 0.2 mm in your case? That's what you should aim for. I Have 80 steps/mm on X and Y, therefore MIN_STEPS_PER_SEGMENT = 16 filtered out all the tiny segments <0.2 mm from the GCode.

[XBrav]

What size circumference are you using to see the stutters? I've put together a test stl / gcode just to see if I can see any artifacts. Here's the files. You may want to stretch it vertically if you want more comparison layers, but I included a gcode file from S3D at 0.2mm layer height at 0.4mm:

https://drive.google.com/open?id=1zZSb3GSWtmA65jmILRCykF0DZYADhaPb

Each ring has a different edge count. Bottom layer is a standard circle in Fusion 360. The next layer has 1000 edges, followed by 500, 100, and 50.

One change I've been playing with is increasing the buffer size. I noticed 16 seems to be a bit rough with lots of tiny movements. With my 32 bit board having lots of RAM, I increased it to 128:

#if ENABLED(SDSUPPORT)
  #define BLOCK_BUFFER_SIZE 128 // SD,LCD,Buttons take more memory, block buffer needs to be smaller

My results seem to be quite smooth, even with the MIN_STEPS_PER_SEGMENT = 1. This is on an Ender 5 with a E3 DIP STM32F103RC with all steppers as TMC2208 and LA enabled. I also ran the print at 300% speed just to see if I was saturating the 128 buffer. Stealthchop was turned off for the extruder as I managed to stall it with it enabled.

EDIT Added a 'tall' version that's stretched 500% on the Z. Will update with photo.

EDIT 2 Tall results at 300% speed:

[BarsMonster]

@XDA-Bam @XBrav I was testing on R=8mm features, which is probably too tight. Probably cone in vase mode would be more efficient and cover all curvatures. My curves are exported with maximum resolution in Fusion, and sliced in Cura with maximum resolution so it definitely pushes the limit.

Steps per mm is 160 in my case, so yes, seems like higher MIN_STEPS would be needed in my case according to your formula. I will test min steps = 32.

BLOCK_BUFFER_SIZE is 64 in my case.

[BarsMonster]

@XDA-Bam Tested with MIN_STEPS_PER_SEGMENT=32. "Noise" is still the same in amplitude, but lower in frequency. Probably on larger circles it would be less visible, but at R=8mm it is still very significant and significantly degrades surface quality.

[qwewer0]

Could I get a little information about BLOCK_BUFFER_SIZE, BUFSIZE, TX_BUFFER_SIZE, to what those do in our cases?

[swilkens]

I do not see slowdown on SKR PRO during printing of gcode with lots of small segments. But surface quality difference between JD and Jerk is still there. MIN_STEPS_PER_SEGMENT did not changed it much.

I see hardly any differences in surface quality for MIN_STEPS 6 and 16. MIN_STEPS 16 has slightly less "noise" on the surface, but still very far from JERK quality.

Jerk surface quality is better with all MIN_STEPS values (16, 6, 1).

I can't seem to replicate this on my SKR Mini V1.2 running 2.0.5.3, also printed with JD and Classic Jerk. Sliced with PrusaSlicer 2.2.0 at max resolution possible. S_CURVE_ACCELERATION was enabled while LINEAR_ADVANCE was disabled.

I'm also not sure this is the same issue as OP, who seems to have shown this happens with fill segments - which this model doesn't have.