Marlin: Problems with Linear Advance

[landodragon141]

So I have this problem when I try to use Linear Advance on my printer. The extruder motor starts stuttering and skipping and sometimes it runs backwards instead of forwards at random (no I'm not talking about retraction :P). I tried turning down the acceleration on the E from the default 10,000 to 3,000. It's a direct drive bowden MK10 esq. My calculated value for K is 160 which shouldn't be that high. I'm also only printing at 40mm/s max. Thanks in advance.
EDIT: It was previously working for me before Sebastianv650 moved the code around.

[Sebastianv650]

Do you know which version was working for you? The last changes i did have not modified the extruder isr, so I have no idea why it should now run backward.
Please upload you configuration file, i will see if i can find some values that may confuse the math in the advance code.

[landodragon141]

There you go. I'll try and capture a video tonight as well.
Configuration.txt

[landodragon141]

I think it was a while back maybe a month. I only just realized that I had been running with it commented out and now it's highly opinionated.

[Kaibob2]

I also tested lin_advance some weeks (maybe months) ago and had it almost working. Then there were other stuff to fix and i commented it for many RCBugFix versions. Then, a version from end of October (i don't know which one exactly) made massive retraction moves as soon as i switched from K=0 to K=1.

Now i'm with RCBugFix as of 8.11.2016 and the last few tests where chastening too. I can higher K to around 200 (55cm Bowden) and the massive movements are gone, but it is far from working reliable. The reason why i didn't open a thread yet, was because i need more testing to be more specific. So, i know, this post is not really helpful. Sorry.

[landodragon141]

No I think it is helpful because it's likely you are having a similar problem as me.

[Sebastianv650]

If it does huge moves with k=1 and smaller ones with k=200,something had to go totally crazy. Maybe a variable is overflowing.. I will have a detailed look at it tomorrow

[Sebastianv650]

One thing I notice in your config is that you are using a completely different range of esteps/mm than I do. I have 801 steps/mm, you have 95.
So my next question is, @Kaibob2 what's your estep value?

I hope we find some similarity between your printers, that would mean we have one specific bug.

Edit:

block->abs_adv_steps_multiplier8 = lround(extruder_advance_k * (de_float / mm_D_float) * block->nominal_speed / (float)block->nominal_rate * axis_steps_per_mm[Z_AXIS] * 256.0);

Maybe I introduced a silly copy & paste error in the PR? Why the hell I wrote Z_AXIS in the calculation? I have to rethink into this..

[Kaibob2]

This were different versions! The "older" one behaved like:
Printing a cube with K=0
Send M905 K1
On the next acceleration the extruder massively overextruded then retracted maybe 50mm or more with high speed (probably 150mm/s which is the limit I've set). I always killed immediately because this behaviour would have damage the hotend when primed a this speed

The recent version is almost working but the retract amount is more then the following prime so each beginning of a loop is massively underextruded. It's hard to describe. I will take some pictures next time.

With the version I tested many month ago everything was fine, but i had to use a K of around 250 which made the extruder rise the white flag. I cancelled experimenting with it because i didn't expected to get it working due to the long bowden.

My estep value is 99 steps/mm, so quite close to landodragon141 and i think quite common for MK8 style extruders.

[Kaibob2]

Why the hell I wrote Z_AXIS in the calculation?

This explains a lot. Nevermind, nobodys perfect. I think this whole lin_advance thing is a great development and i would really appreciate if it would work reliable one day.
Keep irt going. Good luck 👍

[Sebastianv650]

Please go into planner.cpp and change the Z_AXIS in the line I pasted above (around line 1267) to E_AXIS and report how your printer behaves now. In doubt, ignore the formulas for K and try to find K by try and error.
Maybe it's that easy..

[Kaibob2]

I did a REALLY quick test and changed Z to E in planner.cpp.
It's not realy that much different as far as i can remember. The below pictures are with K=50,100,150,200,300 and 400 from bottom to top.
This is all i can do for now. It's Schlafenszeit :)

Btw.: Before you ask. The printer itself is perfeclty calibrated and produces perfect prints with lin_advance disabled

[Sebastianv650]

It should be a big difference for @landodragon141 at least, because he has over 4000 steps/mm for Z but under 100/mm for E. K=1* 4000 will lead to a rocking like crazy extruder, while K=say 75* 100 may be a real value.

But as you said, time for bed. Gute Nacht zusammen ;)

[landodragon141]

Well considering my value for K was 160.... 160*~4000 0.o This explains so much! Thanks for looking into this I'm almost off work so I'll head home and give it a whirl.

Edit: Just cause numbers are fun. 4076x160=652,160; 95x160=15,200.

[thinkyhead]

@Sebastianv650 Could this be also related to the concern that K was possibly 10x its former values for some users? (As I recall, 47 versus 4.7)

[Sebastianv650]

@thinkyhead I had not much time to think about it. But if the issues here can be solved with this change, it's definitiv possible. I will think about it today and see what the next feedback is.

[Kaibob2]

I have 1601 Z-steps/mm. I will calibrate K with a bigger testcube this evening. The 4 cubes from above were printed with:
70mm/s print speed for everything (I suppose this is too fast for K=250)
No retracts, coasting, wiping or other extrusion related settings switched on
PLA @ 210°C

@Sebastianv650 Would you recommend leaving a small retract (<1mm) enabled? I normally have 3mm retract when not using lin_advance

[Sebastianv650]

You can use your normal retract settings without an impact to LIN_ADVANCE. Retract and prime moves are handled without the influence of the advance calculation.

[landodragon141]

When I saw your test print above I was going to ask if you had retraction enabled. One of the advantages to Lin_Advance is that it reduces the need for retraction and theoretically it might be possible to for retraction to become obsolete in the future with more processing power and a more refined algorithm. Also I'm sorry I didn't have a chance to test out the fix last night so I'll have to get to it later today.

[Kaibob2]

I had this in mind from the lin_advance documentation

Some slicers have options to control the nozzle pressure in some ways. Common names are: Pressure advance, Coast at end, extra restart length after retract. Disable them all! The firmware will do a much better job than the best slicer can do, and they would influence themselves in a bad way. I also strongly recommend to disable further features like wipe while retract. You can try to enable it again after you have calibrated your K factor (see next step), but I guess you don’t need it anymore.
After you have a calibrated, working pressure advance feature, you may want to recheck your retraction distance. You will find out that you can cut it down to nearly 0. This is caused by the pressure control, it reduces the nozzle pressure at the and of a line to about zero. For example, I was using 1 mm retract length for PLA, with enabled LIN_ADVANCE I’m now using 0.5 mm.

I will test later with everything disabled only retract as usual but reduce to "only retract when crossing open spaces"
Until now i retracted at every end of a line, because during travel moves the nozzle lost filament due to oozing and pressure left from the last extrusion. This filament got lost by glueing to the infill or whatever. When the next line started there was underextrusion. I hope this new combination will work...

[landodragon141]

May the force... flow... pressure be with you! 😄

[Sebastianv650]

I created PR #5230, it should bring back the K values needed into reasonable ranges. Up to now, I guess this should solve the problems rised since the last big patch.

[Sebastianv650]

One of the advantages to Lin_Advance is that it reduces the need for retraction and theoretically it might be possible to for retraction to become obsolete in the future with more processing power and a more refined algorithm.

That's no question of processing power, it would be possible to do something like that. In Sailfish, they tried it with JKN, but as far as I know it's always disabled.
In theory, you only have to bring the nozzle pressure to 0 at the end of a move where we usualy stop at some jerk speed. So the needed retract length equals the absolute amount of advance steps at this point (k* jerk_stop_speed). But I see no advantage between doing a realy small fixed retract compared to a calculated small retract..

[Kaibob2]

Okay, like promised here is what i got.
600mm Bowden, MK8 Extruder

Two calibration cubes 30x30mm with a X distance of 110mm.

First attempt:
PLA@210°, Print speed 70mm/s, Outer perimeter 28mm/s, 2mm retraction only when crossing open space, all wipe and coast and whatever disabled
Started with K=0. Went up to K=300 in steps of 50. The best value was around 90, what is crazy, because the formula says around 250 for me. From K=130 upwards the inner perimeter after travelling to the other cube becomes underextruded. At K=300 the first 50mm (30mm front and 20mm side) are underextruded.

Quite nice, only at the top right the infill is a little weak.

Second attempt:
PLA@210°, Print speed 70mm/s, Outer perimeter 28mm/s, NO retraction all wipe and coast and whatever disabled. Started with K=90 but, long story short, this doesn't work at all! When travelling to the other cube around 5mm filament oozes out of the nozzle. This stops at a K>270 but this high value makes almost the whole inner layer underextrude.

There is also a very nice effect on the holes which i mentioned some time ago here #4766
This over or underextrusion after leaving the hole is minimized.

To summarise:

• Lin_advance works properly with the fix (Z->E-steps)!
• High K values which prevent oozing lead to massive underextrusion when next loop starts.

Maybe @Sebastianv650 can say something about this and give a hint.

[landodragon141]

That's very interesting. I'll try and replicate that tonight. Do you want to send me that model? That way we can compare apples to apples. I'm right at the cusp of replacing my crappy M5 threaded rod with an integrated M8 Leadscrew stepper. (the integrated motor/screw is sitting on my workbench waiting to be installed).

[Kaibob2]

Using the same model is a good idea:
Cube 30x30x10 holes.zip

I also started with TR8x1.5, but the pitch sucked because you cannot use every layer height you want. At least not 0.05, 0.1 and 0.2, which i use mostly.
This is why i switched to TR10x2.

[Kaibob2]

I feel like i have to give some more info about what my intention is to get lin_advance working.
Once my printer was well calibrated with cubes i turned to use more complex objects to do the fine sdjustments. This gecko from thingiverse turned out to be useful.
Gecko.zip
I usually scale it to 120% and set an Z-Offset of -0,1mm (dropping it into the printbed)

Meanwhile i get really good quality prints, but the price is a huuuge amount of retracts because S3D has to be set to retract at every end of a loop. This leads to no oozing from the nozzle and a clean print when traveling.

To get rid of the retracts i have to enable the "only retract when crossing open spaces". This makes S3D to only retract after a loop when there is a travel move to be done over an open area.

So far so good, the problem then is, that if the head travels over a "not open" area the nozzle oozes and loses filament when dragging over infill or outlines which is missing when starting the next loop (underextrusion!).

The option to "Avoid crossing outline for travel movements" is nice, but makes it even worse. With this option DISABLED you get this

Without retracting after each loop this leads to a hedgehog gecko beacuse the oozed out filament sticks to the outline where the nozzle touches its destination.

With "Avoid crossing outline for travel movements" ENABLED you get this

This makes the hedgehog spikes almost no problem anymore , but now there is another one

As you can see, S3D plans the "avoid crossing outline" path over the outer perimeter. That means if i don't retract after the previous loop the oozing will create dots of filament along the travel path over the outer perimeter. If the real outer perimeter is printed after that you don't get a clean line as there is too much material everytime the nozzle hits a dot.

Here comes lin_advance into account. If i have no overpressure in the nozzle after ending a loop there will be no oozing and i can enable the "Only retract when crossing open spaces" and "avoid crossing outline" without getting the dots when travelling.
Like i explained above the problem now is, that if i set K=250 the oozing stops but the next line starts with massive underextrusion.

[thinkyhead]

With the patch now merged, is it working better @Kaibob2 ?

[Kaibob2]

Lin_advance works properly with the fix (Z->E-steps)!

@thinkyhead The crazy extruder moves are gone, but the issue i'm facing is the described above.

[Sebastianv650]

A lot of posts since my last free time slot. If I forget to answer one question in this post, feel free to raise the hand.

@Kaibob2 while LIN_ADVANCE should help you with the retraction problems, it will not completely eleminate it. Even if the pressure control math works perfectly and we add 1mm retract of the end of the move for safety, there is still molten filament inside the hot end. And nothing will hold it back, over time it will ooze out of the nozzle. Like if you take a glas of honey and turn it up side down. Gravity is a ugly thing sometimes ;)

The best value was around 90, what is crazy, because the formula says around 250 for me.

This proves my formula isn't working. I can live with that, then I have to remove it from the config file again. In fact I know it can only be a rough estimation, as it's not taking into account that the needed force to extrude the filament at a specific flow rate differs sometimes. For example if you have another nozzle diameter than I have, or you are printing at a different temperature.

But at first, I think you should do a step backward: You are trying to calibrate K by watching the effect to retraction and oozing. There is a relationship, but I bet it's not a real way to find a perfect K value.
I strongly recommend to follow the calibration procedure from the documentation. Print a flat 25x25mm cube at 70mm/s (also for top solid infill an every other line type except for 1st layer). Use a filament color that gives a good contrast and be sure not to bend it when removing it from the print bed. Then, using a scanner or a strong magnifier and a metal ruler, inspect the edges (rounded inwards or bleeding), the perimeters (gaps between them?) and the solid top infill (rough at perimeter line junctions, gaps when approaching the perimeter turn points?).

Here are two example pictures (with a very bad color in terms of contrast).

In this picture, you can see K is (a little bit) too low. Edges are bleeding and the infill could be a little bit cleaner at the turn points.

In this picture, K is definity too high. Edges are rounded inwards, there are gaps between the perimeters around the edges in the acceleration/deceleration phase and there are even big gaps at the infill turn points.

When you got a K value that satisfies you, the next step would be to do retraction tests again. First I would try to maximise the retract speed as much as possible (prime speed should be lower if possible). If you found the maximum your extruder can safely handle, do the tests you already described above to find a minimum retraction length.
It's only my opinion, but I would stay within reasonable distances between the calibration cubes for the retraction length tests. 11cm are rare in real models, and as described before you will never have 0 oozing if your travel length is high enough. Therefore, I would go with a distance of about 7cm.

[landodragon141]

@Kaibob2 I just switched from a T5 x 0.8 to a T8 x 8 (2 pitch x 4 starts). Wow I should've done that awhile ago.
@Sebastianv650 The fix worked, but I only had time to do a single print. I did the Belt gear for the Voron Extruder. It turned out really nicely. I really wanted to get that Z-axis fixed before I did any further testing because I knew it was a source of issues.
I'm not convinced that I have the perfect K value but I'll run through the values tonight and take some good pictures. Occasionally my extruder (i think it was my extruder) was making a click at the end of a line. It didn't seem to effect anything that I could see.

I'll have to put a brown bag over my printer it's pretty ugly lol!

[VanessaE]

One thing I'm seeing across all of my prints is slight under-extrusion at the starts of some lines, especially after retract, much like what @Kaibob2 is seeing, though in the object I'm using (CtrlV's v3 test object), the nozzle isn't crossing over large areas of infill as in his case, or even taking all that much time to complete the travel (300 mm/sec, and this object is only about 100 mm wide).

Anyway, I made a clean clone, applied #5230 onto RCBugFix (this was before @thinkyhead merged it), added my settings, and ran a bunch of tests.

With the formula @Sebastianv650 gave there, based on E=760, Z=4000, and an initial K value of 75, I get a correction of K=395. The result of that setting is okay for most of the part, but here's what the trouble area looks like:

(no, it's not printing too hot. :stuck_out_tongue: That's just the lighting, and those are ~1mm verticals.)

[Sebastianv650]

Interesting miniature print, but not realy something where i can make a statement about advance or k value. At least I would need a print without LIN_ADVANCE to compare.
Do you have a detail picture of a under extruded line start?

[Kaibob2]

@landodragon141 TR8x8 has 2mm pitch too?! Cool, didn't know that.
@Sebastianv650 I will start from scratch and print the cubes you suggested. Maybe next weekend i find some time to do so.
Regarding retraction speed i just lowered it from 150mm/s to around 40mm/s as the high speed didn't have no effect at all. My theory was, that the hard part of the filament get's separated from the soft part in the nozzle and because of expansion the nozzle oozes. Anyway, i had retraction speed 150mm/s and retraction distance 5mm. Now i have retraction speed 40mm/s and retraction distance 2mm and it's not oozing even if i travel over the complete printbed diagonally.
@VanessaE What are your settings for retract etc.? How long are your bowdens? I've read it before in another thread but forgot :)

[Sebastianv650]

@Kaibob2 wow, that's a great example related to "everything is relative"! When I wrote max retract speed, I was thinking about going from a usual default value like 25mm/s to 40mm/s. With my 801steps/mm, 40mm/s is also the maximum speed at which Marlin can drive my estepper. I never thought about 150mm/s :-D

But yes, I also made the experience that a too fast retract can make the result worse again.

[VanessaE]

The bowden is a bit over 50 cm length, retract is 5.5 mm at 25 mm/sec (too much faster and the motor will stall).

Sorry, I didn't think to take a photo of an under-extruded line-start, but it's not severe - just the first 10-15mm or so of total length (i.e. solid infill winding back and forth for a few turns), then it catches up.

[thinkyhead]

Should LIN_ADVANCE and retract be used together?
It seems to me that if using "advance" then retraction is redundant.

[VanessaE]

@Sebastianv650 here's an example of the under-extrusion, snapped mid-print. In this case, K=260 just to make sure it was clearly visible. The movement through the part is roughly clockwise around the two holes at the right (well, there's three, but one is out of frame), with the underextruded part next to them being about half-way through that section, then a retract is performed, and the part left of the "V3" is done.

@thinkyhead I would have to venture a guess that no matter how good the advance algorithm gets, you'll still be fighting the tendency of the filament to "bubble" its way out of the nozzle (I guess heat expansion, if there's nowhere else for the melted filament to expand into).

