Sunday, January 24, 2010
New Software - May Contain Nuts...
...but fewer.
I've been a bit quiet for a while, owing to the fact that my pathetic brain can either communicate or work, but not both. About six weeks ago, I decided that the Java host software had not been looked at seriously for a long while, what with all the Mendel hardware developments that had been going on. So I decided to take it apart, put it back together again, then throw all the funny-shaped bits that were left over in the bin.
Ages ago Forrest started to develop his pixel-based STL slicing software, where the pixels are at the RepRap machine's resolution (about 0.1mm). I thought that this was All Wrong, because it was going to be inefficient in memory use, and would not scale well. But I did think that a very similar scheme that used a quad tree to represent slices might be a good idea.
Just before Christmas, I realised that it is very easy to do unions and intersections on quad trees recursively (something I should have known...), so I implemented it.
But, though it worked reliably, and it was parsimonious in its memory usage, it was very slow in execution. A bit of testing revealed that it was the continuous quad-tree-walking to access pixels that was eating the clock.
So I threw away the quad trees and replaced them with pixel maps in the form of Java BitSets. That went a lot faster, and - in fact - didn't use much more memory at all. So Forrest was not All Wrong - he was All Right.
The code probably still contains bugs, and I want to do more testing before doing a release, but it seems to be able to reliably compute the G-Codes for an entire Mendel tray build (pictures above). On my 2GB AMD Sempron 3800+ running Ubuntu that takes about 2 hours. The total-memory monitor for the machine hovers around 630MB for all that time, not creeping up, implying no memory leaks.
It will handle multiple materials and allows single objects to be made from several STLs - one for each material. It does fine-fill over the surface and coarse-honeycomb interiors properly. It also now asks you how many of each thing you want to print, to save having to load multiple copies of them.
The next thing to do is to get RFO file reading and writing implemented, so that you can set up an entire tray, save it, load it, and edit it. Then I'll do automatic support calculations (virtually all the code is in there to handle that anyway, now).
It's in the usual place in the repository - download instructions here.
I've been a bit quiet for a while, owing to the fact that my pathetic brain can either communicate or work, but not both. About six weeks ago, I decided that the Java host software had not been looked at seriously for a long while, what with all the Mendel hardware developments that had been going on. So I decided to take it apart, put it back together again, then throw all the funny-shaped bits that were left over in the bin.
Ages ago Forrest started to develop his pixel-based STL slicing software, where the pixels are at the RepRap machine's resolution (about 0.1mm). I thought that this was All Wrong, because it was going to be inefficient in memory use, and would not scale well. But I did think that a very similar scheme that used a quad tree to represent slices might be a good idea.
Just before Christmas, I realised that it is very easy to do unions and intersections on quad trees recursively (something I should have known...), so I implemented it.
But, though it worked reliably, and it was parsimonious in its memory usage, it was very slow in execution. A bit of testing revealed that it was the continuous quad-tree-walking to access pixels that was eating the clock.
So I threw away the quad trees and replaced them with pixel maps in the form of Java BitSets. That went a lot faster, and - in fact - didn't use much more memory at all. So Forrest was not All Wrong - he was All Right.
The code probably still contains bugs, and I want to do more testing before doing a release, but it seems to be able to reliably compute the G-Codes for an entire Mendel tray build (pictures above). On my 2GB AMD Sempron 3800+ running Ubuntu that takes about 2 hours. The total-memory monitor for the machine hovers around 630MB for all that time, not creeping up, implying no memory leaks.
It will handle multiple materials and allows single objects to be made from several STLs - one for each material. It does fine-fill over the surface and coarse-honeycomb interiors properly. It also now asks you how many of each thing you want to print, to save having to load multiple copies of them.
The next thing to do is to get RFO file reading and writing implemented, so that you can set up an entire tray, save it, load it, and edit it. Then I'll do automatic support calculations (virtually all the code is in there to handle that anyway, now).
It's in the usual place in the repository - download instructions here.
Comments:
<< Home
sounds like you have been a busy body, though i am looking forard to your other updates, i do think there are some more things that will need to be done in time though.
Wow! A few hours for a whole print surface full of parts! Wonderful! I always understood that the grid approach was going to be massively memory inefficient and probably CPU inefficient as well. It seemed to me, though, that given an environment where DRAM was dirt cheap and CPUs were subject to Moore's Law that code simplicity and maintainability might be the most desirable goal.
Adrian, are you going to have an option in your new code to output gcode files so that we can use it for SD chip systems like Rapman?
Adrian, are you going to have an option in your new code to output gcode files so that we can use it for SD chip systems like Rapman?
Nice work! I'm looking forward to reading through the code - hopefully I'll eventually be in a position to contribute something useful!
It outputs nothing but G-Codes...
But be careful - for example, unless you turn the function off (see the preferences file) it will output accelerated moves; it will also treat the extrudate as another dimension - in short all the cool things that Mendel does with G-Codes, but that I don't think MakerBot and Bits From Bytes understand yet. But - as I say - you can turn all that off.
But be careful - for example, unless you turn the function off (see the preferences file) it will output accelerated moves; it will also treat the extrudate as another dimension - in short all the cool things that Mendel does with G-Codes, but that I don't think MakerBot and Bits From Bytes understand yet. But - as I say - you can turn all that off.
How does the speed of this software compare to repsnapper? I have just played around with repsnapper a little, and I would suspect that it process that whole build platform in less than 2 minutes. Am I wrong?
Post a Comment
<< Home
