Has anyone else notice or is it me observing that Cura has a very inefficient gcode path process.
As you see on the attached picture in the white areas the gcode passes overs these areas meaning it doesn’t lay down plastic. Yes eventually it does come back and lays down plastic in these areas, but it just seem to me so inefficient.
When cura compiles the gcode what is MOST important ?. The most efficient travel path or quality or both.
Slicers have always done this type of weird jumping around. Slic3r is particularly bad in this regard. It was a much bigger problem in the days when retraction didn’t work well and the nozzle would be oozing every time it moved around.
It’s called the “Traveling Salesman Problem” and it has been a mathematical domain and its own problem since math has existed practically. The greatest scientists and mathematicians don’t even have an optimal algorithm for this…though they do have some very fast ones.
“In the theory of computational complexity, the decision version of the TSP (where, given a length L, the task is to decide whether the graph has any tour shorter than L) belongs to the class of NP-complete problems. Thus, it is possible that the worst-case running time for any algorithm for the TSP increases superpolynomially (or perhaps exponentially) with the number of cities.”
TSP was part of my PhD thesis. Branch and bound has been around for half a century and works pretty well for stuff like this - 40-60 nodes would cover nearly any print. I don’t think the open source slicers take any sort of intelligent approach to this problem, but I haven’t looked deeply into how they work.
EDIT: just looked into Cura. It seems to use nearest neighbor, which is a not very good. Nearest neighbor does not guarantee optimality, and in some cases will return the worst possible solution.
Cura is better than Slic3r last time I compared them. Cura attempts to have as few travel moves as possible, and it will do travel moves over old perimeters instead of crossing perimeters to avoid accumulating ooze. There’s a very smart commercial slicer out now (Simplify3D) that seems to be much smarter than the current free offerings, but I haven’t tried it yet.
@Jelle_Boomstra Why wouldn’t it? You dont need to make a node for every track, only every rectangular, triangular, etc area. If you were printing a calbration cube for example, You’d have 1 node on the bottom, and 4 nodes on the sides.
Slice the object, fit polygons of your liking to the infill areas (rectangles would be easiest), job done. A dozen nodes (polygons) would probably cover the object above.
I’d be excited if slicers do better path routing. That said, I don’t think there’s that much time spent “hopping” between different segments. Those hops are rapids and actual part build takes the strong majority of the build time. But if it makes the part a few percent quicker because of better sorted motions, I’ll take it.
For the purpose of the optimization discussion, I understood the “node” to be the start and end point of each jump, or start and end point of each build “island”, either way. I think 40-60 nodes would cover most parts.
