In which your narrator rebuilds Tommelise’s Slice and Dice app.
Some years ago with Tommelise 1.0, I built a routine to slice STL files and lay out tracks for printing plastic on each slice. It worked reasonably well. After that, I completely rebuilt the app to do milling instead. As well, I developed routines to do milling of printed circuit boards. A few months ago, I resolved to go ahead and develop Tommelise 3.0. This entailed a completely new controller design centered around the I2C bus. That’s pretty much done. I hit a dry point in my creativity and spent a few months developing a stripboard design routine which I recently published.
Since then, it has become obvious from the complaints of several other Reprap team members that the open source Art of Illusion 3D modeling package leaves a bit to be desired. I’ve always had good luck with AoI and have, until recently. been puzzled by the bad press it’s got. Nophead (Chris Palmer) in Manchester has been very critical of AoI. I always take Nopheads criticisms VERY seriously in that he is a very thorough person and doesn’t say negative things without considerable justice. Nophead and I did a cycle of parallel tests on AoI and discovered that you can run it in what are, for practical purposes, virtually identically configured PC’s and get either excellent performance (me) or miserable performance (Nophead). That wants some serious looking into by the people on the Art of Illusion team.
Mind, my experience with AoI hasn’t been without it’s frustrations, though nothing as bad as what Nophead reports. The major problem I had was with my own slicing routine. If AoI sent over a STL which was not Euler Valid, that is, with all of the triangles making up the surface pointing outwards, my slicing routine couldget a little unstable. Not to put too fine a point on it, that means that I’d get a very bizarrely printed layer.
I’ve liked to boast that I use a grid approach to dealing with slicing and dicing as opposed to the geometric approach that Adrian’s august background in 3D graphics lets him do. Grid processing is slower but all the same tends to result in much simpler and easier to maintain, by me anyway, code. The problem historically with my slice and dice routine is that it wasn’t quite completely grid oriented, but rather a “neither fish nor fowl nor good red beef” mix of grid and geometric techniques. I decided to fix that.
Doing the Slice
Using a grid is very simple. Basically, I just create a picture box big enough to hold the object’s xy dimensions and set the pixel size to the step size of the xy steppers. I then take a slice of the STL and map it onto the picture.
The lines making up the slice are automatically represented as pixels on the picturebox, so which way a vector is pointing and other minutae that give geometrical approaches headaches simply aren’t there.
You get something that looks like this…
Once you have your slice boundaries laid down you have to fill in the parts of the slice which are to be printed with plastic. Those areas are shown in red while empty places are shown in green.
The routine that does this is very, very short and very robust. You can see the process underway here…
Once you have your slice painted onto your picture box you need to figure out where the roads your extruder is going to have to travel. This is accomplished by…
- Painting a border around the inside of the perimeter of the slice that is one-half of the width of your extrusion road less one step resolution distance {done in blue}
- Paint a white midline for the extrusion road on the inside of that blue stripe
- Paint another blue stripe next to that which is one-half of the width of your extrusion road less one step resolution distance plus the distance to the ends of your infill roads.
- Paint your infill road midlines
You can see this process underway here…
The only part of the code I have not yet written goes through and arranges a print order which minimizes the distance that the print head must move between infill roads so that the Tommelise 3.0 print head does not spend a lot of time moving around while not printing a layer. I’ve written that sort of code for the old slice and dice app, so I don’t see it as being any big deal.
Years ago in China, I had the unique opportunity to spend an evening with Benoit Mandelbrot, who brought the fractal into the general public awareness. He related a story that, I think, has some important things to say for Reprap design. When he originally went to work for IBM he was given the task of working with a particular device that was very sensitive to electrical noise. Any time repairmen in the building used an electrical drill the device malfunctioned. His supervisors at IBM wanted Benoit to track down and eliminate the sources of the noise. Benoit, being the sort of man he is, disagreed and insisted that there would always be noise caused by one thing or another and it would far better to figure out how to somehow shield the device from such noise or somehow make the circuitry itself in the device noise tolerant.
That is what I am trying to achieve with this new incarnation of Slice and Dice. It seems to me that we are going to be confronted with how to process bad STL files for a long time, given the state of the art with open source 3D modeling packages' boolean ops routines. The flooding process that I use in Slice and Dice shows you very quickly where such faults manifest in a particular slice. Rather than having to fall back on fooling with code, a Slice and Dice user can simply use something like Windows Paint or Photoship to fix the the and image and then go on from there.
Just so you are reassured that this is only robust for an over simple case…
Keeping that in mind, I’ve arranged to save the developing slices as images. This requires substantial hard disk space, but disk space is a trivial expense these days. Doing that gives me a number of very powerful capabilities.
I can review a print job visually, slice by slice and assure myself that there are no problems therein.
Should there be problems that can’t easily be cured by working with the 3D modeling app {AoI, for instance}, I can easily just pull the marred images into something like Photoshop and fix them, then reprocess the road building.
I haven’t got a full tool-path from AoI to Tommelise 3.0 yet, but it is looking very strong. It would be a very small matter to filter myslice and dice output into G-Code and use it in mainstream Reprap machines. I want to convince myself that I’ve really got something worthwhile before I suggest that sort of thing, though.
No comments:
Post a Comment