Changes to Slice and Dice

Slice and Dice was fine as long as your parts were more or less continuous along the z-axis and not so complicated that you got a lot of clashing with print loops. When I got to working on the thumb joint on my telepresence hand, however, I started having a lot of trouble with both of those limitations.

A major strength of Slice and Dice is that if you have a dodgy STL file you can clean up little imperfections on the slice images. That's wonderful until you have a part that you want to print that has little in the way of commonality between slices. I found myself fixing faults on 30-40 slices in Paint. That was seriously not fun. The main problem, as it developed, lay in the implicit dependence of Slice and Dice on looped road descriptions. Once you get into complicated parts it becomes very difficult to meet the app's expectation of clean looped print roads.

This is the part that started causing me trouble.

Virtually every slice is unique.

I rewrote the road making routine to deal with non-looped roads this evening. This is the resulting test print of the part shown above.

A problem that the old Rapman firmware was that it expected minimum print road line segments to be about 0.6 mm long. When I finished the rewrite, I was not looking forward to fitting line segments to the non-loop print roads. I had the output, but it was all 0.1 mm print roads.

Andrew at BitsfromBytes has said that the updated firmware would handle 0.1 mm roads with no problem. I frankly didn't believe him because the older firmware would slow the print down to 6 mm/sec with 0.1 mm roads. I decided to give it a try with the 4.0.2 code, however, and it turned out that Andrew is absolutely correct. The Rapman firmware has no trouble print sequential 0.1 mm line segments at my chosen print speed of 16 mm/sec.

That made the print file for the two halves of the thumb joint some 8 meg long. Since I have a 1 gig SD card, however, that's no trouble at all.