Marlin: [BUG] Rapid changes of acceleration break linear advance when using Junction Deviation

[BarsMonster]

Description

When objects sliced by Cura with acceleration control enabled - Cura generate g-code with lots of speed changes, which is not invalid. When this g-code is printed with linear advance and junction deviation enabled (M900 K2) - sometimes extruder is missing alot of steps, and this breaks everything. This is not hardware related, as position of defects is consistent on every print, and also alot of hardware tweaks did not solved the issue. Example g-code is attached.

It seems geared extruder show less of an issue (i.e. looks like fixed number of steps are missing). So with Esteps 415 issue is much less, with Esteps 93 it is much more significant.

Lots of hardware tricks tried - with no luck:
Different drivers: A4988, TMC2209 (spreadcycle). Microstepping 1/16 and 1/8 (to reduce step rate). EMI supressors on E-motor, series diodes (for A4988). Different marlins: 1.1.9 and latest 2.0 x. With different extruders (stock one with Esteps 93 and geared BMG with Esteps 415, with different spring tension. This is definitely not filament slipping). Also tried different oversized power supply to ensure there is no power sag.

Steps to Reproduce

1. Print attached gcode on bowden 3D printer with Junction Deviation enabled and M900 K2 (issue will still be significant at M900 K1)
   5mm_acceleration_stress_LA.zip - cleaner example, with no timelapse code

Expected behavior:
Everything is smooth and extruded uniformly.

Actual behavior:
Steps are severely missing on extruder, which makes printing not feasible for K=1 and higher.

Additional Information

• latest 2.0.x bugfix

[shitcreek]

How did you arrive at the K Factor value of 2? Did you do a k factor calibration test? http://marlinfw.org/tools/lin_advance/k-factor.html
2 is at the high end for lin advance 1.5
How fast are you printing at? What is the acceleration rate? Configuration files?

[Powerprobot]

I think every change of acceleration need to be a recalibration of K-factor. Marlin use for lin advance only the single K-factor with speed and length without to check the acceleration. If Marlin use K-factor depending from acceleration, Marlin need massiv more calculations, especially if S-Curve enabled.
If you @BarsMonster use Cura accelerations, so deactivate lin advance and activate Cura "Coasting" and flow-adjust. Find the best Compromise.

[thinkyhead]

Cura is attempting to make things work well on a machine that doesn't have independent intelligence to adjust flow and speed and so on. If you like the way Cura tunes things with its internal logic, it would be a good idea to turn off all of Marlin's advanced features.

[boelle]

@BarsMonster still having issues?

[boelle]

given the lack of activity and that this is more likely to be cura that screws up with marlin by trying to optimize independant of marlin i will close this one

we can always reopen

[BarsMonster]

@boelle Yes, issue is still there and does not allow me to get perfect prints even with linear advance disabled, and cura acceleration disabled.

Even without linear advance and without acceleration changes - issue is still there, though very rare to reproduce, and is less terrible, but it is still there. Here and there you get spots of underextrusion on outer shell and it does not look perfect.

It seems that it is some sort of race condition somewhere in the Marlin's core, which causes to skip extruder steps in certain conditions. And changing acceleration makes it more significant.

I believe acceleration changes should not cause extruder step skips so massively and consistently, as it generates valid g-code. Enabling acceleration control in Cura is just a convenient way to show this error in reproducible manner.

[BarsMonster]

@boelle Can we reopen it?

[BarsMonster]

If you @BarsMonster use Cura accelerations, so deactivate lin advance and activate Cura "Coasting" and flow-adjust. Find the best Compromise.

While I agree with you from the practical side, behavior of Marlin here is definitely completely broken by valid G-code. Is looks like completely broken math, when E stepping is stopped for some time, and then restarted. Again, due to consistence of under-extruded areas it looks like code error, and not mechanical issue.

[Vertabreak]

Ive yet to see a valid k value greater then 0.5 with any filament on any of my 6 printers k2 seem very high and is considered the max k. i would totally slice the model shown if you post the stl for my printer and post my result.

[ManuelMcLure]

The sort of “chattering” under extrusion you show in the first picture is a lot like what I saw on some prints when I had Linear Advance enabled. And I was not using acceleration control or jerk control (PrusaSlicer) and my K was only 0.7.

[BarsMonster]

@Vertabreak @ManuelMcLure This is for Bowden, that is the reason for high K value. Anyways, issue is not in K value itself. I am pretty sure that you will be able to print model with your settings - the issue is not that I am unable to print it. If I remove all acceleration control, linear advance, e.t.c. it will print just fine. The issue is that there seems to be some sort of math error in the core of step calculation code in this corner case, that is rarely used (linear advance enabled, bowden = high K value, rapid acceleration changes).

Model I was printing is this one: https://www.thingiverse.com/thing:24238

[thinkyhead]

