[BUG] 2.1.2 Stepper motor stutters and skips at high speed due to new ISR calculation

[ansonl]

See latest post at bottom for better summary and narrowed down bug in stepper.h and stepper.cpp.

Did you test the latest bugfix-2.1.x code?

Yes, and the problem still exists.

Bug Description

Marlin no longer properly offsets the printhead on a toolchange between switching nozzles that have a X offset between them.

#define HOTEND_OFFSET_X { 0.0, 19.00 } // (mm) relative X-offset for each nozzle
//#define HOTEND_OFFSET_Y { 0.0, 0.00 }  // (mm) relative Y-offset for each nozzle
#define HOTEND_OFFSET_Z { 0.0, -2 }      // (mm) relative Z-offset for each nozzle

#define EVENT_GCODE_TOOLCHANGE_T0 "G90\nG0 X210 F7200\nG0 Y165\nG0 X216\nG0 X216 Y183\nG0 X210" // Extra G-code to run while executing tool-change command T0
#define EVENT_GCODE_TOOLCHANGE_T1 "G0 X229 F7200\nG0 Y199\nG0 X234\nG0 Y184\nG0 X229" // Extra G-code to run while executing tool-change command T1

When Marlin switches to a tool T1 with a positive X offset it will move the printhead quickly in the negative X direction and return to the original position before running EVENT_GCODE_TOOLCHANGE_T1 to complete the toolchange. The DXU mechanical switching nozzle mechanism has a lever on the right side of the printhead that moves to the bed limit X_BED_SIZE to touch a hook on the right side of the case which causes a nozzle lift/lower.

As of 2.1.2 Marlin no longer moves the toolhead in the negative X direction for the same distance as the "return" movement in the positive X direction before running EVENT_GCODE_TOOLCHANGE_T1. This leads to a printhead collision with the side of the gantry since the final X offset from before -> after the offset adjustment (but before EVENT_GCODE_TOOLCHANGE_T1) is no longer 0 or equal to the new HOTEND_OFFSET_X.

The last working commit I found was on 10/30/22 on PR #24553

The commit history for the PR can viewed here: https://github.com/MarlinFirmware/Marlin/pull/24553/commits I have taken a video of the correct toolchange and the new bug toolchange that is linked below for each test.

• 10/30/22 I updated the PR #24553 repo to be up to date with the main bugfix2.1.x repo. Tested to be working correctly.
• On 11/23 and 11/28 the same repo was updated to be up to date with main bugfix2.1.x repo. Tested both and they have a stepper motor failure when homing.
• On 12/19 I synced my own copy of the repo at https://github.com/ansonl/Marlin/tree/dondolotest to be updated with bugfix2.1.x to have 2.1.2 changes. Tested and stepper motor failure is gone. Toolchange offset adjustment does not work correctly.

As seen in the linked videos, the bugged toolchange initial offset adjustment does not move the full amount in negative X direction as it did in the correct toolchange. This seems to lead to the machine's real X position deviating from the software X position and it collides the side of the gantry.

The initial first toolchange from T0 -> T1 on both correct and bugged firmware does not have this problem when it is from the origin position right after homing. It is the second T0 -> T1 toolchange that this bug occurs in.

I found this bug while testing a version of PR#24553 synced to the current bugfix2.1.x and this PR has some additional definitions for Mechanical Switching nozzles and a bugfix in toolchange.cpp that prevents a bed collision. To my knowledge it doesn't modify the toolchange offset adjustment code.

Bug Timeline

New bug in 2.1.2

Expected behavior

Toolchange offset adjustment movements result in a final printhead offset equal to 0 or the HOTEND_OFFSET_X before running EVENT_GCODE_TOOLCHANGE_T1.

Actual behavior

Printhead runs into gantry when doing toolchange that is not from origin.

Steps to Reproduce

