Marlin: Bug in Linear Advance 1.5, causes extruder motor to stop for several seconds

[Itox001]

Description

Found what I believe is a bug in Linear Advance 1.5. Got K=0.65 for my bowden setup and my benchies are beautiful except for a missed perimeter. It´s 100% repeatable, I will attach gcode (slic3r PE 1.41) and config files, currently using the 2.x bugfix from 27/08/2018.

Notice the horizontal line about 4 mm up from the bottom. Apart from that, It´s a beautiful benchy.

You might think that maybe my extruder just can´t handle the jerk and I should back it down a little, but I´ve got a couple of clues that tell me that maybe that isn´t the case.

First, I´m using 10 e jerk and I believe that my extruder should be more than capable of using this, since its not geared and current is cranked high, so if something happens it would rather chew on the filament than skip steps. Its of this style:

Second, I´ve seen it do quite some work with linear advance, for example while doing gapfill or the letters at the bottom of the benchy, but the part where it fails is a much easier section. This is it:

I hope it´s understandable, what I´m trying to show is that when the first (1) perimeter (internal) starts, everything is ok and the perimeter goes perfect, but when the second (2) perimeter (external) starts the extruder just stalls and it takes the whole perimeter to recover. (Note that you are watching here layer 17, and the issue happens while printing layer 18, both are exactly the same)

Third, the way it stalls is not a normal skipped step. It literally just stops. It doesn´t "snap" and then keeps moving like a normal step skip. It just stops dead on it´s tracks, and then starts again after a while.

I uploaded a video of the print missing the perimeter (so you can see better the movement where it stalls) and of the extruder stalling (so you can see the weird stall). Hope this is enough to pinpoint a cause, and find out if there´s an actual bug.

Video of perimeter failing to print (exactly at 0:08, you can actually hear the extruder disengaging at the start of the external perimeter and engaging again after the perimeter is finished): https://www.youtube.com/watch?v=Ym9LZCmsFH8&list=UUo6FE6-O51yfTyem8lkwxxw&index=2
Video of extruder stalling oddly (exactly at 0:14, you can see and hear the extruder disengaging and then engaging again): https://www.youtube.com/watch?v=XPeTST3yFWg&index=1&list=UUo6FE6-O51yfTyem8lkwxxw

Same Gcode with k=0 prints fine.

On the zip, the config, config adv and gcode. Let me know if you need anything else. The only difference from the config is that my ejerk is 10 and k=0.65, but this is set on the fly.
LAfailEvidence.zip

[Itox001]

Pinging @Sebastianv650 for help

[Sebastianv650]

A perfect bug report, thanks for that!
So if I got it right, watching your videos, it stops extruding as soon as the printer switches to the outer perimeter and continues when the infill of this layer is starting.

I will try to recreate this on my printer, starting tomorrow. I never used the 2.0 branch before so I hope I can compile it, but beside this your config should run nearly 1:1 on my printer.

[Itox001]

A perfect bug report, thanks for that!

Thanks! I do tech support at a big engineering firm, so I know the importance of a clear bug report.

So if I got it right...

Exactly.

