Closed kefir- closed 10 years ago
Is this the same thing as #512?
Yes, it looks like the same, only that it is vastly exacerbated by the "avoid crossing perimeters" option. The printer goes bananas moving back and forth around the slot in the middle. Have a look at the gcode in the gist, search for "G1 Z3.100" and look at the following code.
Just to add, I don't understand why the infill isn't printed on one side first, and then on the other side. Shouldn't require many retracts or moves at all, only some details in the corners.
I need to finish porting an algorithm for this. I'll close this issue as it's a duplicate of the other one, but they will stay linked.
I have something similar here. Please let me know if that is the same case or if it is better to open a new issue. I have a problem like that on 1.1.1 only, 1.0.1 seems to be a better path planner.
Results on 1.1.1 experimental: 6hr job time
Results on 1.0.1 Stable: 3hr job time
Both g-codes + STL are available here: https://www.dropbox.com/s/dbqb91bge54afpm/BetterPath.zip
Thank you @thiagopeixoto16, I fixed this.
I have a part that is essentially a box, but with a deep slot in the middle. That creates a perimeter that almost, but not completely, splits the box in two. When slic3r generates rectilinear infill and "avoid crossing perimeters" is selected, the infill is generated on one side, then it moves to the other side of the slot, draws two lines, and then back around again, draws two lines, then back around again, etc.... It takes a long time, and the infill gets messy as a result.
Here's my config and the generated gcode, a gist was the best I had available right now.
https://gist.github.com/kefir-/6cd329c377f7626228f7