1. Setup #define HOTEND_OFFSET_X { 0.0, 19.00 } and toolchange gcode that moves that printhead to the right limit ex: if bed X size is 216, move X to 234 which is derived from 216+19 since the toolchange gcode is run from the offsets of the target hotend.
2. Home and move hotend so X position is < 19mm from right side of gantry limits.
3. Run toolchange between T0 and T1 repeatedly.
4. Printhead will collide with gantry limit due to first offset adjustment movement or offset adjustment not working correctly.

Version of Marlin Firmware

2.1.x

Printer model

Ultimaker Original+

Electronics

Ultimaker 2+ electronics

Add-ons

DXU hotend

Bed Leveling

MBL Manual Bed Leveling

Your Slicer

Cura

Host Software

OctoPrint

Don't forget to include

• [X] A ZIP file containing your Configuration.h and Configuration_adv.h.

Additional information & file uploads

Configuration.zip

[j-be]

I will give it a try on Friday.

[tombrazier]

The only thing I encountered is with linear advance stuttering as object is further from X=0. But don't know if it's related to this issue or should I file another one as AFAIR it also happened in 2.1.1.

Can you check with 2.1.1 please to be sure?

[er1z]

@tombrazier, confirmed, stuttering occurs on 2.1.1 as well (for what I plotted on the diagram).

[dc740]

I finally got time to test it. The situation improved a lot, BUT I still have missed steps when moving around the axis (specially on X axis).

(input shaping enabled for x and y and S-Curve disabled)

[dc740]

Sorry about the double post, but... is it possible that it skips steps because I didn't go through the IS calibration process?

[tombrazier]

is it possible that it skips steps because I didn't go through the IS calibration process?

I don't think so.

The situation improved a lot, BUT I still have missed steps when moving around the axis (specially on X axis).

Is this still only a problem at higher movement speeds? And how does it compare to 2.1.1?

I am in the process of further optimising the dynamic multi-stepping. So I think it ought to get even better soon.

[dc740]

2.1.1 was/is rock solid. But again, 2.1.1 was with S-Curve enabled. I will test S-Curve (instead of IS) as soon as possible, but I only got time to test IS so far.

[j-be]

@tombrazier Tested your branch with my config, extruder still broken with LinearAdvance and K=2.3. My config can be found here.

TL;DR: Bowden setup with Voron M4 (ESteps=565), LinearAdvance and SCurve. Extruder retracts more than it pushes forward, hence no material is coming out of the nozzle.

[dc740]

I just retested your branch (I pulled your latest changes again, there was a force push on that branch and I wanted to see what was there):

IS enabled: misses a few steps when the motor is slowing down (when there is inertia). Starts and speed ups are fine though.

S-Curve enabled (NO linear advance, just S-Curve): works fine, very smooth and no missed steps even at the highest speeds.

config-tevo3d-mks_genL_1.3-SCurve.zip

[thinkyhead]

Please give LA another test with 2.1.2.1 and compare to the current bugfix-2.1.x (proceed with caution during the current motion refactors), and then we can also try reverting some of the changes from #25541 and #24533 to see if they have any effect. I can create a branch with partial reversions for testing, if needed, to help isolate specific changes.

[dc740]

