[BUG] Micro stutter on high speed print moves

[Tailslide]

Bug Description

After migrating to the 2.0 release version from the previous release version, I notice 'stuttering' on long travel high speed print moves. The print head kind of stops and starts for a tiny fraction of a second leaving a poor surface on the print (no steps are lost). If I reduce printer speed using the lcd from 9000mm/min to 8000mm/min it almost completely goes away. I think the same print settings used to work under the previous release of marlin.. maybe I just made a mistake migrating my settings??

My Configurations

Configuration_adv.zip

Steps to Reproduce

1. Print attached file if you can? Issue should show up at second layer when print speed ramps up to 9000mm/min for the big fill area. RamboMountA.zip

Expected behavior: Not be jerky?

Actual behavior: Jerky!

Additional Information

• Provide pictures or links to videos that clearly demonstrate the issue.
• See How Can I Contribute for additional guidelines.

[Liger0]

Same. With the same settings as marlin 1, the quality of the perimeters is all jerky and uneven, really horrible.

[Tailslide]

I did realize I made one change ... I turned on bed levelling. Also I notice the jog dial on my lcd becomes unresponsive intermittently during printing. I’m wondering If it’s just too much processing for my Rambo board to keep up with at high speed.

[Liger0]

I have always had an ABL. I was using a cr10s v2.1 mobo (A4988 drivers), now an skr 1.3 with TMC2209.

[YAost]

If I'm not mistaking, it might be due to low Z-jerk value (when moving two or more axis simultaneously, you have to "respect" the slowest one, and that is exactly what UBL/ABL is doing). Have this "issue" as well, but haven't yet tried to eliminate it. As UBL fade height is reached, stuttering stops. Can't say about earlier versions, started fast traveling only on version 2.

[albert2004]

I updated Marlin 2.x from revision: 12c595c61f4b3e0be2baa6a906718e155a797ea3 to 2.0.1 release Nothing else was changed. Now I can see micro stops during linear movements even at speed 45mm/s (2700mm/min). With previous baseline, issue was not present but it was still 2.x branch.

I'm using MEGA2560 (Geeetech GT2560 board) with bed leveling (AUTO_BED_LEVELING_BILINEAR) and linear advance enabled and used. It looks like performance issue but it can be hard to investigate since I updated almost 3 months of development... For LCD display unresponsive, this was visible for me from when I changed to Marlin 2.x at extruding holes (a lot of small linear movement commands).

[Tailslide]

If I'm not mistaking, it might be due to low Z-jerk value (when moving two or more axis simultaneously, you have to "respect" the slowest one, and that is exactly what UBL/ABL is doing).

I'm using the new 'junction_deviation' not CLASSIC_JERK so don't think that's it.

[YAost]

Update: Installed 1.9 version which I used earlier and can confirm that no stuterring is happening with UBL online, so definately an issue for 2.0. Already get used to it, to be honest.

[boelle]

@Tailslide does this also happen with bugfix 2.0.x ?

[thisiskeithb]

I was seeing similar micro stutters on long travel moves on my SKR 1.3/TMC5160 build before I tore it down for an upgrade. The rebuild will be with an SKR 1.4 and TMC2209s and is almost done, so I’ll be able to check if the issue persists.

[mavericm1]

I also have this issue using skr1.3 tmc2209 with ABL bi-linear using latest 2.0.1 release and linear advance. turning on classic jerk solves the issue for the most part but i'm still seeing some inconsistency in nozzle placement.

[vadsh]

I have the same issue with 2.0.1 release. Stuttering at higher speeds (150 mm/s).

Previously I used 2.0 version (about 4-6 months old) - there was no such an issue.

Board: skr 1.3. Drivers - TMC2208 (5 total - 2 for Z). s-curve - on, junction deviation - on. bed leveling with bl-touch

with LA enabled seems to be more prominent.

Advanced ok output shows that planner queue is ok (I have BLOCK_BUFFER_SIZE = 64 and it is almost full).

Tried with SQUARE_WAVE_STEPPING (on/off) MINIMUM_STEPPER_POST_DIR_DELAY 20 MINIMUM_STEPPER_PRE_DIR_DELAY 20 MINIMUM_STEPPER_PULSE - 2 and 4 STEALTHCHOP_E - on/off MAXIMUM_STEPPER_RATE 400000

The stuttering is very similar to what I've seen with 8-bit board when it was unable to process all the moves.

Is there any way to see debug info about mcu load or stepper Motor Queue depth? I believe that it is limited processing power that triggers such behavior.

