Skip to content

Artefacts produced on small radius or nearly co-linear segments at corners #1046

jonathanwin opened this Issue Mar 11, 2013 · 11 comments

2 participants


When slicing objects with small radii or short nearly co-linear segments at the corners, small protrusions are created.

The STLs are created in Sketchup, and seem fine when viewed in meshlab.
The protrusions are present in "slice to SVG" also.

Attached are several versions of the object, with rounded corners, chamfered corners, squared corners, and simplified square corners (removed exactly co-linear segments)

The part has thin walls, only just over 2 widths (1.4mm vs 0.69mm), having wall thick enough for infill seems to solve the problem.

I'm running 0.9.8, but it's much worse in 0.9.7 (a solved bug maybe?)



I can also supply source skp, stl files and configuration, but where to host them?

alexrj commented Mar 12, 2013

Yes, we'd need the STL and config to check. Put them on a public Dropbox or something else. Any public storage would work.


I've uploaded all the files to here:

alexrj commented Mar 24, 2013

I just tried to slice the holder1chamfer.stl file and the result is fine
Schermata 2013-03-24 a 20 14 22

Also, it looks like the holder1chamfer.g file wasn't generated with the config.ini file you included in folder.

Can you please help by narrowing the test case down? We need one STL file and one config.ini that we can use to reproduce the troublesome output.


Thanks for your help!
I have uploaded a new test case that puts all the problems in one stl file.
Slicing with extrusion width 0.6, 0.65 and 0.69 gives different results, but 0.69 is the most visible (and affects all test objects)

Files are here:

alexrj commented Apr 18, 2013

So, I'm puzzled because I can't reproduce this. When slicing your demo.stl file with config.demo.ini I get a clean result, which is different from the demo.g file you supplied. I wonder why do you get those spikes and how could I reproduce it.

What OS did you try this on? Linux? 32bit or 64bit?


I'm running on Ubuntu 12.10, 32bit.
I did have Slic3r 0.9.7 "installed" before, maybe there's some configuration left over that isn't ex/importing correctly?..
I will try deleting ~/.Slic3r.


Deleted .Slicer, no change.

  • Delete/rename ~/.Slic3r
  • Start slic3r 0.9.8 (x86)
  • go through wizard, all default options
  • import config.demo.ini (discard default settings changes)
  • Quick slice the demo.stl file (using the plater also does the same)
  • Enjoy

slic3r 0.9.8 (x86_64) does the same

Note that the demo.g output changes every time (due to start point randomization), the extruded traces stay identical albeit in different orders.

alexrj commented Apr 19, 2013

What about Slic3r 0.9.9?


Running the above steps on 0.9.9 x86, Slic3r crashes on leaving the wizard:
Can't locate object method "select_default_preset" via package "Slic3r::GUI::SimpleTab::Printer" at /home/jonathan/Documents/Craft/reprap_utils/Slic3r099/lib/std/Slic3r/GUI/ line 246.
I'll open a separate issue for that if there isn't one already.
Just restarting it works, but forgets all settings entered in the wizard.

Importing the config.demo.ini does not produce the expected gcode, I have tracked this down to expert mode needing activating before importing the config.
Separate issue also.

These problems aside, The gcode produced by 0.9.9 is correct. It seems the problem has been fixed between 0.9.8 and 0.9.9.
Unless you want to track down the original bug in 0.9.8 (or at least reproduce it), this can be closed I think.

alexrj commented Apr 19, 2013

Good! Thanks.

@alexrj alexrj closed this Apr 19, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.