Let's just say it's a "feature, not a bug" that Linear Advance doesn't like frequent changes in acceleration. Cura is naively assuming you're not using such features.

[ManuelMcLure]

Unfortunately, there are still major problems with Linear Advance even if not using acceleration control.

[boelle]

@BarsMonster is the issue still the same with all the updates in the last 8 days?

[boelle]

btw, who can confirm there is an issue? use the same configs as OP and the same hardware if possible

[BarsMonster]

@boelle I've tested with latest Marlin-bugfix-2.0.x and currently it is much worse, "pulsating" extrusion starts from the very first layer, and under-extrusion is so severe that print cannot stick to bed.

Not sure whether it is code change or config change. Please see attached latest config files for 2.0.x and latest cleaner gcode.

Marlin_config.zip

5mm_acceleration_stress_LA.zip

[boelle]

just remember i'm not a code guy, i just keep the issue list, making sure issues dont die

@thinkyhead is the maintainer that does code arround here :-)

[BarsMonster]

I compared behavior on K=0.5 and K=1. On K=0.5 it is not terrible, but far from perfect. At K=1 you can see that it looks like skeleton. At K=2 it is not printable. So currently it looks like linear advance is completely unusable for Bowden setups, and I assume for direct extruders it might still show rare glitches.

[Vertabreak]

think ill take video of printing the model linked with my machine and posting it.

[sjasonsmith]

@BarsMonster, can you try your configuration with this branch? It addresses a LA issue which might be related to this.
\

This is currently experimental, and not cleaned up like I would a normal PR. You should completely replace my configuration files with your own.

[BarsMonster]

@sjasonsmith I tested EXPERIMENTAL_LA and got identical result for K=1.

BTW, just weighted the parts. Cura's simulation shows 4g, with K=0 actual print weight 3.47g, with K=1 weight is 1.15g. So there is severe underextrusion.

[Vertabreak]

K1 seems extremely high even on a 2 foot Bowden tube have you run calibration to find valid k value.

[BarsMonster]

@Vertabreak Yes, I did calibration and got optimal value around 2. When not using acceleration control - prints look almost ok (corners are square), but there are still rare glitches (pulsating extrusion). Anyways, my understanding is that from math point of view for any K value and regardless of whether acceleration control was used or not - weight of the print should be the same (i.e. same total length of filament pushed though).

[Vertabreak]

soon as i sort out cura not starting ill try printing the model and posting results to compare.

[BarsMonster]

I spent like 0.5kg of PETG for many dozens of test prins and finally narrowed down on an issue. I fell back to manufacturer config and 1.19 firmware, re-merged config into recent 2.x bugfix version, and started to re-introduce configuration changes one-by-one until I found it:

@thinkyhead It appeared that Junction Deviation (0.022 in my case) combined with Linear Advance and acceleration control in Cura leads to spectacular failure. Without acceleration control (constant acceleration) - print is still significantly degraded, so we cannot attribute it to Cura's quirks.

On the photo left print is nearly perfect. Very slight bulging on the corners which looks worse than it is in reality due to illumination. Medium one has lots of defects on the shell, might be more issues hidden inside. Right print show the same terrible under-extrusion when using both linear advance, junction deviation and lots of acceleration changes in g-code.

[sjasonsmith]

Does it print well if you use only JD and Cura Acceleration Control (no Linear Advance)?

[ManuelMcLure]

I know that in my tests I found that switching from JD to classic jerk greatly reduced but did not entirely eliminate the extruder rattling, so @BarsMonster 's results are in line with what I was seeing.

[BarsMonster]

@sjasonsmith I've tested it, and it seems JD with Cura Acceleration Control does not cause the issue. There are print defects in this configuration, but they seems to be caused by much higher print speed when not using linear advance (defects are exactly the same with Jerk).

So only Junction Deviation + Linear Advance seems to be broken, and JD+LA+Acceleration Control brakes it much more severely.

[sjasonsmith]

I have concluded that Linear Advance has significant issues in general. It results in very inconsistent step rates, and I haven't found an easy way to resolve that. I personally don't even use Linear Advance, so I don't intend to put further time into finding a solution for it.

[BarsMonster]

@sjasonsmith Is it inconsistent on AVR where computing power is limited, or on ARM too?

[sjasonsmith]

I have been specifically testing on AVR, but I expect it to have issue everywhere.

[richfelker]

I may be experiencing this with flexible material, where I'm using K=3.8 (calibrated with the linear advance test pattern, yes it's high but this stuff is a genuine spring and the printer, Ender 3, is bowden). Until seeing this report I hadn't thought to consider the problem might be related to junction deviation. In any case, yes K values larger than 1 or even larger than 2 are meaningful.

With K=0.6 and normal PLA, I see no problem whatsoever; both linear advance and junction deviation seem to have been pure improvements.

