[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 <#17342 (comment)>, 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 ***@***.***>: > 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 > < #17342 (comment) >, > 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 <#17342 (comment)>, 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: #17146 (comment). 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

[swilkens]

Bot wants some attention

[amoose136]

I have noticed this behavior but I had assumed this was a buffer overrun underrun issue that could be fixed with something like an arc-welder. Has anyone tested that the result is the same with arcs vs a bunch of linear segments?

[XDA-Bam]

I have noticed this behavior but I had assumed this was a buffer overrun issue that could be fixed with something like an arc-welder. Has anyone tested that the result is the same with arcs vs a bunch of linear segments?

Segmenting is going to be different when using ArcWelder comapred to the "default" GCode generated by the slicer. I would expect the result to at least look different from the regular print - could be worse, but could also be much better. As far as I know this hasn't been tested and published. In any case, it would be workaround and not a fix.

Feel free to check it and please let us know about the results! :)

[brunoosti]

So.. I've been testing Junction Deviation with Arc Welder plugin in Cura. It seams to "fix" JD stuttering in curves problem.
Making some tests right now, but the part that always gave me zits before is completely smooth. No rattling during curved moventes and great corners.
The only thing a bit different is that the extruder is more aggressive on the corners with linear advance.

[brunoosti]

Now the printer "chops" the travel moves (?) wile going up on the mesh level fade out. Like it is dividing it in 2 or more movements. This didn't happen before. After the fade (1mm) it travels in one movement segment again.

[The-Fonz]

So.. I've been testing Junction Deviation with Arc Welder plugin in Cura. It seams to "fix" JD stuttering in curves problem.

I observed the same problems on fb9502e (origin/bugfix-2.0.x), stuttering on curved surfaces using gcode sliced by Cura. It was "solved" by using ArcWelder, and came back every time I did not use ArcWelder, on various models.

It was solved completely by commenting out #define JD_HANDLE_SMALL_SEGMENTS in Configuration.h. Is this the best solution, or should I use "classic jerk" instead?

[mydevpeeps]

Using a Creality CR-10 S5 with v2.2 silent board, TMC2208_STANDALONE, Linear Advance Disabled, Bugfix 2.0.9.1 (july).

I had this problem as well and disabling linear advance (because its not compatible with my board anyway) helped a lot. I always have arc-welder on, and leave accel/jerk off in cura, and just use the printer defaults (that i set) from EEPROM. Even with Linear Advance enabled but set to K0 i still saw this effect. It's really obvious if you just print a test cylinder shape from the cura test shapes extension (40mmx10mm).

Based on the above I have now commented out JD_HANDLE_SMALL_SEGMENTS, and increased SLOWDOWN_DIVISOR from 2 to 4. I will report back my findings and I hope to see this get resolved.

[VanessaE]

I know this issue is pretty old now, but I figured I should add my remarks since it's still relevant...

I've been working on a redesign/rebuild of my larger printer, and it kept having stuttering problems going around curves, like the bow of a Benchy. Couldn't figure it out initially, then found this issue. Commenting-out #define JD_HANDLE_SMALL_SEGMENTS fixed the stuttering entirely. That machine runs bugfix-2.0.x commit 01d1192, on an SKR v2.

For comparison, my smaller machine runs bugfix-2.0.x commit e2480d4, on an SKR v1.4, and that one works fine with that setting enabled. I guess that commit predates whatever change created this stuttering problem.

(oh, and github-actions bot can go jump in a lake 😛 )

[mydevpeeps]

My issue also went way when I disabled that setting...

[VanessaE]

Just to satisfy the bot, and as a follow-up.....

I ran into this issue again when I upgraded my printer's firmware recently (to v2.0.9.3 stable, so no longer on the bugfix-2.0.x branch), and it turned out that I had skipped changing the buffer size and divisor settings per bcat's remarks in the commit linked above, as I had done before^[1].

Once I had the tweaked the buffer settings in place along with disabling small segment handling, the stutter disappeared.

So this issue can't be closed just yet, I guess.

---

[1] I had to apply my configs by hand this time around, due to too much divergence. Always an error-prone process, I guess.

[tombrazier]

