Ender 5 Plus - Micropausing Creality Silent Board 2.2.1

[diddlyuk]

When using the lastast DWIN 6.2 firmware, i have noticed that there are micropauses on complex shapes causing a popcorn like surface. I have tested with and without octoprint, adjusted all accelleration and jerk settings to match the stock firmware, and run the same GCODE on stock firmware to confirm there is no issue.

Load screen files and DWIN 6.2 onto an Ender 5 Plus with Silent board. Load GCODE of 30mb+, print.

1. [First Step]
2. [Second Step]
3. [and so on...]

Expected behavior: [What you expect to happen]

Actual behavior: [What actually happens]

Additional Information

• Include a ZIP file containing your Configuration.h and Configuration_adv.h files.
• Provide pictures or links to videos that clearly demonstrate the issue.
• See How Can I Contribute for additional guidelines.

[diddlyuk]

Update on this - its not just large files, its when doing any curve, im printing at 40mm/s and its still stuttering. I believe this is because of the real-time XY being output to the screen. Any way if disabling this so i can test?

[chunter1]

I guess it's the same issue we saw in this thread here and made me finally switch to Klipper Firmware (and am happy since then ;) )
#134 (comment)

[diddlyuk]

I guess it's the same issue we saw in this thread here and made me finally switch to Klipper Firmware (and am happy since then ;) )
#134 (comment)

I just enabled Lowmemoryboard and disabled the XY on the screen, still no change. I didnt think Klipper worked with the standard creality board?

Also says that junction deviation caused that issue but i've compiled my own with it disabled and have the same issue

[DarkZed1]

I am also having this issue

[quarky42]

I think this is an old thread, but I had an idea, so in case it helps:

What is your slicer set to in terms of max allowable deviation / smallest segment size? (These values have different names in different slicers but basically it is how much the slicer is allowed to deviate the line in order to reduce the complexity of moves.) One possibility (Thanks to CNC Kitchen's YT Channel where he has a video talking about this very topic) is that the defaults for the slicer are simply too aggressive and needs to be turned down a little bit. You'll never notice the "error" but the amount of commands per second trying to be processed by the controller will be much more sane.

There is an alternative that also can achieve this same sort of goal AND it may have some other benefits as well. Check out Arc Welder. It is a standalone program or there is even a plugin version for Cura. It does the same kind of thing as far as simplifying the GCode, but it uses arcs instead straight line moves. The arcs take up a lot fewer gcode lines and can greatly reduce the file size and ergo greatly reduce the number of commands per second being processed.

The controller can "bog down" if the commands per second is above some threshold. Some people switch to Klipper because a lot of the processing is offloaded to a Raspberry PI (or similar) microcomputer leaving the controller processing to be a lot less. I've been playing with Arc Welder and Slicer Settings a bit and have seen a great improvement in the kind of stuttering / zits you're talking about by going this route. My SKR board can handle a lot more processing / commands than the Creality board could, but even then I'm noticing smoother prints by using arcs and a little bit larger allowable deviation in the slicer.

[diddlyuk]

Hey, sorry I forgot about this. The fix was to lower the resolution in cura but I went back to standard firmware as I can achieve higher resolution prints.

[quarky42]

What you experienced definitely wasn't normal. Glad it's working well for you now. That resolution thing in Cura is still worth messing with and so is that Arc Welder because the kind of deviation we're talking about is miniscule, but it can have a huge effect on the work-load of the controller. After playing with Arc Welder a bit, I really love it. The curves come out a lot smoother, the steppers run smoother / sound better.

[diddlyuk]

Thanks dude, I've stopped printing for a bit until the weather picks up so I can finish them in the workshop but I'll keep this in mind and have another go

[InsanityAutomation]

Some effort went into reducing ram usage for the refactored file handling. Given that more can likely be allocated to the buffers on some of these machines which can help with this type of issue.

This is definitely a multifaceted issue with many possible causes and resolutions.

Disabling Junction Deviation
Utilizing Arc Welder
Lowering slicer curve resolution
Increased buffer size
Increased baud rate

[InsanityAutomation]

Good chance this is what was actually causing some of what was seen... MarlinFirmware#25338 - Upstream issue around since Sprintr that could be triggered just based on how timing landed.