I tested 2.1.2.1 and bugfix-2.1.x (yesterday's checkout). But I'm still tuning it

2.1.2.1: general movement OK. I'm printing the IS calibration tower now. I have to reduce the extruder feedrate, but that can be explained by a runout sensor that I haven't tunned properly,so the extruder has to push harder. So, all in all, it seems OK.

bugfix-2.1.x: LOTS of grinding noises in all axes (not just the extruder). BUT I was able to print for two hours, and I can't see the missed steps. I'm thinking that maybe it was the extruder too, but it was way louder, and it happened more often too.

NOTE: This is all under review. I have issues with the extruder and the testing was not conclusive>

[dc740]

I can't get anything conclusive. It's like input shaping is disabled all times. (UPDATE: config attached below. IS + Lin Adv enabled)

Tried printing normally (80mm/s outer walls), tried printing too fast for my printer (outer walls at 200mm/s). I can't see any difference on the ringing tower height, and inspecting the gcode I see M593 commands, so the slicer (prusa slicer 2.6beta2) is inserting them just fine. Of course more speed == more artifacts on the print, but nothing changes with height. It's like input shaping is not doing anything when configuring it with M593.

After printing the ringing tower two more times, my results are the same as my previous comment: 2.1.2.1 does not skip steps (although I had to reduce the extruder feedrate to 5mm/s). bugfix-2.1.x has a lot of skipped steps, so the extruder feedrate needs to be set even slower.

I also tried the volumetric limit (enabling VOLUMETRIC_EXTRUDER_LIMIT). But they were completely ignored too. Tried enabling and disabling them through gcode. No changes at all. G0 E50 always outputs at the same speed. It only changes with F...., but no upper limit is applied to the feedrate. So I disabled the option after I was done testing. As it is, I'll revert to 2.1.1 for a couple of months to get the printer back in shape.

Printer details It's a Tevo Tornado. I changed the motherboard for an MKS Gen v1.4 + DRV8825 drivers with a fast decay mod and smoothers on all axis. The extruder is the stock one, but with a volcano hotend, and the only add-on on the carriage is the bed level thing, which is a Geeetech 3d touch pro v3.2. Finally, the hotbed does not have springs. It's fixed, so there is very little ringing on the Y axis. These mods work OK on 2.1.1 ;;;;;; Config and gcode attached Configuration.zip

[cbagwell]

@dc740 For what it's worth, when I tested input shaping + LA with a high K value then it messed with acceleration enough that I could not produce ringing either. Similar issue from my slicer (Cura) where minimum layer time of 10 seconds was reducing my feedrate enough to prevent ringing. Neither caused stepper noise though.

During tuning phase, you should have LA off and disable any slicer settings that slow down feedrate or acceleration to be able to produce ringing. Once tuned, you can re-enable LA and those settings.

What acceleration are you using? You'll need something high like 4000 but your config shows max of 2000 so max sure to increase both acceleration and max accelerations during tuning as well.

Finally, during your tuning, I suggest updating your Configuration_adv.h and uncommenting SHAPING_MIN_FREQ and set its value to what ever is the lowest frequency you're testing on your tower. If your board doesn't have enough memory, you will need to set the minimum to something like 20 and then update your tuning tower to start testing from that 20 frequency. Otherwise, there will not be enough buffers reserved and could cause lower parts of tower to look same as upper parts of tower.

[dc740]

Thanks for the tips. I couldn't get to the point of finding the sweet spot, but I had to revert back to 2.1.1. I don't know if it's the drivers, the fact that I'm using 1/32 stepping, or both. But I keep getting missed steps issues with the extruder. It's like the motors is not strong enough after the ISR got changed. Tried master (which is even worse) and 2.1.2.1. The extruder clearly misses steps and I have to reduce the speed A LOT to avoid them, and I really mean a lot, retractions are too slow, you can clearly see it takes a couple of seconds to get past a single retraction. Reverted back to 2.1.1 (and reverted the speeds) and everything is back to normal. I even enabled UBL and LA with the extra ram from not using IS. To be fair, the results are not as good, but I can finally stop fighting with the extruder speed.

I'd hook an oscilloscope to show the difference, but I don't have one anymore and I'm not planning to get a new one in the near future.

I'll leave the testing for someone with bigger micro steppings. It probably works on those configurations and I'll keep it in mind if I ever want to upgrade Marlin in the future. I was hitting the RAM limit (8k) already anyway and I could barely move through the menus when printing, so all in all I think I reached the best I can do with this board.Thank you all.

[ansonl]

I tested the latest bugfix2.1.x on my Atmega2560ext with A4988 stepper drivers with ADAPTIVE_STEP_SMOOTHING enabled, IS enabled, and MULTISTEPPING_LIMIT set to the default 16. It works well at lower speeds. I set the max feedrate to 300mm/s and it seems to self limit the speed to 250mm/s and acceleration even if those are set higher due to the MULTISTEPPING_LIMIT. Increasing the multistepping limit to 32 and running at high acceleration and feedrate like 9000mm/s2 and 300mm/s leads to lost steps.

[tombrazier]

Increasing the multistepping limit to 32 and running at high acceleration and feedrate like 9000mm/s2 and 300mm/s leads to lost steps.

That is what I would expect, which is why MULTISTEPPING_LIMIT was introduced. The A4988s don't go beyond 16x microstepping, if I remember correctly.

[er1z]

It looks like 2.1.2.1 is working much better, no stuttering noticed, so far. Needed to lower max speed (by 0,5 mm/s) of the extruder but finally works.

[dc740]

To those who got it working. Did you see the benefit? I modded my printer to test this better, set it to 1/16 microstepping to match the most common configuration, made a direct drive mount, calibrated Linear Advance, increased the acceleration above 5k and fired the IS test tower. The results were surprisingly disappointing. It can still be a problem with my printer, of course, but I didn't see the ringing reduced more than a small amount. I calibrated it to the best result I saw, which was at very low height, around 1cm from the bottom. The ringing was way more noticeable at the top, so I assume IS was doing something. The good news is that I don't see any missed steps anymore. (turns out I had a clogged barrel on my last 2 tests, before doing the conversion to direct extruding)

[tombrazier]

IS has had an incredible effect on my 12V bedslinger. I'm presently working on a sub 20 minute benchy and the limits are extrusion speed and cooling, not layer skipping.

But I did find that the test tower (which, in fairness, we stole borrowed from Klipper) mixes up the X and Y resonant frequencies. I have written a python script which generates a single layer test pattern that is much better (and faster and cheaper on filament). It's a bit rough and ready. You have to set one of freq_pattern, zeta_pattern_y or zeta_pattern_x to True and it will generate an appropriate pattern.

The freq_pattern script generates a gcode file that will draw X and Y lines with increasing frequency at right angles to the line. Pick the spot where the oscillations are largest (or layer skips are worst!) measure from the end of the line in mm. Divide by 2 (or whatever wavelength) is set to and that's your resonant frequency.

The other two scripts draw a set of lines with increasing zeta/damping values from 0.05 to 0.5 in increments of 0.05.

Yes, before you ask, this really ought to be added to the M593 gcode command. I will hopefully get round to it some day unless someone beats me to it. (I really hope someone beats me to it!)

[dc740]

Awesome. I can finally tune it properly! Your script was a game changer (of course I had to set the start g-code to my temps and machine setup). I can finally see the results.

Regarding the damping. The lowest damping gives me the best line on the X axis, but the Y axis shows bad results in all. Y damping X damping

Am I interpreting these correctly? This is with the new IS frequencies already in the firmware.

[tombrazier]

Sorry I didn't explain how to interpret the results. You want the zigzags to have about the same amplitude across the whole line. On Y that's about 6 lines from the bottom and on X it's quite close to the right.

On Sun, 30 Jul 2023, 14:12 Emilio Moretti, @.***> wrote:

Awesome. I can finally tune it properly! Your script was a game changer (of course I had to set the start g-code to my temps and machine setup). I can finally see the results.

Regarding the damping. The lowest damping gives me the best line on the X axis, but the Y axis shows bad results in all. Y damping [image: image] https://user-images.githubusercontent.com/546408/257052903-8ac1a27c-df01-4fd7-af22-409d540aaf52.png X damping [image: image] https://user-images.githubusercontent.com/546408/257053013-45d2dcdd-3be3-4b4e-a59f-05b5e27fb811.png

Am I interpreting these correctly? This is with the new IS frequencies already in the firmware.

— Reply to this email directly, view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/25117#issuecomment-1657160564, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQNZXQJ6NBXSVOJSVYTCRQ3XSZMSZANCNFSM6AAAAAATD6J3KI . You are receiving this because you were mentioned.Message ID: @.***>

[dc740]

Thank you. I'm not seeing issues on 2.1.2.1, but I haven't tried the bugfix branch and I ran out of time. I'll probably try it in some distant future again. My concerns regarding this particular ticket are over, but someone else may still have issues.

[tombrazier]

I think this issue is resolved. Anyone disagree?

[ellensp]

closing, if it turns out not to be resolved will reopen

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