Have you every have these weird blobs randomly on the surface of your prints?
Stefan from CNC Kitchenshowed us how I fixed this problem with a slicer setting.
How I was able to get rid of these blobs on the surface of the U30 Pro prints? You often see these printing artifacts at the location where the printing move of a perimeter ends, and the build-up pressure in the extrusion system pushes more material out of the nozzle. Before that pressure is relieved by the retraction move.
This is mostly fixed by coasting, wiping or higher retractions though in the case where I noticed it, it was on a vase where the wall was printed in a spiral, so theoretically at a constant speed of the print head without any retractions or similar.
Upon closer inspection, I noticed that in reality, though the print head stuttered from time to time, where again, the built-up pressure in the bowden extrusion system lead to the blobs.
The G-Code also didn’t show any real problems or backwards moves especially since the model is a really nice and smooth vase. But here’s actually the problem because during slicing each of the facets will be translated into one linear move, resulting in a lot of very small motions.
I know a similar problem form my CNC router because it also can’t reach its full speed and starts stuttering. If the individual moves are too small and have even seen it happening with Octoprint that wasn’t able to stream movement commands fast enough for gyroid infill.
The mainboard is not able to handle reading or receiving and processing the individual commands fast enough. So at some point, the machine starts to slow down and, in this case, extrudes a little wider due to the pressure in the system.
For the print quality of a Bowden Extruder 3D printer, it would be optimal, if the material feeddrate would always be constant. Direct extruders are a bit better in that regard.
To be honest, this shouldn’t happen nowadays with a printer and the moves are not horribly tiny and also, the Ender 3 prints the same G-Code fla wless.
Regardless of that fact I’m now going to show you how I simply fixed that problem with a quite unknown slicer setting.
So what CURA and also most other slicers offer is a resolution setting.
This setting, which doesn’t always work the same basically merges individual moves into one. If they are below a specified length, effectively reducing the size of the G-Code file and making moves more smoothly.
In order to see this setting in CURA, select the gear icon, scroll to "mesh fixes", and activate “maximum resolution” and “maximum deviation”.
The tooltip already says that this is to help that the printer can keep up the speed.
Maximum resolution defines the minimum length of a line segment. Maximum deviation, the maximum error that is allowed by this simplification.
This means that CURA tries to merge segments, if they are smaller than the defined value.
But if the geometrical difference would get bigger than the defined deviation, it will also allow smaller print moves. For the Ender 3 profile and many other predefined CURA profiles these were all set to 0.05mm, which is for deviation, an okay value but for the resolution pretty small.
In the worst case, this would mean that a printer running at 60mm/s, would need to process up to 1200 commands per second, which will definitely overload the processor, at least the old 8bit ones.
Though looking at the Ultimaker 3 profile for example showed me that they were using a maximum resolution 10 times as big, the Ultimaker 5S even sets it to 0.7mm!
How does that change the G-Code?
I sliced Buddy once with the stock 0.05mm resolution and once at the resolution that the Ultimaker 3 also uses which is 0.5mm.
I loaded the G-Code into Excel and with some formula magic calculated the length of each print move and plotted in a histogram.
All in all I analyzed around 10000 lines and the bars. Now it shows us how many print moves have a length in a specific range. For example 0.12 to 0.14mm or 0.4 to 0.42mm.
For the baseline G-Code we see that most print moves really have a quite small length, again, especially because the model itself was really fine to begin with.
It peaks at around 0.16mm.
There is also by the way a small, individual peak at the side and can you guess what that is? It’s our wipe distance of 0.4mm. Pretty cool.
When we take a look at the histogram of the G-Code sliced with 0.5mm resolution, we can see that the peak has moved from 0.16mm to the assigned 0.5mm.
We still have some smaller print moves remaining due to our maximum deviation criterion. Still I think we were able to remove quite a lot of small print moves which is also visible in the file size of the G-Code but in the end, the proof of the pudding is in the eating or rather here, the printing of the G-Code.
And really, the print moves at the vase are totally smooth and so is the printing result. And also all of the zits on Buddy are gone, so we’ve really succeeded.
This might slightly alter the dimensions of the model, so don’t use values too high, especially for deviation. In my case, I couldn’t see a negative impact on print quality with the 0.5mm value that I used.
The guys from Ultimaker also probably had a reason to use it.
This is definitely not the solution of all of your printing problems and might in this case really be more evident because the firmware of the Alfawise seems to be acting up a little, but if you have strange phenomena during printing and notice that the moves are not smooth, try playing around with that parameter and you might be surprised about the results!
Let me know in the comments if you’ve ever noticed and played around with this setting, and if so, what your results were and which values you can recommend!