Stuttering movements on 2.0.x (5/23/2018 complile)

[Pyro-Fox]

Description

When testing the latest compile of Marlin 2.0.x (5/23/2018 in this case) I'm getting motor stutters that I wasn't getting from my 2.0.x 3/19/2018 compile.

Configuration

• MKS Gen 1.4 Board
• Latest OctoPrint (for USB print testing in this case)
• Folger Tech FT-5 R1 printer
• 4 TMC2208 Stepper Drivers

Steps to Reproduce

• This impacted all printing movements. Even simple things like the K-Factor calibration pattern.
• The issue occurred at all feed rates and print speeds. In the examples below, I was printing at 3600 mm/min. However I experienced the same behavior printing as slowly as 725 mm/min
• Issue occurred while printing over USB (from Octoprint) and from SD card (with OctoPrint disconnected).
• I tested an EEPROM reset (M502 + M500) and it didn't resolve anything either.
• Rolled back to my 3/19 build and issue goes away.

Additional Information

Files: 5-23 Config.zip 3-19 config.zip Video: https://photos.app.goo.gl/ZZbBVhP0nllR7XTf2 (Stutters at ~13 and ~33 seconds) Pictures: https://imgur.com/a/pvOqsVX

[puddly]

I thought this was some problem with my stepper drivers but it is indeed Marlin. I'm also running the latest bugfix-2.0.x on a similar setup, including linear advance.

0566badcefda3146fbccebade4a9131cde5e6f20 is the last good commit (ha). a11eb50a3eab6d58d595a67e526fb51190018db3 did not compile for me and e0ca627033504dd7bf8d9b87ce9ec526ee792276 began stuttering, so something with the stepper/planner refactoring and enabling LINEAR_ADVANCE is causing this, I think.

[thinkyhead]

In fact we know that there is something amiss when using Linear Advance since the refactor. The author of Linear Advance, @Sebastianv650, is looking into it at #10688 with some help from @ejtagle, the author of the updates to the planner and stepper code.

While we await their patch, can you test with LIN_ADVANCE disabled and see if the problem also manifests? You can still try the K-factor calibration pattern as your test, to save on filament.

[thinkyhead]

Also, test with LIN_ADVANCE and JUNCTION_DEVIATION enabled and see whether the problem is less or more pronounced.

[puddly]

With 645df23eb0cb11f67ec69959cbd75807e24ea225:

• LIN_ADVANCE disabled: OK
• LIN_ADVANCE enabled: stutters
• LIN_ADVANCE enabled with M900 K0: stutters
• LIN_ADVANCE enabled but running the same gcode file with all extruder moves removed: OK
• LIN_ADVANCE enabled and JUNCTION_DEVIATION enabled: stutters, no difference
• LIN_ADVANCE enabled and JUNCTION_DEVIATION_INCLUDE_E enabled: stutters, no difference

[thinkyhead]

The conclusion we've reached is that the Linear Advance scheduler got broken by the recent refactor update. A fix has not yet been devised, but we have some ideas and it should be fixed very soon.

[ejtagle]

@puddly : If using the latest 2.0.x, you can test if this patch fixes the issue: stepper.zip

Replace stepper.cpp by this one.

[puddly]

@ejtagle those changes fix the stuttering issue, at least on my small test print.

[ejtagle]

@puddly : If they work for all the people (i am hoping they will!) they will be integrated into Marlin very shortly 👍

[ikarisan]

Just updated to the "fixed" version but it seems that there is still some stutter. I.e after my initial prime line from (X/Y) 1/1 to 200/1 the motors stutter when X and Y moves to the startpoint of the print (somewhere near the center).

[ejtagle]

@ikarisan : Maybe that happens on a very fast move ?

[thinkyhead]

the motors stutter when X and Y moves to the startpoint of the print

So… during a travel move with no E movement?

[AcHub]

I think I see the same behaviour with my prints on travel moves with no extrusion. During print moves with extrusion it seems to be fine

[thinkyhead]

Does it matter whether bed leveling is on or off?

[ejtagle]

@thinkyhead I have also seen that problem. The ISR rate is limited by some of the changes we did. Threr is an specific 8uS minimum time between ISRs that is enforced by the firmware.

If we assume 96pulses per mm (16microsteps), that gives

1/8uS = 125kHz maximum ISR rate = maximum movement speed: 1302mm/s If we use 32x microsteps, that halves into 651mm/S

So, if the maximum travel speed is greater than that amount, you WILL see stutter and/or speed limitation of the moves.

Anything below that speed should work fine...

[AcHub]

@ejtagle Are you refering to travel speed as set in the slicer? Because I have set it to 270mm/s and still get stuttering on travel moves. I can test without bed leveling, but that will probably take me a few days

[ejtagle]

Yes, travel speed for non print moves - It would be interesting to know also if bed leveling is the culprit. Undoubtly it could, as it breaks each linear movement into hundreds of small movements, thus increading the planner work quite a bit...

[ejtagle]

@thinkyhead : I think i have figured out an execution pattern that could cause stutters. Let me explain... Let's assume the Stepper ISR is ending, has read the timer value, and ensured that the next to be programmed value is + 16 (in avr case) of the current value (to give AVR time to execute the ISR epilogue code at least, before reentering.

