Thanks @supermerill, I will take a look. Could you copy/paste your ironing wiki entry into a PR for The Manual? That way I can merge both and it should update as soon as it goes live.

ok, i'll do that.

Like that?
slic3r/Slic3r-Manual#56

https://ci.appveyor.com/project/lordofhyphens/slic3r/builds/19156645/job/5pdi2f6pxt979tbq/artifacts

Hi! I'm testing this PR out locally, and I've run into some results that seem counterintuitive - I ended up with worse results on the top layers than I do in Cura without ironing!

I'm printing a couple more test parts as I type this - one more in Slic3r without ironing, and one more in Cura with ironing - but as of right now, it appears this might need some more tuning, or at least some more tunable settings.

Other than that, I like how it's handled - just change the top layer fill type, and bam. Very smart.

@chainsol did you read the wiki/doc?

Cool

I have more settings for top-layer quality in my fork, but i wanted to merge things gradually.

Can you post some pictures+settings to see what's problematic for you?

Of course!
http://imgur.com/a/0ppYYPV

Slic3r settings are identical to Cura, so 0.2mm layer height, 0.9 flow rate, 220c, 50c bed, 60mm/s.

Cura's top layer is much more consistent than Slic3r - and the ironing only made the layer bulge more due to the added heat and material.

Thank you!

I wonder if the first pics was with or without the merge? What about the "over-bridge flow ratio" ? I suppose below that the first pic is without it (or a "1" value). If it's more than 1 in the first pic, that's probably the problem (value too high or maybe i should reduce the area of effect to not over-extrude near perimeters).

Cura's top layer is much more consistent than Slic3r

Seems like a bit more of over-extrusion in slic3r vs cura, also cura rectilinear can draw 8 lines vs 6 for slic3r, so it seems that the top layer width isn't the same. But it's not the topic of this thread,.

Sadly, I didn't add the "enforce 100% fill volume" option in this pr (it's an algo to be sure the amount of extruded plastic volume will be equal to the volume to fill, by playing on the flow), it's particularly useful for small surfaces, because the infill/perimeter overlap ratio can have a huge impact on them (creating over-extrusion). I will submit this as a new pr after this one.

For the "droplet" in the left of the ironing part, it looks like oozing, a lack of z-hop, or just over-extruding, but i can't be sure without seing it. It's also present on most of the slic3r rectilinear surfaces, but It's not the subject of this pr.

The purpose of the ironing top pattern id just to smoothen the top layer. If the print has some artefacts, it will not

(also, for the next time, If you have a light grey filament, it's a bit easier to "read", from my own experience)

and the ironing only made the layer bulge more due to the added heat and material.

Well, if it's already over-extruding... But the ironing shouldn't extrude more material than rectilinear

❌ Build Slic3r 1.3.0-master-2093 failed (commit 46248c89dc by @)

❌ Build Slic3r 1.3.0-master-2124 failed (commit fd4310d55f by @)

✅ Build Slic3r 1.3.0-master-2126 completed (commit c8cde471eb by @)

It compiles ok.

I need to do some quick tests to see if it works as intended with the changes.

✅ Build Slic3r 1.3.0-master-2131 completed (commit 0ddfef6458 by @)

I've sent you a small PR to add the smoothing to the current fill.t (which pass, btw :))

As I understand it, ironing should have one long extrusion at one flow that is 9/10ths the usual solid infill flow and then a set of extrusions at 1/10 solid infill flow, evenly spaced?

As I understand it, ironing should have one long extrusion at one flow that is 9/10ths the usual solid infill flow and then a set of extrusions at 1/10 solid infill flow, evenly spaced?

Yes. The most important thing to test is to see if the gcode.cpp / gcode.pl create the line in the right order (= respecting "no_sort" flag). As it can be "random", it's a bit difficult/time consuming to do.

✅ Build Slic3r 1.3.0-master-2172 completed (commit c4cbcf527f by @supermerill)

@supermerill is it non-deterministic for the same model?

Shouldn't be. (it's up to the legacy gcode path planner).
I have to make the code "buggy" (removing the flatten_if_sortable call is enough for my fork, but maybe not in this branch) , ie make it extrudes the thin line before the big one.
I didn't had the occasion to observe the "badly sorted" output, so i didn't have the occasion to create a test (yet).

I've fixed some bugs in master that were introduced by the config system changes (configs are now more picky about what you can get from them or how you can set them), you probably want to rebase.

This currently affects the C++ test suite and the CLI.

✅ Build Slic3r 1.3.0-master-2212 completed (commit 32709533a8 by @)

✅ Build Slic3r 1.3.0-master-2217 completed (commit 05956d2c87 by @)