[Sebastianv650]

@VanessaE that's a clear sign of a too high k, especialy when it gets better with a lower k value.

I would have to venture a guess that no matter how good the advance algorithm gets, you'll still be fighting the tendency of the filament to "bubble" its way out of the nozzle (I guess heat expansion, if there's nowhere else for the melted filament to expand into).

True. But I wouldn't call heat expansion for it, especialy not for oozing during travel with retract. Usualy, during a retract the solid part of the filament is a little bit lifted from the fluid in the hot end. So it would be much easier for a heat expansion to move upwards instead of squeezing through the tiny nozzle. Also there shouln't be much expansion during travel move: The molten filament is already molten, so no big further expansion.
It should be simple gravity as described above with the glas of honey, combined with not 100% released pressure from extrusion before in the molten filament in the area of the nozzle tip (pressure may not be released uniform inside the melt).

[Sebastianv650]

@thinkyhead see this one regarding retract and LIN_ADVANCE.

[Kaibob2]

@Sebastianv650

"everything is relative"!

This made me struggle quite a long time when i built the printer. Because of beeing absolutely new to this i took advises from several posts from different sources. Everybody statet "as fast as possible" For me this was 160 mm/s so i took 150 and wondered why retract didn't work reliable.

I wouldn't call heat expansion for it

This is exactly what i'm experiencing now. When i retract, travel and prime the print comes out almost perfect. Everytime there wasn't a retract (prime) before starting a new line it looks like in @VanessaE s' picture because the drooping causes the nozzle to become "empty". It would just be great to limit retraction moves, because in fact i only need them to have the new line start with the same amount of molten filament and pressure like the last one. (I must admit that this is much easier in theory than while actually printing)

[brainscan]

Is there any way to have the extruder keep retracting very slowly while moving to the next line? It's just a thought but I wonder if it would help stop ooze between points.

[thinkyhead]

to have the extruder keep retracting very slowly

I believe some slicers may utilize this technique. May be worth checking the latest Cura and Slic3r.

[VanessaE]

Slic3r does not, to my knowledge, have such a feature.

[Sebastianv650]

A slow, continous retraction will not prevent oozing. That would only work if the filament would be air-tight to the hot end entry.
What might be a slight improvement: Retract while the travel move is already starting so your nozzle isn't standing still until the retract is done. But that's not possible as long as each move is forced to be synchrone along each axis. And it will lead to further special cases on the next line start (prime). Then Marlin would have to check if the travel move was long enough so the retract move is also done. If not, Marlin is only alowed to prime the already retracted length and every further retraction has to be canceled. I don't thing we will be happy with that..

[landodragon141]

I ran some tests last night on some cubes. However I didn't calibrate my Z axis since I changed it (facepalm). I'll calibrate that and print some more cubes tonight. Other than user error this appears to be working much better.

[Kaibob2]

What might be a slight improvement: Retract while the travel move is already starting so your nozzle isn't standing still until the retract is done.

This is what "Perform retraction during wipe movement" in Simplify3D does.

[Sebastianv650]

No, not realy. Wipe usualy perfoms a backward move along the print move done before. And the reatraction acceleration is usualy much higher than a print acceleration that is also used for a wipe move.
My idea was to have a full-speed retract while starting the normal move to the next printed line. Basicaly, that means we would start two independent actions executed in paralel. But thats "science fiction" up to now.

[Kaibob2]

@Sebastianv650 You are absolutely right. Dammit. I misread the hover text the whole time. It says

So "Wipe nozzle" has to be enabled too to make this function work. Thanks for kicking me in this direction.

[VanessaE]

I've continued my testing, and just don't understand what's going on. Even at a print temperature of 200, retract of 6.0 mm, and K=650, I can't get rid of the ooze in that trouble spot (the vertical wall with hole), though increasing K and decreasing temperature did help a little.

I gave it a try with K=650, 200 degrees, but (FW) retract and (Slic3r's) Z-lift disabled. There was enough stringing to knit a sweater. That would seem to suggest to me that K is still far too low, but I think the frequent rattling is causing the extruder to lose too many steps (or rather, is perhaps the result of it).

[VanessaE]

Once that no-retract print finished, I took a good close look at it. Surfaces, shapes, corners, that sort of thing are far HIGHER quality with retract disabled, but of course stringing everywhere. That would seem to reinforce the notion that LIN_ADVANCE is causing the extruder to lose steps.

[Kaibob2]

@VanessaE I was curious, so i downloaded the model you're using. This is how it comes out with lin_advance disabled and my absolute basic settings for PLA without any model specific modification. The only thing i had to do is to scale the model to 70% because my PEI spray coated test glas printbed (just made it today, works great) wasn't big enough :)
And yes, the first layer could also be a bit higher.
Printed with PLA@210°, 100% infill, 70mm/s, 28mm/s outer perimeter,2mm retract@40mm/s

[Kaibob2]

@VanessaE

I gave it a try with K=650

This seems like an extremely high value?! If i get it right:
My Esteps are 99 and when i set K=300 the extruder is quite busy. BUT i can go with a E speed of 150mm/s without any problem (16000/Esteps = 161mm/s - safety margin = 150mm/s)
If your extruder stalls at 25mm/s (why is this? It's geared i guess) then K=650 i would suspect is impossible to handle for it.
In my case the extruder shaft turns approx. 90° with K=300 back and forth with extremely high speed but has no problem keeping up.

@Sebastianv650 Do i get this right? I don't want to be the wisenheimer :)

Enough 3D printing for today, time for an Altbier ;)

[landodragon141]

@VanessaE How long is your bowden tube? Is there a lot of play in your feeder setup?

@Sebastianv650 Is it possible we actually are dropping steps? I'm wondering if that is the click I hear that occurs somewhere between the Advance and the Retraction.

[VanessaE]

@landodragon141 about 65 cm from the hobbed gear to the nozzle tip, thereabouts, of which a little over 50 cm is the tube. There's a little play, and a very small amount of backlash in the gears, but no moreso than any such setup should ordinarily have.

@Kaibob2 Yes, it's geared; it'll stall somewhere above 30 mm/sec, so I limit it to 25. I started at K=75 and stepped it up over the course of about 15 prints. I ran another test with LIN_ADVANCE disabled. My result was about the same as yours (maybe slightly better).

Here's how they all compare (all with exactly the same settings, except as noted):

Linear advance enabled only (retraction/z-hop disabled)... Clearly the shapes of the objects are the most accurate here. Lots of ooze everywhere, especially on the other side of the object (where the spire and pyramid are). You can see some of that ooze on one of the bridge's uprights and on the left of the wall-hole part.

Retraction/z-hop enabled only (linear advance disabled)... Retractions are done cleanly and no evidence of skipped steps anywhere, but without linear advance, the shapes and surface quality of the objects suffer. The ripples on the bridge's uprights is not Z wobble, it's an artifact from one of the objects that's nearby but out-of-frame.

Both enabled (i.e. "normal" settings)... It's a mess. :frowning_face:

[Sebastianv650]

On geared extruders, a clicking/knocking sound can also happen when there is a little bit of play inside the gearing. If the extruder does a sharp direction change, the stepper's gear knocks against the next gear. But it's also possible that the stepper is losing steps.

Especially with the print results with different settings from @VanessaE enabled/disabled I would say that's a sign of losing steps.

But I have one problem with @VanessaE pictures: LIN_ADVANCE seems to work. Retract with z hop works. But combination doesn't. In the end, this can't be because if the code works as it should LIN_ADVANCE isn't active during retracts with z hop.
Therefore my first idea would be there might be another situation where LIN_ADVANCE should be ignored that's not yet filtered out inside the already existing planner checks. As I can't reproduce that, it might be even specific to one slicer or specific settings of one slicer - so I need your help to find the root cause. So let's continue..

First I have to state again that my engeneering soul is winding when using such "calibration" models. If you want to tune one specific setting like K, you want to be absolutely sure that you don't have other parameters playing into your final result. All you want to see is a difference caused by a changed k or enabled/disabled LIN_ADVANCE.
That's not the case in this "let's throw every possible shape into one model" stl. That's a nice capability test once you are sure your printer is properly calibrated, and it may point out some options where you can still improve, but not more. Only my 2 cents..

Therefore I have to ask some questions so we can shoot out some possibilities:

• Has everyone here found the minimum k value that leads to a as nice as possible flat cube and is there a clicking sound or other problems printing it with that k value?
  If that works, don't chance k anymore. Every other k will decrease print quality on your printer, as long as there are no lost steps.
• Does a complex object like the all-in-one test piece above is now printing worse with the found k value in step 1?
• If yes, we have to find the gcode-combination where the error rises. In the last picture from @VanessaE we can see something goes realy crazy during the move from (or to) the wall with the hole to the second pillar from the left. That's the biggest problem I can see in this picture, so we should start with this one.

So I would ask you to do some homework: Cut the model with some planes so that it only prints the area with the wall and the first 3 pillars. If you need help with that, I can try to do this but I'm also not used to do such things ;)
Then, cut the small model at top and bottom so that it only prints up to the point where the bridges between the pillars are printed, starting with the first layer a little bit under the point where the error happens. Slic3r can do this two plane cuts. If necessary, print on a raft so that the pillars print OK.
Hopefully, the print error with LIN_ADVANCE combined with your retract settings is still there.
Then, try to find the specific layer where the problem starts. Find the gcode before this travel move starts and the gcode where it continues to printing after it, including +-5 lines of gcode.
If you can send me that lines, it should be possible for me to reproduce it and find a fix in a short time!

Sorry for this amount of work, but up to now I have no better idea how I can find the mistake..

[Sebastianv650]

You can also try to print this test with k=0. If it's not a problem of the rule set but with the esteps er isr,the problem should be also there then.

[VanessaE]

First I have to state again that my engeneering soul is winding when using such "calibration" models. If you want to tune one specific setting like K, you want to be absolutely sure that you don't have other parameters playing into your final result

...which is why I watch the model as it gets started. :smiley:

The lowest 2mm of the model is just a solid shape with what amounts to several vertical holes of various sizes. Pretty simple compared to a "real" model like the gecko, I'm sure. That pic I posted before showing the beginning-of-line underextrusion is an example of that, and it's easy to watch that section of the model to see what effect various K values have.

So I would ask you to do some homework: Cut the model with some planes so that it only prints the area with the wall and the first 3 pillars.

Easily done, but I believe that would invalidate the test. As the printer progresses around the model, it moves from heavier items (pyramid, cylinder, small dome) to thinner stuff (the six little thin walls, bridge) and back to heavy again (wall with hole, big dome), which I'm certain is key to making the problem show up.

That said, gcode.ws does make it easy to find the section of g-code you want. At the bottom of this post is the part of the layer you wanted, from just before the bridge's uprights, to part way through the wall with the hole.

Meanwhile, I did that test you wanted with linear advance enabled, K=0. The extruder is _far_ noisier than it was with the advance-disabled test (i.e. commented out), and there's ooze where there ought not be, so it's clearly losing steps around the retracts.

G1 X69.482 Y70.995 F18000.000
G11 ; unretract
G92 E0
G1 F390.293
G1 X69.345 Y71.317 E0.01270
G1 X69.023 Y71.180 E0.02541
G1 X69.160 Y70.858 E0.03811
G1 X69.427 Y70.971 E0.04864
G1 X69.267 Y71.271 F18000.000
G10 ; retract
G92 E0
G1 X62.864 Y86.436 F18000.000
G11 ; unretract
G92 E0
G1 F390.293
G1 X62.918 Y86.459 E0.00212
G1 X62.781 Y86.782 E0.01482
G1 X62.459 Y86.645 E0.02753
G1 X62.596 Y86.323 E0.04023
G1 X62.809 Y86.413 E0.04864
G1 X62.888 Y86.490 F18000.000
G10 ; retract
G92 E0
G1 X59.371 Y94.513 F18000.000
G11 ; unretract
G92 E0
G1 F390.293
G1 X59.480 Y94.560 E0.00430
G1 X59.343 Y94.882 E0.01700
G1 X59.021 Y94.745 E0.02970
G1 X59.157 Y94.423 E0.04241
G1 X59.315 Y94.490 E0.04864
G1 X59.422 Y94.620 F18000.000
G10 ; retract
G92 E0
G1 X57.440 Y98.909 F18000.000
G11 ; unretract
G92 E0
G1 F390.293
G1 X57.604 Y98.978 E0.00647
G1 X57.467 Y99.300 E0.01917
G1 X57.145 Y99.164 E0.03188
G1 X57.282 Y98.841 E0.04458
G1 X57.385 Y98.885 E0.04863
G1 X57.524 Y99.065 F18000.000
G10 ; retract
G92 E0
G1 X56.291 Y101.462 F18000.000
G11 ; unretract
G92 E0
G1 F390.293
G1 X56.510 Y101.556 E0.00865
G1 X56.373 Y101.878 E0.02135
G1 X56.051 Y101.741 E0.03406
G1 X56.188 Y101.419 E0.04676
G1 X56.235 Y101.439 E0.04864
G1 X56.414 Y101.667 F18000.000
G10 ; retract
G92 E0
G1 X59.279 Y104.563 F18000.000
G11 ; unretract
G92 E0
G1 F390.293
G1 X59.958 Y104.281 E0.02671
G1 X61.136 Y107.123 E0.13836
G1 X60.456 Y107.405 E0.16507
G1 X59.301 Y104.618 E0.27455
G1 X58.747 Y104.342 F18000.000
G1 F390.293
G1 X60.179 Y103.749 E0.33081
G1 X61.668 Y107.344 E0.47201
G1 X60.235 Y107.937 E0.52827
G1 X58.770 Y104.398 E0.66729
G1 X59.147 Y104.344 F18000.000
G1 X59.696 Y104.610 F18000.000
G1 F520.390
G1 X60.718 Y107.076 E0.73533
G10 ; retract
G92 E0
G1 X62.299 Y111.854 F18000.000
G11 ; unretract
G92 E0
G1 F390.293
G1 X62.979 Y111.572 E0.02671
G1 X64.067 Y114.200 E0.12992
G1 X63.387 Y114.481 E0.15663
G1 X62.322 Y111.909 E0.25767
G1 X61.767 Y111.634 F18000.000
G1 F390.293
G1 X63.199 Y111.041 E0.31393
G1 X64.599 Y114.420 E0.44670
G1 X63.167 Y115.013 E0.50295
G1 X61.790 Y111.689 E0.63354
G1 X62.167 Y111.633 F18000.000
G1 X62.716 Y111.901 F18000.000

