[BUG] Motor stuttering with linear advance on TMC2208 since Marlin 2.0

[Schild0r]

Hey there, in the past I often tried to switch to Marlin 2.0 from 1.1.9 but there was always some hinderance. Eventually I managed to sort out most of it (last was the motor knocking noise where you have to disable monitor_driver_status but I digress)

Bug Description

So I ported all the settings from my working 1.1.9 configuration to Marlin 2 (running an MKS Gen L with 5x TMC2208 in UART mode, dual BMG bowden extruder). In 1.1.9 I made use of linear advance and dialed in my K factor at 1.45 Now with Marlin 2 I get this weird stuttering on my extruder motor when linear advance is used (no stutter when I set K = 0) Any ideas why this is? (Here's also a video of that symptom: https://www.reddit.com/r/3Dprinting/comments/e73s9h/marlin_2_tmc2208_stutter_with_linear_advance/ )

Already tried

I already tried using square wave stepping or setting the minimum stepper pulse to 1 or 2 (with TMC2209s installed you would get an error which tells you to do so with linear advance enabled and Trinamic drivers however with TMC2208 drivers you don't get that error message but I tried it anyways). Also it makes no difference whether I use stealthchop or spreadcycle or make use of hybrid_threshold. Running the driver in standalone mode or changing a TMC2209 driver and running that one in standalone mode makes no difference either

also see the attached configuration files (only changes I made are in these two files and always denoted with "//MS" in that line ) Schild0r_Marlin2.0_config.zip

[randellhodges]

Try disabling stealthchop on E. From everything that I read, TMC2208, linear advance and stealthchopped e don't mix.

[Schild0r]

Try disabling stealthchop on E. From everything that I read, TMC2208, linear advance and stealthchopped e don't mix.

As stated above this does not fix it. It only makes the stutter a little bit quieter (or it may only seem like it due to increased overall noise of the extruder motor/driver)

[ManuelMcLure]

This seems like another instance of #10272 - there's a problem with Linear Advance in 2.0 that causes extruder rattling but I don't think anyone knows why yet.

[Schild0r]

This seems like another instance of #10272 - there's a problem with Linear Advance in 2.0 that causes extruder rattling but I don't think anyone knows why yet.

Agreed. Might be the same cause. But didn't you say in that post that using CLASSIC_JERK would mitigate the rattling? I will try that with my setup today and if it helps maybe print a set of benchy and calibration cube with JD and noLA vs JERK and LA

Edit

So Finding No. 1: enabling classic jerk indeed does eliminate the stuttering (i.e. sudden direction changes on the extruder which is creating vibration and noise) and linear advance does work with jerk enabled. Finding No. 2: However linear advance will still cause noise from the extruder motor but it is not a rattling but a low pitched whine (similar like if you run A4988 drivers but not quite it) Finding No. 3: running linear advance with jerk (x6, y6, z0.3, e4) and a minimum stepper pulse of 2 results in worse quality (greater corner buldge: 0,27mm vs 0,135mm) and slower prints (50min vs 32 min) than running no linear advance with junction deviation (0.013) and a minimum stepper pulse of 0 as seen below. it is likely though that the slower print speed has a negative effect on corner buldge (i.e. greater buldge) as well BUT I rather take better quality in less time anyway...

[boelle]

btw is JD calculated correctly?

http://blog.kyneticcnc.com/2018/10/computing-junction-deviation-for-marlin.html

[Schild0r]

btw is JD calculated correctly?

if you are referring to the values I used above: No I didn't translate them since I did not know the formula. I just used the standard value of the basic config.h file.

So if I translated the Jerk values, my JD would be even lower. But again, I won't complain when I get better quality in less time.

EDIT: Did someone already try setting the JD to 4.1421 and printing a 20x20x20 cube?? A JD of 4.1421 would result in a Junction radius of 10 so would said cube turn to a circle then?

[boelle]

better quality in less time migt be impossible

the faster you print the quality will suffer, itsa just a matter of printing fast enough

[YAost]

This issue is simillar to another request https://github.com/MarlinFirmware/Marlin/issues/16184 You have S-curved acceleration enabled as well, worth checking without it.

[ManuelMcLure]

In my testing S-curve seemed to make no difference, but your mileage may vary.

[robustini]

Same issue here with TMC2130, damn.

[Vertabreak]

does that say linear advance k = 1.45 holy cow that's high never seen a working valid k over 0.5 even with over a foot of bowden tube.

[robustini]

There's a confict with Linear Advance and Junction Deviation, i disable the second one and the L.A. work fine here. This is probably a bug that needs fixing.

[sjasonsmith]

Yesterday I noticed unexpected (to me) timing on the extruder with linear advance enabled. Perhaps it is related to this issue. I am only timing signals, I don't actually have a driver connected, so I can't be sure that this is related to the stuttering described.

In this image you can see a steady frequency, which corresponds to the Linear Advance interrupt rate. This is with square-wave stepping, so the narrow "glitches" correspond to two or three steps taken in a single Linear Advance ISR.

I suspect this could be causing the stuttering, and might even cause TMC2208 motors to shut down, based on past behavior I have observed.

[ManuelMcLure]

When I turned on LA_DEBUG I was seeing a lot of instances of

More than 2 steps per eISR loop executed.

which matches up with what you're seeing in the stepper timing.

[boelle]

@Schild0r is the issue still the same with all the updates in the last 13 days?

[boelle]

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

[sjasonsmith]

I have reproduced 2208 drivers turning off related to the picture I posted. I don’t know whether that is the root cause of this or not, but it seems possible.

[Schild0r]

@Schild0r is the issue still the same with all the updates in the last 13 days?

Will test with the latest marlin build and stuff like s-curve turned off etc once I am home in the next few days. Happy holidays to y'all :)

EDIT: Didnt work.

[Lord-Quake]

Using search I came to this open issue thread

Today I started to design a K-Calibration tower that I want to post on Thingiverse. I'm working on a real life calibration object as the values coming from the K-factor Calibration Pattern didn't corollate with the quality I was expecting. This how the prototype tower looks like: Here the G-Code file for internal use only: K-Tower_Calibration_Leo_N.zip (Edit the header to your setup accordingly)

I'm posting here because when K was at 0.04 I received the following debug output: More than 2 steps per eISR loop executed. At 0.4 and 0.0 all was fine again.

Marlin 2.0.1 was used. Config files: K-Configurations_Leo_N.zip

I can test if needed......

[ManuelMcLure]

Can you check out @sjasonsmith 's fork linked from https://github.com/MarlinFirmware/Marlin/issues/15473#issuecomment-568802775 and see if that affects the behavior? This is not ready for prime time, although I myself have tested it and it seems to work well.

[Lord-Quake]

Test completed. No change, same outcome.

I compiled the FW from @sjasonsmith using my configs from above.

On another note: For this test I mistakenly used the gcode from the K-Pattern script instead of my cal. tower. When the printer drew the very first K line the console gave out "More than 2 steps per eISR loop executed." from the get-go and when the print head came to the end of the first line it paused for a brief period before it moved on to print the second K line. I don't recall this happening with the 2.0.1 FW.

[qwewer0]

I have this problem too, thought it was normal even if it's annoying. Ender 3, SKR Mini E3 v1.2, TMC2209, Marlin 2.0.0/2.0.1, LA K 0.4 - 1.4, S-Curve, Junction deviation on/off

[boelle]

@Schild0r is this still an issue when using bugfix 2.0.x ?

[qwewer0]

Compiled a fresh bugfix 2.0.x, the problem is still there.

[boelle]

how often do you update? bugfix is updated almost daily

[qwewer0]

Recompiled the latest bugfix build [2020.01.24.], the problem is still here. Ender 3, SKR Mini E3 v1.2, TMC2209.

[boelle]

i just got TMC2209 and dont have the problem, so the issue is likely to be the SKR Mini E3 v1.2 (or MKS Gen L which is what @Schild0r uses) as that is the only difference

[Schild0r]

Compiled the latest bugfix (or at least the one from 5 hours ago) and did some testing. Found out that decreasing the K Value makes the stutter less pronounced/shorter which makes sense I guess since the extruder does not have to decelearate as long as it would have to at higher values.

I then tested at a K value of 0.4 and found that - while at higher values you hear the stutter at every junction - at that low value the stutter seems to only occur on small or sharp movements. So Lets say we print a 20x20x20 calibration cube with a brim of 5 lines. The vibration is notable on the corners of the cube since they are sharp. But since the corners of the brim get rounded by the slicer, you can only hear it at that point where the transition from one brim line to the next inner brim line is located (same with solid infill etc. only where the small transition to the next line is, stutter/vibration occurs).

While it was printing I decreased the feedrate to 80% then 50% but even at 30% I could still hear and feel the vibration regardless without a notable difference which does NOT make sense to me since linear advance is a function of speed and decreasing speed should then decrease deceleration needed doesn't it?

also: why is there a "wait for user" now after heating and after the job has finished??? How do I turn it off? If I would want that I would put it into my start/end gcode myself. I now have to put "M400"s everywhere to not run into some buffering related inconsistencies where some actions are done before that 'wait' that should actually be done afterwards and vice versa...

[ManuelMcLure]

i just got TMC2209 and dont have the problem, so the issue is likely to be the SKR Mini E3 v1.2 (or MKS Gen L which is what @Schild0r uses) as that is the only difference

NO!! This happens with TMC2209 (or A4988) on Re-ARM as well. I can't use Linear Advance on my system (Re-ARM, BMG extruder, in direct drive, either TMC2209 or A4988 on the extruder) without rattling and underextrusion. If it works for you, great! But don't say it's due to the SKR Mini, or due to TMC2208. There are known issues with LA generating pulses out of sync with the normal extruder stepper pulses that cause rattling.

[qwewer0]

So, the higher the K value the more the motor has to compensate, and thus makes more noise. Makes sense. I didn't even realise it, but I did hear it more with K = 1.2 than K=0.4.

[boelle]

when i did the calibration patterni ended up with an insane low value of 0.05 i started out with 0-2 in the pattern and i had to go below 1 so did 0-1 in 0.01 steps

might explain why i dont hear or see anythin

[ManuelMcLure]

I see it with values as low as 0.06.

[kingofmonkeys]

So I just updated my firmware to 2.0.3 and I think i am having this issue now. Skr pro, tmc2209s, LA and s curve enabled. The printer looks like its working great BUT on some of the long flat surfaces i saw a pattern in the print. When i investigated i realized the extruder head (im running direct drive hemera) was vibrating at a pretty high frequency in those sections. After the current print is done im going to see if i can recreate it in a smaller print for testing.

[thinkyhead]

@kingofmonkeys — Try disabling S-curve and/or Junction Deviation and compare to see what kind of results you get. There does seem to be bad interaction between S-curve and JD according to reports, and this could extend to the extruder.

One recent (much needed) update we got in a recent version was for step pulse timing, so we should also look at that and see if it could be involved in the behavior.

[kingofmonkeys]

@thinkyhead I forgot to mention I already have JD disabled, I have been running without it for a while because it seemed to cause issues.

I updated from 2.0.0 to 2.0.3 so i jumped a few versions (there wasn't a ton of time between those versions) but there were a bunch of updates in there. I'm currently wondering if the DEFAULT_EJERK could be causing my issue or at least making it noticeable. I had it set to 1.0 in the 2.0.0 build but saw the default of 5 when updating and decided to split the difference and make it 3.0.

[ManuelMcLure]

@kingofmonkeys — Try disabling S-curve and/or Junction Deviation and compare to see what kind of results you get. There does seem to be bad interaction between S-curve and JD according to reports, and this could extend to the extruder.

I did some testing under #10272 including disabling S-curve and found it to have no effect on my problem: https://github.com/MarlinFirmware/Marlin/issues/10272#issuecomment-547226919

[kingofmonkeys]

So i created a simple test print and ran it under current settings last night. Tonight i plan to run one with LA turned off to see the results.

[Lord-Quake]

@kingofmonkeys Could you post your g-code file that is showing the issue.

[kingofmonkeys]

So this is the first test file, its just a rectangle. I tested last night with K set to 0 and i'm still getting the odd pattern. I'm considering going back a few versions to see if it goes away. Since it did the same thing without LA I'm thinking this problem might not be related to the issue here.

simple flat.zip

[Lord-Quake]

I just took a look at it.... over 2:15 hours print and over 11 meters of filament :-O That's a huge test print. I think 2 cm height should be enough to see the result. I'll be using todays 2.0.x bugfix.

[kingofmonkeys]

yeah it could stand to be shorter. the print that i first saw this on was taller and i didn't see it lower in the print. I know now that i didn't see it lower because of the details lower in the print, the effect is only see on straight sections. I can shorten this one up but its just a basic rectangle nothing fancy.

[kingofmonkeys]

Ok after a bunch of testing I found that my issue is NOT the same as this issue and not related to the firmware, sorry for the false alarm. I had a belt mount that was giving out and causing minor vibrations that I could see in the print. I just happened to notice the defects after I updated the firmware.

[Lord-Quake]

Using your g-code I wasn't able to reproduce the issue as well.

[kingofmonkeys]

yeah it was definitely the faulty bracket, after i found and replaced it no more vibration and no more pattern on the print. again sorry about that.

[Scope666]

Myself and a few others have a similar bug, but it's not Marlin's fault. I believe it's an actual hardware bug with the TMC2209s on the SKR E3 Mini 1.2. The symptoms are louder than normal motors, INSANELY hotter than normal motor temps, and missed steps. It would happen maybe once in 10-20 times powering on the machine. Power cycling would fix it. Crank the volume to hear it:

https://www.youtube.com/watch?v=rcYc3-wiAYw

TMC debug of the bad X motor while the bug is happening: (1F instead of 11)

[thinkyhead]

Duplicate of #10272

[qwewer0]

I believe it's an actual hardware bug with the TMC2209s on the SKR E3 Mini 1.2.

Could you upload your config files? I have the same board and I had never experienced that you did, I want to make sure that it is not something in the firmware.

[Schild0r]

Why is this issue closed now? I see that this might be a duplicate of above mentioned issue but that one is also closed without any solution to the problem and since that conversation moved to discord the conversation gets split even more without anybody knowing if there is someone working on that, what a possible solution could be etc

[Scope666]

I believe it's an actual hardware bug with the TMC2209s on the SKR E3 Mini 1.2.

Could you upload your config files? I have the same board and I had never experienced that you did, I want to make sure that it is not something in the firmware.

Sure, I'm not using the E3 anymore (on SKR 1.4 now) but my last config was this:

configuration.h: https://pastebin.com/6vZSZWLi

configuration_adv.h: https://pastebin.com/KkJfE0KY

[qwewer0]

Didn't find any unusual in your configs, but can SQUARE_WAVE_STEPPING have this kind of unexpected effect?