Logic seems bright, but it has a flaw, a very important one: The stepper ISR is running with interrupts enabled, so, a different interrupt could preempt it (the serial port interrupt, for example, or the beeper interrupt, or ...). If it is preempted between the estimation of the period time to be programmed, and the actual programming of the compare value of the timer, then the value could be less than the actual timer value at the time of the programming, and there you have: A full stutter, or lost step, as the timer has to wrap around!( 30mS in AVR, 4 minutes on ARM) before the stepper ISR resumes normal activity...

That could be the explanation to the problems, dont you think ? ... And this code flaw is there since the day interrupts were re-enabled in the stepper isr...

What do you think ?

[thinkyhead]

I haven't seen any stuttering of the kind described under normal usage, and I'm not clear why there would be a full wrap-around. I would expect the interrupt-pending state to be set by the compare, and then the interrupt should just occur at the next opportunity.

Of course, there are many experiments we could devise to figure out where stuttering is coming from.

[ejtagle]

@thinkyhead : Example: Let´s assume AVR (timer increments every 8 instructions)

1] We are at the end of Stepper::isr_scheduler, about to execute:

 min_ticks = HAL_timer_get_count(STEP_TIMER_NUM) + hal_timer_t((HAL_TICKS_PER_US) * 8); // ISR never takes more than 1ms, so this sh

TIMER = 100, so HAL_timer_get_count() return 100. We add hal_timer_t((HAL_TICKS_PER_US) * 8);

so now min_ticks = 100 + 2*8 = 116

next_isr_ticks equals 116 (due to near pulses of extruder and steppers)

2] So, the loop breaks, and we return from Stepper::isr_scheduler with a value of 116.

At this point, the timer has increased, in lets estimate, 2 counts (16 instructions), so its value is 102

Then, at HAL_STEP_TIMER_ISR,

  // Set the next ISR to fire at the proper time
  HAL_timer_set_compare(STEP_TIMER_NUM, ticks);

The compare value is set and we return from the subroutine ISR. That takes about 60 instructions. So, the timer incremented 60/8 = 7 extra counts. At the end of the interrupt, the timer value is equal to 102 + 7 = 109.

This is perfectly fine, as the compare value we set was 116,

Now, the 2nd scenario:

It is exactly the same, but assume that between 1] and 2] a Serial interrupt fires. And it is perfectly possible, as interrupts are enabled at that point. Let´s assume the Serial interrupt takes 100 cycles to complete: That is about 120/8 = 15 timer counts.

So, in 2] the timer value is now 117. We program the compare value of 116 we estimated previously and return from the stepper ISR.

The result is that we need to wait a full wraparound (30mS in AVR or 4 minutes on ARM) to be called again!

Granted, this is not common at all, but also it is not impossible for it to happen. When I read that there was a layer shift after 10 hours of printing, or about 36 millions of Stepper ISRs (assuming 1khz medium period value) them, the "nearly impossible" becomes "more than likely"

And... What if more than 1 isr between 1] and 2] ? .. Also possible with serial usarts combined with an endstop, or maybe beeper, or another interrupt source.

Hope you are able to see that "nearly no chance of happening" multiplied by long running times makes unlikely likely.

We don´t need continuous stuttering, just 30mS of sudden "nothing" is more than enough to skip steps if the axis are moving...

[thinkyhead]

Then I would expect Marlin 1.1.8 to exhibit the same stuttering. I think it will be important to verify any theory by direct experiment. Use a bare board, add a pin toggle at the end of the ISR when setting up the compare, and observe with an oscilloscope.

[AcHub]

I'm currently printing something without auto bed leveling (disabled with M420 S0) and it gives me the impression that it has less stuttering on travel moves, but it still isn't totally smooth. Also stuttering seems to occour in phases - it moves smooth a few times, then it rattles again. Do you think it is necessary to reflash marlin with auto bed leveling commented out to securely disable it? (Wasn't there an issue concerning linear advance where disabling by Gcode didn't work?) I'll do an extra testprint next with more pronounced travel moves to see if there is a clear difference between the prints with/without auto bed leveling.

[thinkyhead]

Do you think it is necessary to reflash marlin with auto bed leveling commented out to securely disable it?

I doubt it would help. This issue seems to be endemic to all moves above typical print speeds.

[ikarisan]

@ejtagle and @thinkyhead Sorry for the late answer, I was on vacation. Yes, it happens on fast X/Y moves without E involved. The move from the end of the prime line to the point where the print starts is done by "G1 X81.935 Y80.935 F7200".

[boelle]

@Pyro-Fox is this fixed with latest bugfix 2.0?

[Pyro-Fox]

@boelle Correct. I haven't seen any stuttering like this in a while. IIRC it was an issue with the lookahead combined with linear advance or something like that.

[boelle]

@Pyro-Fox so maybe click the green close button below?

[Pyro-Fox]

Sorry I thought it was closed already.

[zalexzperez]

Well, I'm also experiencing stutterings on travel moves starting from 7200mm/min, especially on the X axis (3 or 4 microstops) instead of 1 microstop on the Y axis.

I'm running a modded Ender-3 with: echo:Marlin bugfix-2.0.x echo: Last Updated: 2019-09-06 with TMC2208 on X and Y axis.

The problem seems to be related directly with Bed leveling. When it's off or near the Fade Height's upper limit, the stuttering is gone.

https://youtu.be/8ntgTnDI9bY (travel speed was 9000mm/min here) Is this normal? It's limiting my travel limit speeds to around 120mm/s Thanks

[PrintEngineering]

I just want to add that S_CURVE_ACCELERATION also causes this issue to manifest, and hopefully get notified when it is fixed. I'm running 2.0.5.3

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