MCU Stepper too far in the past shutdown

General Discussion
1

Basic Information:

Printer Model: Creality Ender 3 S1 Pro
MCU / Printerboard: Creality Sonic Pad
klippy.log

Describe your issue: Twice now I have had a perfectly good print fail due to an MCU shutdown due to “stepper too far in the past”. Last one was very painful, a gift for my wife that was running a perfect print for over 12 hours and 95% complete. Seemed to happen on a layer change. I note that this never happened before (I’ve only been running klipper on the sonic pad for about a month but using it heavily every day for that period), until a couple of days ago I started trying to print smaller extrusion widths. This latest run that failed was on a 0.3mm nozzle running mostly default settings.

Researching what can cause this issue is yielding very unhelpful results. My microsteps are already 16. My PA value was not excessively high, in fact it’s rather low (0.04).

Any help would be greatly appreciated. Not willing to run any more long prints only to have them die due to this issue.

EDIT: One other noteworthy thing is that previously, I always had Prusa Slicer doing acceleration control. I recently disabled that and let klipper handle acceleration settings because the faster accelerations pretty much completely eliminate PETG stringing for me. I have not made significant changes to my printer.cfg though.

klippy.log (1.3 MB)

2

This doesn’t appear to be a Klipper log.

3

Urf. Unfortunately it’s the only log file that this Creatity Sonic Pad interface has provided me. I thought that would be it. I do not yet have filesystem access to it, only their front end interface.

Given that providing a klipper.log is problematic for the time being - and not going to be resolvable soon as I am about to go on vacation tomorrow for a week, I will provide my printer.cfg. Hopefully that is enough? Other than my calibrating e-steps, really haven’t modified it much from the stock settings for my printer.

printer.cfg (7.6 KB)

4

The config isn’t really helpful. If that’s the only log you have access to, then Creality is probably using a forked version of Klipper. If that’s the case I can’t offer help. You will need to contact Creality. I see a few other people posting this same issue and no resolution.

5

I did some searching on the Klipper Discord where I’m a helper, and confirmed that Creality did in fact fork Klipper. Unfortunately that means we can’t help. We have no way of knowing what Creality modified.

6

Sigh. I appreciate your taking the time to check. Unfortunately the creality forums are really limited, and as I noted general internet searches for the causes of this error are very unhelpful. Guess I’m kinda screwed.

7

(The annoying thing is I was running this print on 0.3mm nozzle and extrusion widths, 0.16 layer height, at frikkin’ 35% of default Prusa slicer speeds. The idea that I was exceeding some sort of machine limit seems ridiculous to me)

8

It’s unfortunate that they took this path, and they’re likely violating the GPL with this product. The general recommendation on the Discord is to avoid this product. Hopefully you can get this resolved, or maybe your money back from Creality.

9

I’ve had similar issue with really long and/or fast moves.

Do you have any really long/fast moves on x, y, z, or e?

My z board would flip out if I tried to move the gantry from z0 to z400mm in one step.

Klippy.log will be needed to confirm, but my issues was the pi could not calculate fast enough for fast stepper moves over a 400mm length and a 2mm pitch z-screws.

I used to run a arduino MEGA on a 1gb pi. Now I’m using a Adafruit Metro M4 @ 200mhz and a Odroid X4U with 4gb.

Swapping the pi for the Odroid really helped after changing micro steps to 16, slowing down the fast moves and multiple moves to lift the gantry.

10

Hello. Sorry for the slow reply, I was away for the last week.

When I contacted Creality, they advised to try switching USB cables. Since I had switched the USB cable not long before getting this error, I switched back to the USB cable they had originally sent me, and tried it again. The print died in the exact same spot, 52 layers in out of 56, with the exact same error. At that point, I do have to assume there is some movement in the gcode that is causing the problem but I lack the skills to identify it. It seems to be happening right at the layer change to 52.

I’m going to post two snippets of gcode, right around the layer change to 51 (which had a color change, and which went fine) for comparison, and then right around the change to layer 52 which is where it’s breaking down, possibly on the wipe movement? I’m hoping someone around here can possibly see if there’s something obviously and egregiously wrong here, because comparing the two snippets, I’m not spotting it…

Layer 51 - color change. This worked fine, like the previous 50 layers. Providing only for comparison.

G1 E-.8 F1800
G1 X46.483 Y128.387 F9000
G1 E.8 F1800
G1 F2400
G1 X43.993 Y130.876 E.0671
G1 X43.811 Y130.935 E.00365
G1 X43.228 Y131.346 E.0136
G1 X43.11 Y131.53 E.00415
G1 X43.005 Y131.793 E.00541
G1 X43 Y131.87 E.00146
G1 X41.747 Y133.123 E.03378
G1 X42.054 Y132.389 E.01517
G1 X46.273 Y128.17 E.1137
G1 X46.168 Y127.849 E.00645
G1 X42.501 Y131.516 E.09885
G1 X42.754 Y131.041 E.01026
G1 X43.074 Y130.517 E.01171
G1 X46.064 Y127.527 E.08059
G1 X45.959 Y127.205 E.00645
G1 X43.829 Y129.334 E.0574
G1 X44.783 Y127.954 E.03198
G1 X45.96 Y126.777 E.03172
; stop printing object Articulated_Monarch_3_Layers.stl id:0 copy 0
;LAYER_CHANGE
;Z:8.2
;HEIGHT:0.16
;BEFORE_LAYER_CHANGE
G92 E0
;8.2

