Infils over empty space - slicing problem?

Dear All,

I've just finished building my reprap and now I'm doing very first prints. Today I was doing tests with overhangs. I've built a very simple object in OpenSCAD using the following script:

difference() {
	cube([10, 30, 10]);
	translate([-1, 1.5, 1.5]) cube([12, 27, 7]);
}

As you can see, it's just a hollow box 10x30x10 without two side faces, i.e. only bottom, front, top, and back. Each face is 1.5mm thick.

The print goes well up to a point when the first layer of the top face is being printed. The problem is that generated gcode builds bridges only around the edges of the face, and trying to create an infill in-between. This fails, as infill lines have nothing to stick to, because bridge lines are hanging 1-1.5mm lower than nozzle. My naive assumption was to expect generated gcode to create at least two layers consisting only of bridge lines before any infill could be printed. I've definitely seen prints like this.

I've attached a photo of a failed print (taller than generated by the script above, but it's not the point), and an image of the first layer "over the void" generated by Pronterface at the back of Slic3r-generated gcode.

Is it a correct behaviour, or does it happen because I'm doing something wrong?

I'm using Slic3r 0.7.1 through Pronterface Mar2012.

Edited 1 time(s). Last edit at 04/06/2012 05:17AM by Igor Lobanov.

It's the current behaviour of Slic3r.
For now you could :

1) use Skeinforge and its "Infill in direction of bridge" option for that kind of print.

2) Or you could tell slicer to do its infill at the right angle by playing with the "fill angle" parameter.

---

Most of my technical comments should be correct, but is THIS one ?
Anyway, as a rule of thumb, always double check what people write.

Yeah I noticed this too, and even made a report on github which got closed, I wasn't able to be as clear as you as to what the problem was.

Slic3r already do one layer infill in the direction of the bridge, it even does different direction on the same layer if needed.

module c(){
	difference(){
		cube(20,center=true);
		scale ([3,1,1]) cube(10,center=true);
	}
}

for(i=[0:9]) rotate([0,0,i*36]) translate([60,0,0]) c();

The main problem why the print didn't come out good - apart from bridge printing being difficult in the first place - is there is only a very narrow piece for the infill to attach to. It'll probably work better if you use only one perimeter. Still, your print looks good for a starting print, but the technology does have its limits.

For difficult parts like the Prusa x motor mount, I like to tweak the infill to fit the longest bridge, as it does make it stronger. And a fan always helps with bridges (I'm printing PLA).

---

--
-Nudel
Blog with RepRap Comic

Thanks for your comments guys.

Nudel, I've tried your model and slic3r has generated layer with bridges correctly. Apparently, there's a combination of slicing parameters and a wall thickness that causes slicing problems.

I've done some experiments and it turned out that slic3r doesn't generate bridges correctly if walls are thinner than 3 lines of perimeter. For 0.5mm nozzle and 3 perimeters it's slightly more than 1.5mm because extruded filament expands and slic3r accounts for it.

I've created a test model to confirm that:

module testbox(walls) {
	difference() {
		cube([10, 20, 20]);
		translate([-1, walls, 2]) cube([12, 20 - walls * 2, 16]);
	}
}

translate([-20, 0, 0]) testbox(1.5);
testbox(2);

As you can see, it has two boxes, one of which has 1.5mm-thick walls, and the other has 2mm-thick walls. For both boxes hole ends at the same height. When I'm running slic3r with perimeters set to 3, slic3r fails to generate bridging for 1.5mm one, while for 2mm one it goes well. If I'm switching perimeter to 2, bridges are correctly generated in both cases. I've attached a couple of images of bridging layers for both settings.

In my initial test, walls were 1.5mm-thick, which is a tiny bit less than it's required to have bridges to be generated correctly.

So, it looks like a bug. The workaround is to adjust the wall thickness or perimeter setting in a way that there's a space for all perimeter lines.

Edited 1 time(s). Last edit at 04/06/2012 02:56PM by Igor Lobanov.

I've created an issue report at the back of this discussion:
[github.com]