Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] Rapid changes of acceleration break linear advance when using Junction Deviation #15473

Closed
BarsMonster opened this issue Oct 6, 2019 · 61 comments

Comments

@BarsMonster
Copy link

BarsMonster commented Oct 6, 2019

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.

JunctionDeviation

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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Member

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
Copy link
Contributor

boelle commented Oct 12, 2019

@BarsMonster still having issues?

@boelle
Copy link
Contributor

boelle commented Oct 22, 2019

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

@boelle boelle closed this as completed Oct 22, 2019
@BarsMonster
Copy link
Author

@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
Copy link
Author

@boelle Can we reopen it?

@BarsMonster
Copy link
Author

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.

@boelle boelle reopened this Dec 16, 2019
@Vertabreak
Copy link
Contributor

Vertabreak commented Dec 16, 2019

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
Copy link
Contributor

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
Copy link
Author

@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
Copy link
Member

thinkyhead commented Dec 19, 2019

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
Copy link
Contributor

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

@boelle
Copy link
Contributor

boelle commented Dec 24, 2019

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

@boelle
Copy link
Contributor

boelle commented Dec 24, 2019

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

@BarsMonster
Copy link
Author

BarsMonster commented Dec 24, 2019

@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

pulse

@boelle
Copy link
Contributor

boelle commented Dec 24, 2019

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
Copy link
Author

BarsMonster commented Dec 24, 2019

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.

LA

@Vertabreak
Copy link
Contributor

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

@sjasonsmith
Copy link
Contributor

sjasonsmith commented Dec 24, 2019

@BarsMonster, can you try your configuration with this branch? It addresses a LA issue which might be related to this.
<link to experimental branch deleted>

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
Copy link
Author

@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
Copy link
Contributor

Vertabreak commented Dec 24, 2019

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

@BarsMonster
Copy link
Author

BarsMonster commented Dec 25, 2019

@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
Copy link
Contributor

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

@boelle
Copy link
Contributor

boelle commented Jan 25, 2020

My config for marlin Configuration.zip

@boelle
Copy link
Contributor

boelle commented Jan 26, 2020

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
Copy link

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
Copy link

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
Copy link
Author

BarsMonster commented Jan 26, 2020

@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
Copy link
Contributor

boelle commented Jan 26, 2020

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
Copy link

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
Copy link

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
Copy link
Member

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
Copy link

kazooless commented Mar 9, 2020

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
Copy link

BondarenkoA commented Mar 10, 2020

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
Copy link
Author

BarsMonster commented Mar 22, 2020

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.

image
image

@BarsMonster
Copy link
Author

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
Copy link
Member

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

@richfelker
Copy link

@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
Copy link
Author

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

@boelle
Copy link
Contributor

boelle commented Jun 23, 2020

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

@jpmath54
Copy link

jpmath54 commented Jul 7, 2020

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
Copy link

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
Copy link

jpmath54 commented Jul 8, 2020

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
Copy link

github-actions bot commented Aug 8, 2020

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
Copy link

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.

@github-actions github-actions bot locked and limited conversation to collaborators Oct 13, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests