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.

[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.

[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.