[Kaibob2]

Already had it done, maybe it becomes useful later.
CTRLV-part.zip

[Sebastianv650]

OK, I would say your extruder doesn't like the estepper ISR. You mentioned before your extruder stalls at 30mm/s and it is limited to 25mm/s. Here you wrote that you are using 760 steps/mm which is similar to my one. And you are using MINIMUM_STEPPER_PULSE = 8µs.

After some thinking, I'm afraid there is not much I can do in this case. I have a similar problem if I try to run the extruder stepper at higher speeds, if I try to run it too fast it's even "screaming" without rotation at all. I did some tests about that several weeks ago.

This is only happening when the estepper ISR is used. It took me some time, but I'm quite sure I know the reason now. For a stable stepper operation it is necessary that the stepper pulses come in equal distances. For people like us with high esteps/mm, Marlin has to fire alot of pulses in a short time. When we go too high, there is a good chance that something is blocking the CPU at a point where the estepper ISR has to fire. For example it could be the normal stepper ISR. In this case, our esteps are delayed a bit and if the difference between delayed and normal steps is too high, it's losing steps.

It's comparable to the serial communication losing chars if the baud rate is too high.

For me, that's not a problem in real printing speeds because I don't need extra delay for the steppers. As you add extra 8µs for each fired stepper, it's verly likely that this problem occurs at much a lower extruder speed for you.

Why this doesn't happen without LIN_ADVANCE? Because then all steppers are fire inside the stepper ISR, which also has a very high priority. So even if we are overloading the CPU with a much too high steprate, that's no problem: In worst case, each ISR will be fired just after the last ISR finished. And due to the fixed runtime of the stepper ISR, the stepper pulses will be evenly distributed over time. That means, you can also call Marlin to do 300mm/s at the extruder and it might rotate without problems. In reality, it might only do 40mm/s because there is no more time for further stepper ISRs per second, but at least the stepper will run smooth.

Also note that the estepper ISR isn't checking for the maximum extruder speed. If due to a high K value your extruder has to do a hughe amount of extra steps during acceleration, the resulting speed might exceed the 25mm/s limit.

I did a lot of experiments to implement a limiting function, without success up to now. The main problem here is that we have to decide what to do: Limit the extruder to a maximum step rate? In this case, the advance steps will not be executed at the right place if the limiting step rate is exceeded. With a lot of short segments with acceleration/deceleration that could lead to very strange extrusion problems. Brake down the movement speeds? This means blocking the main stepper ISR until all esteps has been executed. This might introduce other problems with the XYZ steppers if the limit is exceeded.

Another problem is that all the checks are not allowed to take a lot of time like they do inside the planner because they has to be handled inside the ISR..

The only real solution I can offer you, try to reduce the default acceleration for print moves. What's your actual value? Maybe reducing it keeps the amount of advance steps low because the delta velocity between two ISR calls will go down.

A great and maybe working solution would be to find a clever way to calculate the max. extruder steprate due to advance inside the planner. If it exceeds the allowed extruder step rate, limit the acceleration until the step rate is within the limits. I have to think about that, but even if possible it will need some time..

Edit: This will only solve missed steps during acceleration and deceleration, not for retract/prime movement where a high e speed is called and the pulses may fall into disorder as described above!

[VanessaE]

And you are using MINIMUM_STEPPER_PULSE = 8µs

I'm using 4µS. At 8, the printer basically just throws a fit due to the communication errors that setting causes.

If due to a high K value your extruder has to do a hughe amount of extra steps during acceleration, the resulting speed might exceed the 25mm/s limit.

That wouldn't explain the clearly lost steps with K=0.

I did a lot of experiments to implement a limiting function,[...]

My first thought here was to just proportionally slow everything else down if the extruder is hitting its max configured speed.

The only real solution I can offer you, try to reduce the default acceleration for print moves. What's your actual value?

E, XY, and Z are all set to 3000 mm/s².
Correction, E and XY are set to 3000 mm/s² max, Z is at 100. Default is 3000 also.

[Sebastianv650]

That wouldn't explain the clearly lost steps with K=0.

True. That's likely due to the possible disorder of the estep pulses I mentioned. But it's realy hard to say without having access to a printer with that problem..

My first thought here was to just proportionally slow everything else down if the extruder is hitting its max configured speed.

