Having been pondering the control software for a little while, following another discussion thread [
forums.reprap.org] and reading a slightly grumpy blog post at [
blog.reprap.org] (98% of a carriage), I decided I should actually dive in and take a look.
Cue mild arrogance and software-engineer-nerd mode!
There are indeed a whole bunch of fairly fundamental problems, and it occurs to me that *something* needs to be done
I'm inclined to blame the rather nifty build progress window. For a moderately complex shape (I used corner_bracket.stl from the object library) I imagine it uses an awful lot of triangles. It never completed the shape without dying from an out of memory exception, and whenever the garbage collector kicked in (every few seconds) it was easily taking a second or more to sweep through the program's objects.
The larger and more complex the object, the more triangles will be displayed in the progress window, and the more memory will be eaten up. Hence the failure of the larger and more complex parts. If this data was not retained, references to all the triangles in each slice could be removed after the slice was printed, keeping memory usage down: no out of memory crashes, and more importantly much faster garbage collects as much less memory needs to be swept.
Anyway, this is all a bit disasterous. The fabricator demands a certain level of response time... the big garbage collects that occur at random intervals mean this response time cannot be guarateed and as a result you'll get a big blob of extruded plastic each time. This is the reason that EMC [
www.linuxcnc.org] runs a linux kernel with real time extensions.
The pooling is merely an irritation compared to the whole host falling over and the build halting as a result.
I believe that three different applications are needed:
* A GUI front end controller
* A slicer and dicer
* A hardware driver
If these are done carefully, lightweight and compact platform-agnostic tools can be written to do the second and third tasks, with a (potentially OS-dependent) GUI that ties the bits together.
The hardware driver can be small and fast, and perhaps even housed on a separate machine, given that the bits of the system that require an excess of memory or processing power (a GUI with 3D visualisation, or the slice'n'dicer with its number-crunching and memory needs) are quite separate. Partial or total failure of the UI machine would not interfere with the operation of the fabricator in the slightest. assuming that the output of the slice'n'dice module was saved to some intermediate format and passed on to the machine controller.
Does anyone think this is a sensible idea?
I'm not going to act the part of the internet idea man here, and ask for some designers and coders to work under me
It would however be nice to do this sort of work *with* other people, rather than as a solo effort. Especially as other people have a far better idea of what is going on that me!
Edited 1 time(s). Last edit at 02/24/2008 04:27PM by Ru.