[vadsh]

Probably this bug somehow relates to these https://github.com/MarlinFirmware/Marlin/issues/16547 https://github.com/MarlinFirmware/Marlin/issues/16535 https://github.com/MarlinFirmware/Marlin/issues/16308 https://github.com/MarlinFirmware/Marlin/issues/16248 https://github.com/MarlinFirmware/Marlin/issues/16155 https://github.com/MarlinFirmware/Marlin/issues/15908 https://github.com/MarlinFirmware/Marlin/issues/15516 https://github.com/MarlinFirmware/Marlin/issues/15692

Seems to be problem with TMC drivers on newer marlin.

It also seems that most of complaints are from SKR 1.3/1.4 and TMC drivers combination

[Tailslide]

I don't have the TMC drivers I have A4982 but the links are interesting.

I'm still thinking the unresponsive LCD screen when printing fast might have something to do with my issue.. either the board not keeping up or something about the firmware isn't handling high demands on limited resources well.

Haven't had time to experiment with a lot of settings yet but if I did I'd probably start with fiddling with MAXIMUM_STEPPER_RATE, etc and failing that disabling linear advance or enable classic jerk. Or maybe just give up and throw in a 32 bit board or go back to 1.9.

[vadsh]

@Tailslide If you run 8-bit board - the problems are most probably with it's inability to match all new demanding features (LA, S-curve, JD etc.). My experience with 8-bit was exactly like that.

But what is strange - similar problems arise even at 32-bit.

[boelle]

i run both LA, S-curve and JD plus bi-linear leveling and no issue here

[vadsh]

@boelle Behavior is quite tricky and unstable. Very hard bug to be able to reproduce reliably.

For example, sometimes extruder just stops on the second layer (where speeds are higher). One time both extruder and heavy bed stopped. I've noticed other bugs in issue tracker similar to this (seems to be some TMC protection working). The more features enabled - the more prominent the bugs. For example lower layer (before fade height) seems to be more prone to bugs. LA enabled - more bugs. Etc. Performance problems? No way to answer (no performance monitoring in marlin available and documented).

Other people reported that even connectors and wire length matters (i have high currents and long wires)

Each test cycle is tedious since one iteration takes more than 30 minutes (compile, flash, heat up, probe the bed, print, heat down).

I print with 150 mm/s speed 3000 acceleration with many advanced features enabled (s-curve, bed leveling, dual z, z-align, Catmull-Rom interpolations, ADAPTIVE_STEP_SMOOTHING, LA, JD, ADVANCED_OK, fade height, TMC_DEBUG, MONITOR_DRIVER_STATUS, etc). This seems to be quite rare in the community at this moment.

Is that possible that I hitting LPC1768 performance limit? Who knows without debug info being available.

But it's quite evident that some problems exists. Hard to pinpoint though.

For now I was able to run with latest bugfix-2.0.x (24.01.2020) and the following settings

SQUARE_WAVE_STEPPING enabled (not default) MINIMUM_STEPPER_POST_DIR_DELAY 20 MINIMUM_STEPPER_PRE_DIR_DELAY 20 MINIMUM_STEPPER_PULSE 4 (not default by far) STEALTHCHOP_E - disabled (not default) MAXIMUM_STEPPER_RATE 250000 (not default by far)

But I've lost a couple of days trying to find these settings and lots of trial and error. That should not be the case ideally.

Default settings at latest release (official 2.0.1) definitely was not working for me and lots of other people. See the list of bugs I've posted above. Most are closed without definite solution. There are others similar to these.

It would also be helpful to have some methods to debug and monitor MCU load, steppers queues etc. Its really a pity that there is no such thing available and documented for now.

[boelle]

Behavior is quite tricky and unstable. Very hard bug to be able to reproduce reliably.

agreed, but its the first step towards being able to fix it :-/

[tatusah]

What slicer and printer do you use @vadsh ? It's been reported that in Cura for some printers the default profiles have the maximum resolution setting unnecessary high and is causing stuttering.

[vadsh]

@boelle

I believe very good first step - is to introduce performance monitoring.

It should not be hard to implement. At least Marlin should be able to notice the moments when something went wrong (low memory, not enough processing power, stepper queue empty, etc) and report about it via serial.

Seems like very easy thing to implement. And so useful (especially for 8-bit where performance is sooo limited for current marlin 2.0). But I suspect that even 32-bit can have performance issues.

[boelle]

@vadsh i'm not a coder so you must mean @thinkyhead

[vadsh]

@tatusah

