Occasionally Travel Moves are Generated With Extrusions.

[ruevs]

Version

Version 1.3.1-dev
Build commit: d17659b
32bit
Slic3r-master.2018.09.08.1848.d17659b.32bit.zip

Operating system type + version

Windows XP SP3 32bit

Wrong Behavior

Occasionally moves that should be travel moves are generated with extrusions.
Models similar to the attached one with "three spokes" occasionally show this on layers other than the first one as well.

STL/Config (.ZIP) where problem occurs

Slic3rBug.zip
config.zip

Expected behavior

This is a regression of sorts. For example Slic3r-master.2018.04.26.1669.8a93fbb.32bit.zip (which I had laying around) does NOT have this problem when slicing the exact same object running on the same machine (so the exact same configuration as above).

Slic3r-master.2018.04.26.1669.8a93fbb.32bit.gcode.zip

Initially I posted this here #3755 but I suspect it is not the same issue so I am opening this one.

[lordofhyphens]

So the problem goes away when you run the STL through netfabb. Joy.

Slic3rBug_fixed.zip

[ruevs]

Thank you for looking at this.

The file you uploaded slices fine indeed. However the mesh is very different from the original. How did you "run it through netfabb"?

At the same time the original is a perfectly valid STL file according to Netfabb itself:

The part repair tool reports that everything is fine and does not change the geometry at all when executed - at least in Netfabb version 7.4.0 532 that I have.

So what does this mean for the Slic3r behavior? What about the fact that an older build slices it fine?

[lordofhyphens]

Service.netfabb.com is what I meant.

I have not done a bisect yet ( it is a very long process to do so)

[platsch]

I can confirm the bug, having the same issue with several models. The extrusions are actually printed and not only generated for the preview. Blaming the stl files to be inconsistent is a an easy, but not very helpful answer. I'm having this issue with a number of different files which are sliced correctly by older versions of Slic3r. Runnung every second model through netfabb is slightly annoying...

Unfortunately I have no clue of what could be the reason, didn't do substantial debugging though.

[VanessaE]

I am experiencing this artifact, too (commit 1e4fb2d).

(there is not supposed to be any geometry at the bottom of that open space)

Stl: turn signal stalk repair.stl.zip
Config: config-20181201.ini.zip

[lordofhyphens]

reproduction_case.zip
Here's a cut-down version of @VanessaE model.

Looks like it's in the thinwall code.

[lordofhyphens]

The pseudocode for the regression test looks like thus:

Given: The 3D model [reproduction_case.zip] (https://github.com/slic3r/Slic3r/files/2636486/reproduction_case.zip) and a default config,
When: the model is plated centered at 0,0 and thin_walls=1

Then: No extrusion moves are generated from X1.856 Y-6.933 to X1.793 Y-6.899

[supermerill]

My previous thin wall pr is seriously flawed. You should revert it or i have to finish the new one.

[ruevs]

Any progress on this?
Slic3r-master.2019.04.13.2318.85dd6633.32bit-PR.zip
Still has exactly the same problem.

[supermerill]

should be resolved on the branch merill_thinwall

should be downloadable in the dev branches like here
https://dl.slic3r.org/dev/
search for PR4790

[ruevs]

It seem to be fixed in this AppVeyor build artifact:
https://ci.appveyor.com/project/lordofhyphens/slic3r/builds/31012289
from here:
#4790