Slic3r is sullying my toolpath!

Has anyone seen Slic3r do this with a toolpath before? why is this happening in the middle of an otherwise perfectly sliced model? This little maneuver is threatening to knock the print off of the platen! Is there something wrong with my .STL file or do I need to talk to Slic3r about their rogue code?

What happens when you slice it with the standalone version of Slic3r or Cura?

Cura toolpath looks fine. Yes Slic3r does this in the stand alone version too.

What version of Slic3r are you using? A beta version, or a stable version?

I exclusively use Slic3r and I’ve never had an issue with it.

Have you tried printing the part and seeing what happens?

If you slice the part in Slic3r, then view the gcode slices in the Pronterface preview what does it show you?

I have to wonder if there’s just a software conflict with the graphical view. :question:

Do you have the software set to comb for holes or edges? I’ve noticed that when I have software set to not go across holes it will make the nozzle do Kung Fu moves every once in a while. I’m not exactly sure how to solve the issue other than by turning the combing feature off.

I was printing the part when I noticed the printer freaking out with these moves. I opened the preview window in Repetier, turned on reveal toolpaths and found the noted anomalies. Seems to have a nervous tick under some circumstances.

Where in Slicer do you set the option to comb for holes or edges? I don’t recall seeing that option.

Oh, I’m messing with version 1.2.6, but this happens in 1.1.7 too.

I wonder if it’s having some kind of conflict with the “Don’t cross perimeters” setting?

“Open the pod bay doors Hal.” “I’m sorry, I can’t do that Dave…”

I’m pretty sure that the don’t cross perimeters setting in slic3r is the same as comb in Cura. Did you try turning that feature off and looking at the generated tool path yet? That would be my next move.

There might be a small inconsequential error in your .STL file. You might try downloading the free version of netfabb, and run the STL fixes on it, then re-export the repaired stl from netfabb and see if it does the same thing. That or post the STL file here.

Hmmm… would appear that the “Don’t Cross Perimeters” function in Slic3r is not working properly. When I turn it off these weird toolpath jogs disappear. It would seem that Slic3r cannot calculate a path within the body of the part, so it freaks out with this zigzag response. It should just default to the path it normally would select if it cannot calculate a better one. It also appears that this is only a problem with cylindrical bits on the part. Several other part slices display this same behavior with the feature implemented. There are no manifold errors in the .stl files, and Cura slices them with none of this nonsense.

Yeah, I will still get some weird jogs in Cura when combing is on. It’s probably some archaic bug in some of the founding gcode creation software.