[richfelker]

OK, I have a print that's definitely hitting this with K=0.6. Severe underextrusion of straight thin walls in layers with lots of small corners. Rebuilt Marlin with classic jerk and the problem goes away completely. I'll post a pic soon. Any additional information about my setup that would be helpful to provide?

[richfelker]

Left is with JD=0.05, right with classic jerk. Both K=0.6. Notice the underextrusion in the support structures which are part of the model (so no fishy Cura stuff like skipping retraction for supports that could cause such a mess). There are no acceleration or jerk changes after initial setup in the gcode.

[BarsMonster]

I did further tests to narrow down on the issue:

1) No differences identified between JD=0.022 and JD=0.05 pulsating under-extrusion is still there
2) No differences identified with DISABLE_MULTI_STEPPING
3) No differences identified for BLOCK_BUFFER_SIZE=16 and 32
4) No differences identified for printing via serial port or direct SD-card.

On the photo: No acceleration control, linear advance K=1

[boelle]

K1 is to high, try with K0.05

and try other slicers, cura does a lot of tricks (or so it has been said) that assume the printer cant do these things, and you can only guess if the printer can do a thing and the slicer does the same

try maybe prusa slicer

[richfelker]

@boelle: That's simply not true. The range of meaningful K values on a bowden is something like 0.4 for very rigid materials and tight tube clearance, up to 4 or higher for flex materials. 0.05 might be meaningful on a direct drive but I think the difference from K0 would be so small that you might as well just turn it off and avoid the computational complexity.

[boelle]

been doing a series of test prints lately and i have not been able to reproduce this one

will post some pics in a bit, but i dont use cura

[boelle]

https://photos.app.goo.gl/ohjSPgAm3JQcgEk18

[boelle]

My config for marlin Configuration.zip

[boelle]

have you checked if your nozzle is clean? ie take it out and heat it up with lighter and remove all filament so you can see light through it

on e3d nozzles you can use a 2mm drill bit to clean out from the filament side... but use the bit with your fingers and be carefull

when you got all filament out use a sewing needle to clean the last bit,

[richfelker]

A dirty nozzle is not going to violate conservation of mass. If there's really underextrusion you can measure it by putting a mark on the filament according to the total extruded length in the gcode file, and check whether the mark reaches the hole into the extruder when the print finishes. If it doesn't, then either the extruder is slipping or missing steps or the planner is moving the extruder axis less than the gcode tells it to do (logically skipping steps). The latter should be detectable in a simulation run not connected to any actual hardware.

[richfelker]

As an aside, I just started trying TPU and I've found calibration indicating a need for K>4 at 230 °C, but increasing the temp to 250 let me take it back down to 3.4. Just to confirm, again, that high K values are meaningful. I did not experience this issue even with K=5, but I'd already switched back to classic jerk because of it.

[BarsMonster]

@boelle Thanks for the tests, indeed your configs looks correct for reproduction of the issue.
Could you also attach g-code of one of the parts you were printing?
PS. Also, what is your board? Especially MCU.

[boelle]

mcu: re-arm (you would have known from the configs)

Here is the benchy: 3DBenchy_0.2mm_PLA_MK2.5S_1h50m.zip

i use prusa slicer and not cura, not sure if that makes any difference

[richfelker]

How is this "inactive"?! The OP replied just a week ago and there's clearly an issue that OP and others are involved in reporting test results on and debugging.

[kazooless]

