Which thinwall open box is better?
Object A:
or Object B:
The latter, of course: I blundered the inner corner radius, which occasionally produced little tiny dots of infill that shouldn’t be there. Just one of those errors that hides in plain sight until something else goes wrong, then it’s obvious.
Rather than fix the Minkowski version, I rebuilt it using the hull() operator to shrinkwrap four cylinders for each solid, then remove the smaller block from the larger. Commenting out the hull() operators shows that the cylinders now line up properly:
The OpenSCAD source code:
// Thin wall open box calibration piece
// Adapted from Coasterman's Calibration set
// Ed Nisley - KE4ZNU - Dec 2011
// Adjust for Slic3r/M2 - March 2013
// Reworked for hull() with correct corner radii - April 2014
//-------
//- Extrusion parameters must match reality!
// None of the fill parameters matter
ThreadThick = 0.20;
ThreadWidth = 0.40;
Protrusion = 0.1; // make holes end cleanly
function IntegerMultiple(Size,Unit) = Unit * ceil(Size / Unit);
//-------
// Dimensions
Height = IntegerMultiple(5.0,ThreadThick);
WallThick = ThreadWidth;
CornerRadius = 2.0;
CornerSides = 4*8;
SideLen = 20.0 - 2*CornerRadius;
Rotation = 45;
//-------
module ShowPegGrid(Space = 10.0,Size = 1.0) {
Range = floor(50 / Space);
for (x=[-Range:Range])
for (y=[-Range:Range])
translate([x*Space,y*Space,Size/2])
%cube(Size,center=true);
}
//-------
ShowPegGrid();
rotate(Rotation)
difference() {
hull() {
for (i=[-1,1], j=[-1,1])
translate([i*SideLen/2,j*SideLen/2,0])
cylinder(r=CornerRadius,h=Height,$fn=CornerSides);
}
hull() {
for (i=[-1,1], j=[-1,1])
translate([i*SideLen/2,j*SideLen/2,-Protrusion])
cylinder(r=(CornerRadius - WallThick),h=(Height + 2*Protrusion),$fn=CornerSides);
}
}
The Smell of Molten Projects in the Morning 
Ed, Do you think the issues you found wrong with this calibration item is likely similar to the odd protrusion effects people have been noting on their STL items posted to Slic3r’s Issues on gitHub?
Something Bad has definitely happened to Slic3r’s geometry handling in recent versions, apparently due to changes in an underlying library, and it definitely can’t slice the thinwall cube, which is why I don’t have a finished product to show off.
I have the uneasy feeling that Slic3r may have become too complex for a (mostly) single developer project…
Sadly this too seems to be with the 3DRobotics APM systems. Those are the autonomous vehicle’s Open Source firmware and software. The issues are constant and the changes frantic for more issues to be there. It seems these may become commercial products soon or expire.
Say – did you see 3DSystems has partnered with Canon printers? And going gonzo for retail?
We watched the boat sail from the dock….
Makes perfect sense, although I can’t wait to see the pricing for consumables…
You are going to update the issue on Slic3r GitHub?
My description was #3 on the list; I’m hoping they’ll get a patch / workaround sometime soon…
What was the problem with the Minkowski version?
Have you considered using the vase trick of printing it as a solid object with no solid layers and no infill?
The Minkowski is a fairly large hammer for what’s really (in this case) a very small problem. I used it back then because, well, it seemed like a good idea at the time. Now I have a better grasp of the whole modeling process; that’s my story and I’m sticking with it.
It turns out that by slicing the thinwall box in the dumbest possible manner (i.e., not enabling fancy optimizations like Vase Mode), the G-Code includes most of the operations that happen in more complex objects. For example, if the retraction settings aren’t right, the gaps or zits will be painfully obvious: there’s nowhere for them to hide!
The point isn’t to make a beautiful box, but to discover what’s busted!
I wasn’t referring to “vase mode”, but rather, the trick of modeling vase-like objects as filled solids. See http://www.thingiverse.com/thing:13505/ for a non-vase example. If you look in the comments, you will see that various slicers have problems with the thin-wall version, presumably because it is having problems figuring out that it can be sliced with nothing but perimeters.
If you modeled a solid box using just the outer hull, then sliced using n perimeters, no infill, no top and bottom layers, no vase mode(!), you will get (should get) identical gcode to what you get from your thin-wall model.
Ah! Now I get it… and it worked exactly as you described.
However, the results aren’t quite identical to the thin-wall hollow box: the no-infilled solid box lacks the corner glitches. I don’t know whether that’ll be generally true for other models, but it’s a good workaround for now.
Thanks for the tip!