Why does the slicer generate gcode the way it does?
Hello gentle folks - first time poster here...
I've been given a Prusa MK2S printer by my kids for my birthday three years ago and have been happily printing ever since.
One thing that amazes me every now and then is the rather unexpected way the slicer generates code for seemingly simple geometric forms: The attached project has a double row of holes for Dupont sockets, essentially 40 squares in two rows of twenty.
I would expect this to be printed in three horizontal lines (two where one side is taken care of by the rest of the print) followed by a bunch of vertical lines for to generate the 40 squares - but the slicer generates seemingly random mostly U shaped parts in random(?) sequence, which requires way more retractions and also more time for positioning that straight forward way would use.
Is this behaviour intentional? And if so, what is the reasoning behind it?
I've attached a zip file that has the stl, 3mf and gcode files as well as a short video of OctoPrint that shows the unexpected way a layer is printed.
Regards,
Wolf
RE: Why does the slicer generate gcode the way it does?
The slicer pathing depends on perimeter features. Your connector housing has a lot of perimeters - outward facing surfaces - and is simply printing these first.
Keep in mind that a perimeter that crosses another perimeter would lay down two layers of plastic at that crossing; you really do not want that to happen, either. Please don't ask why GRID infill does this because i don't know.
RE: Why does the slicer generate gcode the way it does?
[...] I would expect this to be printed in three horizontal lines (two where one side is taken care of by the rest of the print) followed by a bunch of vertical lines for to generate the 40 squares - but the slicer generates seemingly random mostly U shaped parts in random(?) sequence, which requires way more retractions and also more time for positioning that straight forward way would use.
A big part of the path planning has to do with optimizing travel in relation to the location of the z-seam, the point at which each layer starts and stops. If the slicer were simply printing the most optimal path, you might see something very different... though still probably not what makes sense from our perspective. Shortest travel times, minimizing retractions and other factors are taken into account. A big part of the final pathin has to do with:
- What option you select for the z-seam placement. If you specify nearest or aligned, the nozzle has to move in sub-optimal (from a time perspective) segments. You typically want to hide the z-seam in a corner, so some long moves can result in order to do this.
- What option you've selected for determining if the travel path can cross external perimeters. The travel may take the long way around parts that are already printed, and pathing may print segments that will block travel later.
- What infill patterns you've selected and where a layer finishes up.
These are just a few things that I've observed making a difference. I'm sure the code beneath all of this is fascinating and I won't pretend to understand it all in any depth.