RepRap Host software architecture

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.

i agree wholeheartedly with you.

we'll get there. whether its in fits and starts, or slowly and surely, i cant tell you. but i do know we'll get there.

first step: breaking up the slice/dice -> print commands chain. =)

What are the chances that a retooling of this magnitude could be integrated before a v1.0 release? Or are we looking at host software 2.0 here?

Either way, I think this suggestion has merit. By divorcing the lower levels of processing from the GUI front end, it makes popping a new module in at any of those points nice and simple. For example, you would no longer necessarily have to emulate the SNAP protocol in the Arduino firmware - you could just replace the hardware driver code to send signals (gcode, to name a timely example) that make more sense to the chip. You could have driver modules that, for example, drove the three steppers directly from a parallel port like I believe some CNC mills do it.

Of course, if you could break it down even further and make it modular enough to run subtractive manufacturing as well, this could become the de facto standard in open source manufacturing... but now I'm getting way beyond our mission statement!

I think the only real candidate in the open source manufacturing arena is probably EMC, given that it is pretty widely used and contains significant amounts of magic for handling multi-axis devices or ones with more exotic geometries... trying to replicate that level of functionality would be silly as they already do it very well

I guess there's nothing to stop you speaking to the stepper controller boards directly, which might cut out the whole arduino stage altogther, comms, g-code parsing and all.

I'm not convinced this is the best way to go, though I'm having a tough time justifying the 'smart robot, dumb host' approach when you consider that a dumb robot might require fewer bits of electronics, and hence be easier to replicate.

So, important question number one. RepRap doesn't use something like EMC driving stepper driver boards directly, instead sharing the robot control between driver software and controller boards. Was there any particular reason for this?

* edit: There was a second question here, but I think I answered it for myself

Edited 2 time(s). Last edit at 02/25/2008 04:38AM by Ru.