You shouldn't have trouble with the 2.0 branch, it complies perfectly fine and doesn't need any special libraries or anything. I use a MKS base 1.4, so the good old 8 bit. Thanks for checking this out! Hope we can get it sorted out, because otherwise linear advance has been giving outstanding results, I can print a pretty decent benchy even at 70mm/s, which used to show horrible blobbing on some parts and underextrusion on others without linear advance. (Oddly, this ultra fast benchy doesn't show the issue)

[Sebastianv650]

I'm getting the same compiler problems I had when I tried 2.0 some weeks ago. With 1.8.3, it's not compiling due to too long path / file lengths even if everything sits right on drive D. With 1.8.6 and 1.9 beta I get a known but yet unfixed bug with the compiler. Like this one: http://forum.arduino.cc/index.php?topic=542083.0, but it seems I would have to remove way more comments than just 3 lines.

Maybe you can try if the error is also there in 1.1.x?

[Itox001]

That's very weird, I actually just formatted my computer and installed Windows 10, and the only thing I had to do was to install the latest Arduino release from arduino.cc, download the bugfix and it compiled right away. Maybe use a virtual machine with a clean windows to compile?

Anyway, I'm trying the 1.1.x bugfix later today after getting home.

[Sebastianv650]

It looks like it depends on the exact configuration used. Your config files compiled fine, when I switch only the board to BOARD_RAMBO it fails. Change it back, and it fails again. Hit compile again and it worked once more with your board.

I found a way to remove all comments from the rambo board .h file using Notepad++, deleting some more comments from Marlin now allows me to compile it. I will give it a try.

[Itox001]

Awesome! Hope you can reproduce it. Just printed some other models yesterday and the issue showed up a couple of times, so it's not as uncommon.

[Sebastianv650]

Short report for today:

• I shrinked down your benchy gcode to +-2 layers from the reported problematic layer.
• When I run this with my default config, it works fine.
• Running it with a minimal-modified (changed board and stepper driver type) version of your config, the extruder stops at both perimeters of a layer.

So that's a good start I guess!

[Itox001]

At least you could reproduce it. It's weird that it happens on a feature (a whole perimeter for example) because the firmware doesn't know about features, only a stream of instructions to follow.

What I can think of that delimits the feature is retractions or acceleration changes because I run a different acceleration for perimeters. Going to test with constant acceleration and retractions disabled, to see if the issue persists.

[Itox001]

Okay so today I got to play around with it more, I also isolated the faulty layers so test would be quicker and this is what I found:

1. Lowering E jerk makes the bug go away. With 7 jerk everything is fine, but with 8 jerk and above it shows up. I was using E jerk of 15, hence I saw the bug.
2. Changing acceleration mid print does not affect it. Made it a costant 1000 mm/s^2 but the behavior was the same as described in 1
3. Using jerk 8, a K value of 0.25 doesn´t show the bug, but using a value of 0.3 does show it.
4. Using a jerk value of 15, k 0.55 doesn´t show the issue, but 0.56 does show it.

Very odd, but I hope this helps you find the cause.

[thinkyhead]

Quick-fix for compiler errors is to remove of end-of-line comments from all pins…

Simply regex-replace (#define +[A-Z0-9_]+ +[A-Z0-9_-]+) +//.+$ with $1 in the pins files. For example, in Sublime Text 3…

[Sebastianv650]

Status update:
This is a very specific bug! I was hoping to get a 2 or 3 line gcode to test with, but the shortest sniplet from the benchy file that produces the bug is this one:

M302 P1
G21 ; set units to millimeters
G90 ; use absolute coordinates
M82 ; use absolute distances for extrusion
M204 S1000
G1 F1800 ; Even this special speed is important!
;G92 E5.37489
G1 X102.762 Y112.114; E5.37489
G92 E5.37489
G1 X101.896 Y112.107 E5.41322
G1 X101.022 Y112.060 E5.45194
G1 X92.039 Y111.296 E5.85098
G1 X76.836 Y110.037 E6.52614
G1 X76.586 Y109.991 E6.53736
G1 X76.363 Y109.896 E6.54811
G1 X175.989 Y110.273
G1 X175.843 Y110.148 E6.55662
G1 X175.646 Y109.911 E6.57026
G1 X175.549 Y109.739 E6.57901
G1 X175.472 Y109.546 E6.58818
G1 X175.421 Y109.344 E6.59743
G1 X175.389 Y108.996 E6.61289
G1 X175.389 Y95.997 E7.18822

Even if I enable the first G92 and disable the second one instead the extrusion doesn't stop. Also removing more G1 moves will enable the extrusion.
Note that I shifted the outer perimeter part 100mm to the right, just to make the observation more easy. This has no influence.
Even changing the esteps/mm value from 99.8 to 99.0 or 100.0 leads to a continuous extrusion.

I disabled all extra features in Configuration_adv without an improvement, so it's not related to some special feature. I will have to think about dumping some debug information about USB, hoping they change no timing and "fixing" the problem by just transmitting unchanged data.

Free time on evenings is too short, guess I will deep dive into the code during the weekend.

[buchnoun]

I tried to increase my E jerk value from 5 to 10 as suggested but I still get the extrusion stopping... So back to K0 till a solution is found... In case that might be useful is a M501 from my anycubic :

Recv: echo:Filament settings: Disabled
Recv: echo:  M200 D1.75
Recv: echo:  M200 D0
Recv: echo:Steps per unit:
Recv: echo:  M92 X80.00 Y80.00 Z400.00 E919.78
Recv: echo:Maximum feedrates (units/s):
Recv: echo:  M203 X180.00 Y180.00 Z30.00 E50.00
Recv: echo:Maximum Acceleration (units/s2):
Recv: echo:  M201 X3000 Y3000 Z400 E10000
Recv: echo:Acceleration (units/s2): P<print_accel> R<retract_accel> T<travel_accel>
Recv: echo:  M204 P2500.00 R2000.00 T3000.00
Recv: echo:Advanced: B<min_segment_time_us> S<min_feedrate> T<min_travel_feedrate> X<max_x_jerk> Y<max_y_jerk> Z<max_z_jerk> E<max_e_jerk>
Recv: echo:  M205 B20000 S0.00 T0.00 X15.00 Y15.00 Z0.30 E5.00
Recv: echo:Home offset:
Recv: echo:  M206 X0.00 Y0.00 Z0.00
Recv: echo:Unified Bed Leveling:
Recv: echo:  M420 S1 Z10.00
Recv: 
Recv: Unified Bed Leveling System v1.01 active.
Recv: 
Recv: Active Mesh Slot: 1
Recv: EEPROM can hold 4 meshes.
Recv: 
Recv: echo:Endstop adjustment:
Recv: echo:  M666 Z0.00
Recv: echo:PID settings:
Recv: echo:  M301 P33.69 I3.81 D74.51
Recv: echo:  M304 P136.13 I26.38 D175.64
Recv: echo:Z-Probe Offset (mm):
Recv: echo:  M851 Z-0.55
Recv: echo:Stepper driver current:
Recv: echo:  M906 X800 Y800 Z800
Recv:   M906 I1 Z800
Recv:   M906 T0 E800
Recv: 
Recv: echo:Hybrid Threshold:
Recv: echo:  M913 X190 Y190 Z40
Recv:   M913 I1 Z40
Recv:   M913 T0 E86
Recv: 
Recv: echo:Linear Advance:
Recv: echo:  M900 K0.00

Thanks for your help

[Sebastianv650]

I think I got it:
When the advance ISR rate of the curent block is identical to the advance ISR rate of the previous block and the curent block has no acceleration phase the advance ISR will not be started as it should. The esteps during the cruising phase will then not trigger the advance ISR any longer.

@Itox001 please test the following change to stepper.cpp (in Marlin\src\module):

• Search for the line containing if ((LA_use_advance_lead = current_block->use_advance_lead)) {
• After the closing } of this if statement, add the following two lines:

nextAdvanceISR = 0;
LA_isr_rate = current_block->advance_speed;

On my printer this fixes the problem.

[buchnoun]

Well Thanks sebastianv650 I'm currently printing my 3rd object and it seems it's working fine :)
Just a quick question : how would I know if I'm using LA 1.5 or 2.0? dumb question I guess but I'm quite lost with all that bug fix branch GitHub thing, don't really know which marlin I'm using right now :)
Thanks again for your help...