I notice under-extrusion after enabling Junction Deviation in my config. If I go back to traditional jerk, there is no under-extrusion. That is the only change I make when troubleshooting this. I found this thread by searching for my problem. My version of Marlin is a little old now. It is from 09/17/2020 (I'm not sure where the exact version number is).

[thisiskeithb]

For those with these issues, have you tried the following tips (source):

• Some slicers have options to control the nozzle pressure. Common names are: Pressure advance, Coast at end, extra restart length after retract. Disable these options as they will interfere with Linear Advance.
• Also disable options like wipe while retract or combing. There should be almost no ooze, once the proper K-Factor is found.
• Recheck retraction distance, once Linear Advance is calibrated and working well. It may even be as low as 0, since pressure control reduces the material pressure at the end of a line to nearly zero.

[kazooless]

Update: After updating to v.2.0.4.4 I've spent the last several days testing @thisiskeithb's comments. I find I still need combing in Cura as well as retraction to keep stringing and blobbing away, but I've been able to tune my machine where there is no underextrusion now. So I am no longer reporting the same problem; just the opposite.

[BondarenkoA]

I confirm this issue too. MKS Robin nano, PrusaSlicer without any pressure controls. Lin adv with JD take the same under extrusion. Just rollback to classical jerk for good results with lin adv.

[BarsMonster]

On MKS Gen-L board I was able to reproduce consistent (same place on 2 prints of the same part) pulsating extrusion without acceleration control, linear advance (K=0) and with junction deviation disabled, just on 1 layer. I.e. these 3 options make this issue much more severe, but issue exist even without JD and without LA, just very rare. This line defect is quite long, under-extrusion is visible for ~70mm length of the perimeter. Also, printing outer perimeters first makes it more visible.

[BarsMonster]

After I migrated to SKR PRO 1.1, I was unable to reproduce the issue with migrated config. So the issue could be more reproducible on slower CPUs.

[thinkyhead]

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

[richfelker]

@BarsMonster: That does not sound like an accurate representation of the findings. Acceleration control has nothing to do with the segment sizes Cura produces. That's a function of the mesh resolution and deviation settings.

[BarsMonster]

@richfelker You are correct. I've retested it just now, not sure why I believed that. I've deleted comment with incorrect information.

[boelle]

@BarsMonster
Please test the bugfix-2.0.x branch to see where it stands.

[jpmath54]

Hi.
@BarsMonster
I might be wrong, but these value 'k=2' are insanely out of the range for standard filaments.
(Let's put aside TPU or Flex ones, can we?)

For PLA, with a correct direct drive extruder and short path between gears and nozzle, usual values are within the range [0. ; 0.2]
with a well fitted bowden with the range [0. ; 1.]

Second thing : when printing your K factor calibration pattern, you should also change your firmware printer settings (jerk, acceleration...) to the desired values as firmware value are generally quite different to the slicer ones.

I already saw people saying that any K factor value provide the same result, except that their built-in jerk and accel value prevent linear advance to even start to change anything...
I would think it is the case in you "K=2, JERK" example atop of this bug report.

Linear advance is meant to be tune with a "constant" set of move parameters. If you change your acceleration dynamically, there is no point in using Linear Advance: don't.

As you may now FDM printing is ruled by viscoelastoplastic fluid dynamics, so NO, there not any single reason at high extrusion speeds and accelerations that the amount of "asked" filament will eventually extrudes depending on your configuration...

You seem to know what you are doing , but I would also check whether your extruder is flowing nicely or not.
Any starting clog, bad exruder would provide approximatelly the same result as in your illustrations.

I would be more convinced you have an issue if posting a proper Kfactor calibration patern...

[richfelker]

I might be wrong, but these value 'k=2' are insanely out of the range for standard filaments.

My calibrated K for PETG with a bowden is 1.4. K=2 is high but not "insanely out of the range".

I already saw people saying that any K factor value provide the same result, except that their built-in jerk and accel value prevent linear advance to even start to change anything...

This is false. LA slows down the entire print speed if jerk and accel settings prevent keeping up with the necessary extruder pressure adjustments at the requested speed.

Linear advance is meant to be tune with a "constant" set of move parameters. If you change your acceleration dynamically, there is no point in using Linear Advance: don't.

Everything reported here was reproduced with acceleration and jerk control in the slicer completely turned off (i.e. using a fixed setting from the default or from custom start gcode).

As you may now FDM printing is ruled by viscoelastoplastic fluid dynamics, so NO, there not any single reason at high extrusion speeds and accelerations that the amount of "asked" filament will eventually extrudes depending on your configuration...

Unless the extruder gear skips or the extruder motor misses steps, the total extrusion volume (and the total integrated E-axis move) should be exactly the nominal amount, regardless of LA. This is completely testable.

Any starting clog, bad exruder would provide approximatelly the same result as in your illustrations.

If it were a clog the extruder would grind and the effect would not go away with different LA/JD/jerk settings.

I would be more convinced you have an issue if posting a proper Kfactor calibration patern...

This is really hard to do since the canonical pattern generator produces something with ooze/stringing all over the place that's destroyed when you remove it from the bed, and hard to photograph on the bed when your filament is black and bed is black. I actually use a one-wall skew-cylinder test instead, with Cura overhang angle settings tuned to switch speeds for about 1/4 of the circumference. It's easy to eyeball the appproximate K needed to get a consistent wall at the switchover using the Tune menu, then fine-tune it with a caliper.

[jpmath54]

Won't go in a quote war.

There is - in this whole thread - no reproductible method providing details to reproduce the problem or explain it on a standard setup.
(a piece of GCode is far from sufficient).

If you can't even make a "nice" canonical pattern to assess your K-factor value is good and not the result of a "not bad but not perfect" hardware, there is no point discussing further.
There are so many things that could go wrong, that I would put "Marlin code issues" in the last place of the stack.

To me this looks like people with a Traban trying to go fast like a Ferrari and ending up in the wall.

Go direct drive, fine tune your printer and don't ask the firmware to make your "standard hardware" printing faster than what is physically achievable, especially with a bowden setup, constant feedrate changes, and an elastic material.

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label / comment or this will be closed in 5 days.

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.