;WIPE_START
G1 F7200
G1 X44.783 Y127.954 E-.39532
G1 X43.91 Y129.217 E-.36468
;WIPE_END
G1 E-.04 F1800
G1 Z8.2 F9000
;AFTER_LAYER_CHANGE
;8.2
;COLOR_CHANGE,T0,#FFFFFF
M600
; printing object Articulated_Monarch_3_Layers.stl id:0 copy 0
G1 E-.8 F1800
G1 X47.135 Y128.182 F9000
G1 X48.932 Y127.605
G1 X50.972 Y126.951
G1 X76.092 Y118.878
G1 X75.972 Y118.926
G1 E.8 F1800
;TYPE:Perimeter
;WIDTH:0.329999
G1 F1500
G1 X73.261 Y119.036 E.05069

End Layer 51 snippet

Layer 52 - MCU stepper error happens around here

;WIDTH:0.340058
G1 F2400
G1 X158.448 Y137.256 E.00949
G1 X158.357 Y137.597 E.00682
G1 X157.826 Y137.065 E.01452
G1 X157.427 Y137.099 E.00773
G1 X158.266 Y137.938 E.02292
G1 X158.174 Y138.279 E.00682
G1 X157.026 Y137.13 E.03139
G1 X156.594 Y137.131 E.00833
G1 X158.083 Y138.62 E.04068
G1 X157.992 Y138.961 E.00682
G1 X156.163 Y137.132 E.04996
G1 X155.732 Y137.133 E.00833
G1 X157.9 Y139.302 E.05925
G1 X157.809 Y139.643 E.00682
G1 X155.3 Y137.134 E.06854
G1 X154.866 Y137.133 E.00838
G1 X157.718 Y139.984 E.0779
G1 X157.626 Y140.325 E.00682
G1 X154.455 Y137.154 E.08663
G1 X154.38 Y137.511 E.00704
G1 X157.166 Y140.297 E.07614
G1 X156.625 Y140.188 E.01068
G1 X154.304 Y137.867 E.06341
G1 X154.228 Y138.224 E.00704
G1 X156.083 Y140.079 E.05068
G1 X155.534 Y139.962 E.01085
G1 X154.152 Y138.58 E.03774
G1 X154.076 Y138.937 E.00704
G1 X154.971 Y139.832 E.02444
G1 X154.409 Y139.701 E.01115
G1 X153.888 Y139.181 E.01421
; stop printing object Articulated_Monarch_3_Layers.stl id:0 copy 0
;LAYER_CHANGE
;Z:8.36
;HEIGHT:0.16
;BEFORE_LAYER_CHANGE
G92 E0
;8.36

;WIPE_START
G1 F7200
G1 X154.409 Y139.701 E-.1747
G1 X154.971 Y139.832 E-.13713
G1 X154.076 Y138.937 E-.3005
G1 X154.152 Y138.58 E-.08658
G1 X154.334 Y138.762 E-.0611
;WIPE_END
G1 E-.04 F1800
G1 Z8.36 F9000
;AFTER_LAYER_CHANGE
;8.36
; printing object Articulated_Monarch_3_Layers.stl id:0 copy 0
G1 X153.333 Y138.509
G1 X151.502 Y138.045
G1 X145.511 Y136.529
G1 X143.675 Y136.064
G1 X138.184 Y134.674
G1 X136.44 Y134.233
G1 X134.538 Y133.751
G1 X117.445 Y129.424
G1 X115.115 Y127.635
G1 X111.53 Y122.902
G1 X111.196 Y122.279
G1 X110.705 Y122.213
G1 X109.65 Y122.253
G1 X109.646 Y122.254
G1 X109.351 Y122.308
G1 X109.163 Y122.454

11

Hmmm… seeing that long list of X-Y movements with no extrusion at the end there, I am guessing those are the result of “Avoid Crossing Perimeters” setting in Prusa, which I have seen it send the extruder crazily fast in a zig zag pattern over large sections of this print. I’m guessing all that movement may just be too much to send at once. I’m going to disable that setting and try it again. I’ll let you know if that winds up resolving it.

12

You also have a F9000 feed rate in there too. It is applied to some Extruder load/unload as well as that last block of X/Y moves.

As you said, a large quantity of small moves plus the high fees rate together can cause issues.

I recently wrote a config document related to an single hot end / multi extruder setup. Mainly focusing on SuperSlicer setup. I break down the tool change by g-code and settings. It might be beneficial to take a look at it and adjust some other settings.