What slicer and printer do you use @vadsh ? It's been reported that in Cura for some printers the default profiles have the maximum resolution setting unnecessary high and is causing stuttering.

I use cura. But I believe that problem is not in cura. For the following reasons: 1) I lowered the resolution already (0.3 for print moves, 0.5 for travel) 2) I have pretty high planner buffer (BLOCK_BUFFER_SIZE 64) and ADVANCED_OK enabled and high BAUDRATE. Advanced ok reports that buffer is almost full most of the times. 3) Stuttering exists in very long and fast (about 270 mm long 150 mm/s fast) travel move in Y-axis alone (but steps are not skipped!). If I understand how marlin works correctly - Cura resolution settings doesn't matter in this case.

By the way - it seems that motor load can be involved somehow. Heavy bed moves seems to be more prone to stuttering than light x moves. Extruder seems to be more prone to stuttering when pressure is higher (for example printing second layer at 12 mm3/sec when first layer overextruded). But extruder seems to be skipping steps and Y-axis - not skipping - just stutter.

Sometimes stuttering is so strong and fast that it seams that printer will self destroy...

Too many variables to tell exactly what happens...

[mavericm1]

It definitely wasn't the resolution size for me. But i think it may be related to ejerk. I had eeprom of 5 ejerk and forgot that my slicer was set for a much lower ejerk of 1.25 and i think this may have been causing it at highspeed. I need to retest at a ejerk of 5 with JD enabled but i have a feeling that maybe with JD LA and Scurve enabled that maybe they are conflicting with eachother as far as E kinematic motion. I'm at work now but if anyone is able to test changing your ejerk at a high feed/speed rate and see how this interacts.

[vadsh]

One additional notice. May be related somehow.

I have TMC drivers with *_MICROSTEPS in HAS_TRINAMIC section set to 16 and INTERPOLATE true. It works ok.

But when I try to set *_MICROSTEPS to more than 32 - skipped steps were introduced. So 16 is ok. 32 works but misses steps very rarely. 64 - misses steps always (especially for 0.8 degree steppers) That is for speeds around 150 mm/s

Important note - it is 32-bit board (SKR 1.3).

As far as I understand - the most probable reason for this - is MCU's inability to consistently produce stepper impulses at such a high rate (64 microsteps for 0.8 degree motor: 150 mm/s * 640 steps/mm = 96 000 per second per axis)

Again - no way to tell exactly without performance monitoring feature.

It's actually so strange that such a profound piece of software and such performance dependent has no performance monitoring?!

[vadsh]

I've found another thread with similar problems - i've seen similar symptoms during experiments with settings https://github.com/MarlinFirmware/Marlin/issues/16076

[boelle]

@Tailslide could it be that you are simply trying to move to fast and the MCU cant keep up?

EDIT: there is a limit to how fast the Rambo can move before this happens a mega2560+rambo have the same chip and i had that issue when i tried to do to much at the same time, the only fix is to lower speed and acc so the problem goes away

[maehtricks]

@vadsh I'm on SKR 1.3 with TMC2209 and TFT24 (serial). Noticed today that it slows down frequently which didn't happen with my old marlin 1 based board.

Switched almost every setting on and off, but didn't find anything. Finally found out that printing from sd card works fine via tft24. Printing via serial works as well if the display is not connected.

[vadsh]

@maehtricks Serial is definately a bottleneck. Especially if you run at low baudrates.

ADVANCED_OK feature + octoprint serial logging is great to monitor this part though.

At baudrate 1000000 I'm able to get about ~144 gcode lines per second which is enough for most of my prints.

Planner buffer matters much - with SKR 1.3 I was able to set 64 value. Slowdown should occur when the buffer is half empty (which I find not very optimal, since 32 commands left - is still enough)

But what is important here - we definitely need some tools to monitor performance and bottlenecks! I cant understand why there is no such thing in marlin.

[thinkyhead]

I guess there is nothing actionable here. When there is more data collected and it points to a specific bug please submit a report.

[FreestylePocker]

I have this bug when using any Bilinear or UBL automatic bed leveling, without bed levelling prints are pretty smooth. Bottom of 20mm 3DBenchy Left one without any leveling, only G28. Right one with billinear executed by G28 + G29

I think it somehow related to Z adjustment calculations

UPD Sorry, false alarm, my problem were due to too much filament flow, and too tiny Z offset so the ripples accumulated from outer side, look few outer lines were normal.

[thinkyhead]