At ISR level that's not that easy, at least I have no good idea. That's a binary decision, if the calculated advance steps + normal esteps need a higher step rate to complete until the next stepper ISR event, there is nothing to scale down. We can only execute the esteps as fast as possible, blocking further stepper ISRs until it's done.

Correction, E and XY are set to 3000 mm/s² max, Z is at 100. Default is 3000 also.

You might try a print at 1000mm/s² or even 500mm/s² (that would be realy slow!) just to see if it helps with the problem. But if it's due to retract and prime, I'm afraid it will not. Then, only lowering retract acceleration or retract speed may help.

[VanessaE]

You might remember an early experiment regarding the extruder rattling - lower acceleration did make it rattle less (I think I was at 500 at the time).

[landodragon141]

Am I right in remembering that Lin_Adv should be disabled for short moves? If so we might need to look into that because it is definitely not being disabled.

[Sebastianv650]

No, short moves are Ok. I guess you are referring to the problem with very small print moves (<6 steps) combined with a retract move afterwards. But this is fixed by the check if the e axis is the master axis. In this case, LIN_ADVANCE is disabled.

[Sebastianv650]

Wait a moment, what's about a short move combined with a retract with z hop. Maybe it's not related to a problem here in this thread, but as the z axis usually has a lot of steps/mm is likely it becomes the master axis in this case. .
No problem, it's checking for negative feed rates so that case is handled correctly.

[landodragon141]

What are we recommending for acceleration and jerk values for LIN_ADVANCE? The default in marlin is 10000 for E. I've had better results as I've pushed it down to 1000 and I think I'm going to try to go down to 500 on E to see if that helps. I suppose I should also check if I need to adjust the min step pulse.

[Sebastianv650]

During normal printing, the E-acceleration is not the limiting factor due to the small speeds the e axis has to do compared to X and Y. Therefore I would leave it how it is, but play with default print acceleration. I'm using 1100mm/s², I can't see a reason to go higher as it's not a big impact on speed. For jerk, I'm using 8mm/s. The only reason to have a jerk value >0 is to keep the speed at crusing speed during circles where we have speed direction changes. Below 8, I found the printer is slowing down to stay below the jerk limit in arcs so this is a good minimum value for me.

[landodragon141]

Well I'm not going to be able to test anything for a couple of days. My 4 year old let the magic smoke out of my controller....

[NimrodQuimbus]

I think what might be happening is that a blob is being created while the pressure is building up in the hot end at the start of a line, before movement takes place, which Bowden setups are the most prone to because retractions are much longer.

Imagine an extremely slow extruder that takes say 5 seconds to unretract the filament, that would cause a blob unless movement started slowly taking place as the extruder was building pressure in the hotend.

so, LIN_ADVANCE really has little effect on this, as it is a completely different issue.

[Sebastianv650]

That's only partly true. With a working LIN_ADVANCE the printer will build up nearly no pressure during unretract. The pressure buildup is done during the folowing acceleration phase and it is relaxed during the deceleration phase. Retracts only have to handle a very minor remaining pressure, therefore the retraction length can be reduced, therefore the unretract takes less time and the blob is smaller.

[NimrodQuimbus]

OK, I slowed down DEFAULT_MAX_FEEDRATE for the extruder, big improvement, start/stop blob reduced by almost 50%

[VanessaE]

(I'm now at commit 312caef472901b63624b9066bc578956e879661f)

Something just occurred to me... If the E ISR runs at 10 kHz, and I have E at 788 steps/mm, wouldn't that work out to 12.69 mm/sec theoretical max for the extruder? In which case, my current setting of 25 mm/sec must be invoking that double-stepping I've seen mentioned a few times...

Could THAT be why LIN_ADVANCE just doesn't work for me (e.g. skipped steps at retract)?

EDIT: no, that isn't the issue. Backed the max E speed to 12 mm/sec, no improvement. In fact, the extruder rattling is pretty bad now when LIN_ADVANCE is on, even with an E accel of 500

[Sebastianv650]

Marlin is designed to do up to 4 steps per ISR loop, so it should be able to do 4x the speed you calculated.

Beside that, the e acceleration will have no impact on the rattling of the extruder during print moves. The espeeds and therefore the accelerations are so slow, that only the default print acceleration will be used. That's why I recommend to try lower xy jerk and printing acceleration settings with LIN_ADVANCE. High ones are no longer needed for sharp corners.

[VanessaE]

I'd have figured an XY jerk of 10 and E jerk of 5 was already fairly low.

[Sebastianv650]

yes, that should be ok.

[VanessaE]

Apparently, it isn't. :smile:

[VanessaE]

@Sebastianv650 what became of that last set of tests you mentioned in #5481? I'm really curious why the extruder rattles so much for me when this feature is turned on (as of 922c67f anyway), or rather, what's the right way to solve it.

[Sebastianv650]

Up to now I had no single issue with RCBugFix.
I'm trying to find out if some problems where the printer is freezing are related to LIN_ADVANCE at the moment. But this shouldn't be related to extruder rattling. As long as there is no new information from someone else, I expect it to be differences in gearing play. If you have even tiny play, it will nock when the extruder changes direction. That can't be changed. The reason why it becomes much more noticeable with LIN_ADVANCE is because it is doing corrections much more often than without it.
Sorry, I see no way to find out more with the given informations.

[thinkyhead]

Start a new issue if needed.