I have been having similar behaviour and have identified a cause. It cannot explain the OP's problem because it was introduced in #22599 in August 2021. But it might explain the problems others have subsequently reported. I will submit a PR.

The cause in my case, in case you want to know, is that the arc code can inject very short segments at the end of an arc since #22599. These then get aliased when converted to steps in the planner and that can make the segment look like it has a larger angle from the previous segment than it really has. Then the subsection of JD that kicks in for small segments sees a relatively large angle with a relatively short segment, concludes that a very small circle is being drawn and limits the cornering speed accordingly.

[tombrazier]

Anyone fancy testing to see whether #24362 helps you?

[XDA-Bam]

Anyone fancy testing to see whether #24362 helps you?

Thanks for bringing this up. It may help some users affected by that bug. In general, the issue discussed here, is much older than the ARC_SUPPORT-related problems and originates in slicer problems/bugs. I think there were even a couple of users in this thread reporting that prints using arc commands (G2/G3) eliminated the original problem discussed here, which is caused by slowdowns on tiny segments with incorrect curvature.

If there was an ARC_SUPPORT bug which also introduced such tiny segments, it may have triggered the same underlying problem discussed here.

[tombrazier]

Ah, it's a case of confirmation bias. I saw "curve" and "stutter" and identified this with my problem with arc support.

However the underlying cause of stuttering in junction deviation may be the same. That is, with very short segments JD is affected by aliasing and gets the angle calculations wrong. Possibly JD should use target rather than steps_dist_mm - but that would entail another segment length calculation with its attendant sqrt().

[thinkyhead]

I would like to continue to analyze this issue and find a good methodology to test and isolate and solve issues like this one. I could use a lot of help and guidance in figuring out the best way to accomplish it. Because GitHub is so noisy and I usually have a dozen things going in parallel, Discord is going to be the better place to collaborate and figure this out. Thi is also connected to the bigger issue of how to improve the reliability and stability of Marlin's components generally as we go forward. I took a peek at Klipper source code yesterday and saw some things that inspired and humbled me. So I'm open to any and all suggestions about improving the quality of this project and its processes.

[fausby]

Similiar problem on GT2560 V4 A20 with Marlin 2.1.2.1
Instead of acceleration changes, I have quick retractions and unretractions in the corners.

CLASSIC_JERK enabled
S_CURVE_ACCELERATION disabled
ADAPTIVE_STEP_SMOOTHING disabled

[XDA-Bam]

Similiar problem on GT2560 V4 A20 with Marlin 2.1.2.1 Instead of acceleration changes, I have quick retractions and unretractions in the corners.

CLASSIC_JERK enabled S_CURVE_ACCELERATION disabled ADAPTIVE_STEP_SMOOTHING disabled

Hi. This doesn't sound like it's related to the issue discussed here since you don't use Junction Deviation. Further, retractions are normally controlled by the slicer and this issue affects curved surfaces while you report problems in corners. Probably best to ask around in the Marlin Discord channel for some help with diagnosing your issue.

[rabirland]

A year later hopefully not late to the party.

I was also suffering from this, and extreme layer shifting issues at "high" speeds (150+).

Recently I realized that I still have ADAPTIVE_STEP_SMOOTHING enabled, but since I have TMC2209 decided to turn it off, which instantly solved both my layer shifting issues AND the stuttering curves issues. I would note I also disabled NONLINEAR_EXTRUSION, both flag causes increased amount of step sampling.

Having ADAPTIVE_STEP_SMOOTHING enabled, I could only print with 5k acceleration at 200mm/s without layer shifting or 3k accel 150mm/s before the curves began to stutter.

Disabling ADAPTIVE_STEP_SMOOTHING I could test the machine with 15k accel 300mm/s with zero layer shift or curve stutter.

ADAPTIVE_STEP_SMOOTHING seem to severely decrease the potential torque of the motors in exchange of being completely silent, causing shifting even in relatively low speeds, without the motors running on unnecessarily high currents (1050mA in my case when it was relatively stable).

Combining ADAPTIVE_STEP_SMOOTHING and stealthChop together make the machine useless, skipping steps even at the 3-4k acceleration range.

Find my configuration.h and configuration_adv.h on the links.