@FreestylePocker — Thanks for the image showing the symptom, but we aren't able to do support as a continuation of a closed issue. If you mean to report a bug (that we can take action on) please submit a bug report and fill out the complete template. Before filling out the report try a lot of things to see if you can get improved results. For example, see if it helps to increase your Z jerk or Z acceleration. Try slowing down the print speed or speeding it up. Try using more or fewer points. Try using the interpolation option. Etc. Collect as much information as possible for presentation so that we have many clues to work with. This will help save time for whoever ends up looking into the problem.

[sl1pkn07]

same here with ReARM

the config https://github.com/sl1pkn07/Marlin/commit/081f2e97b94d5214ed7037b84e6775e878191f7c

but my problem is with non-print traveler from point to point in large distance

https://www.youtube.com/watch?v=9V2YY8zvgH0

[raidho36]

Having this issue on all high speed non-straight-line movements on Anycubic i3 Mega S Marlin 1.1.9 (I've checked the entire changelog and haven't found notes of bugfix for this so it might be still valid). My steppers can run 450mm/s when the motion is perfectly linear with no problem whatsoever, but even something as simple as drawing an arc across the entire bed causes stutter. At speeds above 300mm/s the abruptness of stutter causes skipping. When bed mesh leveling enabled the effect is particularly bad (up to fade height) because every movement is non linear. None of the acceleration and jerk settings improve anything, only reducing the movement speed seem to resolve the issue. This makes my practical speed limit only 115 mm/s. Even though I don't print anywhere near 450 mm/s I would like to have such speed available for jog.

See attached video. https://www.youtube.com/watch?v=D7XGRRMJHVQ

[AnHardt]

Marlin has a speed-limit. Always had a speed-limit. And will always have a speed-limit. It lasts some time to step a segment. How long that lasts depends mainly on two things. How long is that segment and how fast should it be stepped. The time for planing a segment is in average constant for a given configuration. It depends on dozens of factors, beginning with the processor type, the MHz, the platform, the degree of optimization of Marlins code for that platform, the buffer sizes, other selected options, ... and ends with the selected baud-rate and the ability of the host to send g-code fast. However it depends not on the length of a segment nor on the commanded speed for that segment. That means, from one speed/length ratio on, the time for stepping the segment was, is and always will be shorter than for planing it. That's completely unavoidable. You have to accept that.

What matters is the point where that occurs - and that is shifting a bit from day to day as Marlin is permanently worked on. New features tend to make planing slower (and larger because they always need time to execute ). Optimizations tend to make it faster or more precise. Bug fixes can make planing speed better or worse. We just always try to make Marlin faster and better - trying to find the right compromise.

So if you say: "My machine stutters if printing short segments fast." i have to say: "Yes - that's normal.". As long as you can't give us a hint where to search for more speed it's useless to complain about low print-speeds. Improving that is always on our agenda.

If you want to ask: "What can i do to make my printer faster?" that's a much to general question for Marlin-Issues.

My general answer to your general complain is: "Find a acceptable compromise between print speed, sent segment length and activated time consuming features for your machine."

[raidho36]

If it's a performance bottleneck that's limiting printing speed, maybe this should be mentioned in the manual, so that people consider their firmware settings and don't think it's just a bug.

[AnHardt]

I would not call it bottleneck - more the nature of things. The number of things/systems that are not limited is (not very) surprisingly small. The universe ? - may be. Compare it to Formular 1 racing on a unknown curvy course between walls. The curviness determines how far you can look ahead (planner buffer). Now divide this distance in to segments - here break, there steer, then break more, steer more, shift the gear here and step on the gas again (variable length segments). You can't make infinit decisions about your plan. Calculating the steering angle and the fastest matching speed takes a while (fixed planing capacity). And there are distractions: observing temperatures, pressures, tire conditions, flags, reading time/lap signaled by the box, observing the concurrent, radio with the box, planing the next stop, attractive grid-girls, the winners party tonight, the virus, inventing a Perpetuum Mobile (other activated features) distracting from planing. If you are at the systems (You and the car) limit and get the order to go faster, or fog comes up, or the pretty girl gives you a smile - the planner buffer runs dry - you have to break hard - and if the (de)acceleration settings are not correct you are leaving the track (lost steps).

[raidho36]

Arguing semantics there, mate. Just give people proper heads up that movement speed will also be limited by CPU throughput.

I'm pretty sure that if it can accelerate and decelerate just fine when going in a straight line, then the settings are OK. More looks to me like the CPU couldn't send step pulses in timely fashion so the steppers lock up momentarily, causing belt or stepper skipping, whichever was weaker.

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