Help: skeinforge refuses to raft this part

Hi all,

I'm trying to print [www.thingiverse.com] on my new Thingomatic. I'm using replicatorg with skeinforge-0035. No matter what I do, I cannot get a raft to print.

When I process other STLs, skeinforge outputs gcode with a satisfactory raft. But with this object, no matter how I rotate or position it, I never get a raft. Instead I get this output in replicatorg:

[01:24:38] Temperature procedure took 0 seconds.
[01:24:39] This should never happen, the base layer has a size of zero.
[01:24:39] This should never happen, the interface layer has a size of zero.
[01:24:39] Zero length loop which was skipped over, this should never happen.
[01:24:42] Raft procedure took 4 seconds.

Does anyone know what might cause this? I've double- and triple-checked the "use raft" checkbox and the raft plugin settings, but the gcode always comes out with this:
(<extrusion>)
;M113 S1.0
M108 S255.0
M104 S225.0
(<raftLayerEnd> </raftLayerEnd>)
(<layer> 0.98 )
(</layer>)
(<layer> 1.38 )
(<surroundingLoop>)
(<boundaryPerimeter>)
(<boundaryPoint> X-20.778 Y-8.0 Z1.38 </boundaryPoint>)

Perhaps relatedly: the renders of the STL all show three large "holes" -- segments of an annulus -- around the part outside the bearing. When I try to run the raftless gcode, in addition to getting a crappy print due to the lack of raft, I also notice that one of these three holes is missing (i.e., it's filled right in as if the hole weren't there). This happens consistently as well; I have regenerated the gcode many times after tweaking the various raft settings.

Is something wrong with the geometry of the STL? If so, what?

Thanks,
--abliss

Sounds like something wrong with the STL. I imagine the mesh has holes and wrong normals, making Skeinforge flip out. It must be bad because Skeinforge can usually handle pretty crappy STLs. Also, others report that missing hole for that STL too.

I could be wrong, but I don't think SF cares about the normals.

---

[www.hydraraptor.blogspot.com]

nophead Wrote:
-------------------------------------------------------
> I could be wrong, but I don't think SF cares about
> the normals.

I didn't think it did either, but I've gotten some weird slices in SF with bad STL's. It'll still slice them sure, but the results may not be what you expect.

Yes STLs can also be non-manifold and that may confuse Skeinforge.

I think I am right in saying that having the normals stored in an STL is completely redundant because you can recreate them with a simple vector cross product and which way a triangle is facing can be determined from the winding order. Presumably if the winding order is wrong it will confuse SF because the triangles will actually be facing the wrong way.

---

[www.hydraraptor.blogspot.com]