https://klipper.discourse.group/t/x-in-1-out-non-mixing-extruder-automate-superslicer-filament-swaps

13

ARGH. Another 11 hour perfect print that died from the same error at the same point, and I double checked and made sure all of those x-y moves from avoiding perimeters were gone.

There’s hundreds of these F9000 feed rates all over this gcode, that almost seems to be the default, and it did 51 layers successfully with them. If that is excessive and unnecessarily high, how do I change it? Any idea where I might find that in either printer.cfg or PrusaSlicer settings? Thanks tons for any help. Looks like I won’t be able to give my granddaughter a butterfly for Christmas :frowning:

EDIT: Looking through your document, sorry, should’ve done that before asking, just in a rush. A bit hard to piece through as I only have a single extruder, but trying to find what would collerate to that feed rate. I am still a klipper noob so if you can point it out I’d appreciate it, but I should find it eventually. Thanks for it kindly.

14

This, by the way, is the new gcode with the “Avoid Crossing Perimeters” turned off, around the culprit layer change. Still died exactly the same way as before.

G1 X154.228 Y138.224 E.00675
G1 X156.083 Y140.079 E.04855
G1 X155.534 Y139.962 E.0104
G1 X154.152 Y138.58 E.03615
G1 X154.076 Y138.937 E.00675
G1 X154.971 Y139.832 E.02342
G1 X154.409 Y139.701 E.01069
G1 X153.888 Y139.181 E.01361
; stop printing object Articulated_Monarch_3_Layers.stl id:0 copy 0
;LAYER_CHANGE
;Z:8.36
;HEIGHT:0.16
;BEFORE_LAYER_CHANGE
G92 E0
;8.36

;WIPE_START
G1 F7200
G1 X154.409 Y139.701 E-.1747
G1 X154.971 Y139.832 E-.13713
G1 X154.076 Y138.937 E-.3005
G1 X154.152 Y138.58 E-.08658
G1 X154.334 Y138.762 E-.0611
;WIPE_END
G1 E-.04 F1800
G1 Z8.36 F9000
;AFTER_LAYER_CHANGE
;8.36
; printing object Articulated_Monarch_3_Layers.stl id:0 copy 0
G1 X75.972 Y118.926
G1 E.8 F1800
;TYPE:Perimeter
;WIDTH:0.329999
G1 F1500
G1 X73.261 Y119.036 E.04856
G1 X73.137 Y118.253 E.0142
G1 X75.791 Y118.225 E.0475
G1 X75.854 Y118.824 E.01077
G1 X75.938 Y118.896 E.00199
;WIPE_START
G1 F7200
G1 X73.261 Y119.036 E-.6366
G1 X73.18 Y118.523 E-.1234
;WIPE_END
G1 E-.04 F1800
G1 X73.59 Y118.635 F9000
G1 E.8 F1800

15

Looks like the F9000 is on some Z only moves along with some X/Y moves.

Post a screen shot of your slicer settings from “printer Settings → Speed”

I’d also check settings for filament unload/load under “ Filament Settings → Multimaterial”. Feel free to post those settings too.

16

image
image453×939 14.1 KB

Note that I was adjusting the speed down to 60% of these values at the tablet.

17

I’m using Prusa and don’t have “Filament Settings → Multimaterial” section, but I suspect the following is the equivalent? I will note that I am using the standard M600 macro to do a filament change at the beginning of this layer, but the error doesn’t happen until the end of the layer. Related?

image
image660×721 13.4 KB

18

Okay, I just noticed something interesting. This is the actual print (monarch butterfly). The white is a single layer, and the error is occurring at what I thought was the very end of this first white layer. The white starts printing on the left wing and finishes on to the right, and since the white pattern is symmetrical, it certainly is happening very close to the end of the layer. But where it dies is at the top of the 3rd section from the right on the right wing (sorry for bad rotation, make that third section from the bottom). Next post will be a closeup of that spot.

20221218_2337052494
20221218_23370524941512×2016 251 KB

19

Looks like it isn’t quite actually finished laying the layer down when it dies and then leaves a dollop at the spot where it stops. There’s still a tiny triangle left to go. Is the gcode being “read ahead” to the layer change and dying when it finds the error? Or is it likely that it’s actually dying on gcode that happens just a few seconds before the layer change?

20221218_2337152493
20221218_23371524931512×2016 93.5 KB

(BTW, yes, I do plan on increasing “Infill/Perimeters Overlap” from 23% to 50% on the next run.)

20

I’ll take a better look at this when I get to my home PC that I slice with.

Are you printing this in PETG? I’m only asking because I have different speed setting for PET over PLA.

My understanding of Klipper is it queues a a few moves in the “motion queue” before execution. I’d expect that the MCU is failing on executed g-code, not queued g-code.

What version of Prusa Slicer are you using?
What “Pi” model do you have?
What is the printer main controller?