Unwanted bridging

[woodsmoke]

Manifold, orientated Stl : https://dl.dropboxusercontent.com/u/4978192/extruder-block-V2_ws.stl (MiniExtruder : http://www.thingiverse.com/thing:44291 modified to print properly)

RC1 Sliced with config file : https://dl.dropboxusercontent.com/u/4978192/sl_RC1_w3_config.ini

On Windows 7, produces unwanted bridging over voids such as the bowden tube clamp void : https://dl.dropboxusercontent.com/u/4978192/ScreenHunter_17%20Feb.%2015%2017.36.jpg

Why's that?

[sheck626]

It did that for me when I was slicing the X carriage for the "Prusa I3 Rework". It bridged over two of the bearing holders and zip-tie channels somewhere in the middle and left the others alone to print correctly. Slicing with Slic3r 0.9.10b using the exact same settings produces correct results whereas 1.0.0RC2 and RC3 do not. The model is manifold, and I even ran it through netfabb to double check (which allowed 3 bearing guides to print while the 4th was bridged over). Looking at the geometry in blender, I can't see why Slic3r would choose to create a bridge for no reason.

[jeder73]

I have the same problems with models, which are totally different in shape and size. Also, with 0.9.10b the perimeters and infill is correct, but with RC2 and RC3, some holes are filled through. I cannot determine, if it is bridging or filling, but I think it is filling, because there is no difference in motion of the print head. I mentioned, sometimes you can avoid the "wrong" fills by changing the angle around the z-axis to some "skew angle", for instance, the wrong fill is at an angle of 45 degrees, just turn around the model at the print bed about 2 third of it, but not a rounded value, resulting 29 degrees or 31 degrees in counter direction. But if you have a cyclic model with radial braces you can have troubles to find some working angle...

[kapanala]

I've been having this problem with my latest model. Rotating the model 17 degrees about the z axis fixed the problem. Thanks jeder73!. I was getting "bridging" fill on some layers and no fill on others. BTW, I have hacked a python script for converting the g-code to PostScript, which I then convert to PDF. I can then examine the layers on Adobe Reader.

I am still getting what appears to be fill that's too dense on some layers, but I suspect that may be a feature rather than a bug.

[alranel]

I tested @woodsmoke's test case. This is a duplicate of #1672. It's fixed in the master branch, maybe I'll backport it to stable.

[jeder73]

@alexrj (also relating to #1672 ) Was this backported to stable? In the recent precompiled release "1.0.0 stable" I could reproduce the wrong infills, in the precompiled "1.1.0 experimental" there were NO wrong infills, but instead, some changed behavior with gap fill... Should I open an issue for the wrong infills in 1.0.0 (assuming it did not occure for some statistical/stochastical reasons regarding some other changes in 1.1.0), or was it NOT backported definitively to "1.0.0 stable"?