MCU Stepper too far in the past shutdown

Yes re: PETG. Been dialing these settings in for months for it. I know the white layer on that model looks badly underextruded, and I’ll have to figure out how to fix that… but check out the red layers below. Printing with pretty much zero stringing or blobbing.

Prusa Slicer v2.5.0+win64 Build 202209060714

Not using a Pi - using a Creality Sonic Pad. Therefore not sure how to answer those last two questions.

I’m not familiar with the Creality Sonic Pad, nor the limits of your printer, but I’ll offer some suggestions that work well on my CoreXY printing PETG.

Typically, I only set speeds in the slicer letting Klipper control Acceleration, but in my PETG profile, I’m controlling both. PETG likes it hot and slow with limited cooling.

Here is what I see thus far:
Printer Ender 3 S1 Pro - It’s a 220mm x 220mm bed slinger -
Creallity Sonice Pad looks to be an all-in-one touch display with some sort of “Pi” comparable SBC running Klipper, Moonraker, and Fluidd.

I looked at your printer.cfg that you provided and I was interested in the [printer] section:

[printer]
kinematics: cartesian
max_velocity: 300
max_accel: 5000
max_z_velocity: 10
max_z_accel: 1000
square_corner_velocity: 5.0

Without fully diving into the hardware, these accel values look a little high. This could contributing to your issue from my experience, but again, hardware configuration plays a big factor.

Questions: How is the z-movement controlled (hardware)? specifically, is the gantry belted or is there a lead screw? Is there only one drive for the gantry or do you have stepper motors on both sides (less of a concern)?

Also, the max_accel value of 5000 looks very high, especially for a bed slinger. Although this Creality printer looks to be more rigid than my Anet A8 (yes, I still have one) and even my CoreXY.

I would probably 1/2 them to:
max_accel: 2500
max_z_accel: 500

We can control some of this in the Slicer and once we have something working, can later translate it to Klipper commands.

PETG Speeds:
Here is what I’m using:
Perimeters: 40
Small Perimeters: 25
External Perimeters: 30
Infill: 80 (you can yield to the slower speed you have here)
Solid Infill: 80 (you can yield to the slower speed you have here)
Top Solid Infill: 40
Support: 40
Bridge: 30

Travel: 180 (I would lower yours down to 120 due to increasing mass on the build plate/y-axis)
Z-travel: 0

First Layer: 20

Acceleration control - Here is were we will set some limits for you, which we can translate into Klipper commands later:
Perimeter Acceleration: 1500
Infill: 0 = default of 2000
Bridge: 2000
First Layer: 1000
First Object Layer over Raft: 1000 (should not matter for you here)
Default: 2000

Max Print Speed: 50-60

To provide some context -
I have a CoreXY with a fixed bed. The entire gantry moves in the Z-direction. I also have very fine lead screws driving the z-direction at 2mm pitch (typically 8mm is used). due to the fine pitch, which requires Klipper to calculate and provide the MCU with many moves, a high acceleration caused the same issue. I had to limit my acceleration down due to hardware, but overall, the speed is similar.

Also, in your filament change area, you can modify the speeds as such:
Loading speed at start: 3
Loading speed: 18
Unloading speed at start: 80
Unloading speed: 80
Number of cooling moves: 1

Next, unload your filament, slice, and print without filament. After printing starts, you can turn off your bed heater and lower your hot-end to about 200C.

That will let you know if the issue persists or not. If an unloaded printer is successful, load up your filament and print with the same g-code again.

If you have a filament run our sensor, you may have to disable it, or put in a small piece of filament to trigger it, but not load it to the gears of the extruder.

Thanks for the awesome tips - I look forward to deep diving on them. And GMTA - I had just slowed down my max acceleration to 3000 in printer.cfg cause the jerking it was causing was a bit too violent for my tastes. Now Prusa was by default setting the accel to 500, which was excessively slow. When I disabled that, and let the 5000 klipper setting take over, stringing completely disappeared, it was pretty damn amazing. But as I said, just now I lowered it to 3000 and that still appears adequate to eliminate stringing, and it took the edge off the violent jerking. I didn’t spot the z-axis accel though, and I’ll definitely try setting it to 500.

I do appear to have lead screws and z-axis steppers on both sides of the gantry.

You’re correct on what the Creality Pad does, uses and runs. The UI - both on the tablet itself and on the WebGUI provided if you connect to it via LAN - is actually excellent IMO, far better than the stock firmware that the printer came with. Not sure how much of that UI is native to klipper and how much is custom to the Sonic Pad itself, as this is my first experience with klipper.

Now, since the last time I posted, I discovered this thread on Reddit. I’m not the only one having this issue, and it may actually have nothing to do with what’s in the gcode at all (other than the fact that I think having lots of small patterened and irregular pieces of print to do is taxing the CPU).

Here are my takeaways from that thread:

  1. Changing the USB cable (in my case, switching back to the cable provided with the pad), as Creality recommended, has not helped anyone resolve the issue.
  2. A couple of people have stated that they do not experience the issue with their various Creality printers’ stock firmware.
  3. A couple of people have pointed out that no one experienced this issue until after the last pad software update.
  4. A couple of people have claimed that unplugging/disabling the camera resolved the issue. I have not had a chance to test this yet (it requires 13 hours for me to get to the point in the print that I experience it consistently).

My guess is the error is due to an overtaxed CPU, and turning off the timelapse camera recording frees up enough CPU resources to handle the requests. It’s notable that the error only occurs once the pattern gets irregular with lots of small sections.

So, with the camera unplugged, I’m currently about 22 hours into a 32 hour print that hasn’t experienced the issue yet (crossing fingers, it will SUCK if this dies). Afterwards, I intend to run the butterfly again.

Incidentally, my current settings are giving me some pretty spectacular results. This is the desk organizer I’m currently printing at 100% Prusa speeds so far, at about 18 hours in:

Still PETG. 0.16mm layer height and 0.3mm nozzle. And not a single string or blob I can see since the 3rd layer. This is about 120 layers in.

I will definitely try out your settings when I have a little more time. Thanks again for it, I’ll be bookmarking this thread forever even if I get the original issue resolved, heh.

Yep. Disabling the camera in settings and unplugging it eliminated the MCU error. I’ve been in touch with Creality about it and they say they’ll fix it in their “DEC update”, so should be soon.

Thanks again to everyone in this thread that tried to lend a hand or otherwise gave advice, much appreciated. I still plan on using your suggestions, jjarosz, as it all seems good advice to me, even if they’re not necessary to solve this issue.

For the record, this is what I was going for. So happy I got it done in time to give it to granddaughter for a Christmas present (I’ll make another for my wife after our visit with them):

3 Likes

@Qwinn Looks good!

For your reference, Klipper config for the Ender 3 S1 can be found here: klipper/printer-creality-ender3-s1-2021.cfg at master · Klipper3d/klipper · GitHub

The basic config for the S1 [printer] section provided is:

[printer]
kinematics: cartesian
max_velocity: 300
max_accel: 2000
max_z_velocity: 5
max_z_accel: 100

This is vastly different than what you are currently using. Adjusting this should allow you to use both camera and printer together.