# Pretty ugly surface remains after using support ramp. Are my slicer settings correct?

I'm printing a object with a pretty sizable overhang. And the results, after support removal, are pretty ugly.

Here is the print before support removal.

And here is the final product, sigh.

Finally here are my slic3r settings:

• Generate Support Material: [✔]
• Overhang threshold: 60°
• Max Layer Count for Supports: 0 layers
• Enforce Support for the First: 0 layers
• Raft layers: 0 layers

Options for support material and raft

• Contact Z distance: 0.2 (detachable) mm
• Pattern: pillars
• Pattern spacing: 2.5 mm
• Pattern angle: 0°
• Interface Layers: 3 layers
• Interface pattern spacing: 2 mm
• Support on Build Plate Only: [✔]
• Don't support bridges: [ ]

The material I'm using is ABS, 230 °C temperature setting. Layers, Adaptive Slicing, Adaptive quality: 75 %, Match horizontal surfaces. Vertical shells, 3 perimeters minimum. Horizontal shells, solid layers: top: 3, bottom 3.

Is there a way to improve this?

Note: for anybody interested... these are small disposable spatulas used to place bondo mix onto a flat surface at the bottom of a restricted space, to fill small holes in wood. Its too tight in there to use a normal putty knife.

---edit-------------------------------------

There has been some conversation about print speeds. Included here are the speed settings from Slic3r:

---Edit #2---------------------------------

Gee, looking at this, I'm wondering why there is such a large gap between the gold colored E shaped interface to the blue spatula handle? And that makes me wonder, what support material and raft settings should I be using? Why is that gap so big? (And I have to go back into SolidWorks and check, but I'm nearly certain that handle is 2 mm wide. That gap to the support is really big.)

• It appears as if the support is just too far away, and then the bridging fails as of the high print temperature and minimal amount of cooling. This prints much easier in PLA. – 0scar Jun 2 '20 at 22:01

## 1 Answer

I'm not terribly familiar with slic3r, but it looks like you have a setting (possibly a default one) to slow down on printing overhangs. This was a popular "feature" in slicing software (Cura has it I know) but it's exactly the opposite of what you should be doing. When slowing down to print an overhang, the pressure in the nozzle forces the material to keep coming out at the same rate it was coming out until it subsides, and you end up with a big hanging glob of ooze like in your photo.

If your printer firmware has linear-advance/pressure-advance functionality, this can mostly be eliminated. But if not (most stock firmware), you need to maintain full speed on overhangs, and might even need to turn up your acceleration limits so that you don't get a significant slowdown just by decelerating to go around the corner.

• I see your words written here, but I don't understand what you are talking about. "Slow down on printing overhangs" ? Where is that set? You mentioned Cura, does that mean Slic3r has a similar setting (and fix)? Then you jump to firmware. I'm using Slic3r --> Printer Settings --> General --> Firmware, G-Code Flavor: Sailfish Makerbot Can that setting be corrected in Sailfish? many thx. – zipzit Jun 2 '20 at 2:59
• Hmm, I thought slic3r had an option like this but I can't find documentation on it. Can you open up your gcode in a viewer that shows speeds and see if it's using a lower speed for the overhang? If not, it may be just an acceleration issue. – R.. GitHub STOP HELPING ICE Jun 2 '20 at 3:09
• I'm trying. Based on your comments I created vebose G-Code. I'm playing with ncviewer.com but there is too much stuff in the way to see the specific g codes at the interface between the overhang on the desired part and the support. Note, I do see varying F codes (which I believe affects the speed of the head) and E codes (extrude commands) Do you have a suggested G-Code analysis system that would make this easier? Hmmm. Let me add my GCode to the problem statement. oops. no go on file upload, sigh. – zipzit Jun 2 '20 at 3:38
• @zipzit: I like gcodeanalyser.com and gcode.ws – R.. GitHub STOP HELPING ICE Jun 2 '20 at 3:47
• See edit #2. I'm wondering if print speed really is a root cause here. – zipzit Jun 2 '20 at 4:08