[Sebastianv650]

@buchnoun LA 2.0 would be a cool thing I guess, but so far there is only a 1.0 and 1.5 ;-)
If you don't know the exact Marlin version or date, the easiest way is to look at the K factor. If it's around 0.x-2, you are using the newer 1.5. The v1.0 would do no noticeable extra movement with such low values.
On the other hand, if you enter an v1.0 K value of 100 and more on v1.5, you extruder would freak out completely with no chance of a decent print at all.

[Itox001]

@Sebastianv650 I got to test the fix yesterday and after some hours of printing it has worked flawlessly so far. The problematic gcodes are no longer problematic and I can now print 120 mm/s infill with 20 mm/s external perimeters no problem, proving that this LA implementation works with bowden extruders (mine, at least...). It even works with my Titan extruder, it requieres a much lower jerk (5) but since my Tornado print acceleration is pretty low anyways (500), I don't notice much speed reduction.

[Sebastianv650]

That's great news, I will create a PR 👍

[SJ-Innovation]

Hi, this fix breaks extrusion if Linear Advance is enabled, but K is set to zero. It results in the motor only moving if linear advance steps would have been made. May have been another setting in my setup, but might be worth a test before the PR is made.

[Sebastianv650]

@SJ-Innovation I'm aware of that, this two lines are meant as a quick test only. I'm curently working on the PR which will include some more small changes to to get everything working again as it should be. This PR should then be tested by some of you before it get's merged, I will set your name on the list.

[SJ-Innovation]

Okay :) Thanks for all your excellent work!

[blejdacik]

Hello!
PROBLEM with linear advance. Driver tmc2208, cheetah 1.2, Titan extruder.
Extruder do retract at end of line, then hotend moves to next line and extruder retract again.
Video here.
https://drive.google.com/file/d/1n5HXvY2dTtWvLYJFYXQUAlujS76-b6wh/view?usp=drivesdk
Sorry for my English but I hope you understand me. Thank you

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