Repowulf cluster

Problem: A RepRap takes on the order of days to print parts for replication. This will slow availability of RepRaps.

Solution: the Repowulf cluster. Componentize the software that drives the RepRap into two parts:

1. The queue manages a list of parts to be printed;
2. The print driver drives the actual RepRap system.

In default mode, the process would look like this:

1. The user starts the RepRap software on the first machine;
2. The software seeks a queue on the local network using Zeroconf/Bonjour zero-configuration networking;
3. It doesn't find it, so it starts a queue component;
4. Then it starts a separate identical process on the same machine;
5. The second process starts up, does its own zeroconf search;
6. It does find the queue component previously started;
7. It requests the first piece off the queue and starts printing;
8. Now it gets interesting: the user starts a second instance of the RepRap software;
9. It does find the queue component previously started;
10. It requests the next piece off the queue and starts printing;
11. Later, the parts for a third RepRap are completed;
12. The user gets his/her friends together and assembles them;
13. They add the necessary computing capacity to the network, attach the new RepRap, and start the software;
14. It finds the queue component previously started;
15. It requests the next piece off the queue and starts printing;
16. And so on exponentially...

One modification of the previous process: instead of saying 'Etiquette requires that a new RepRap must be used to replicate itself twice,' we say 'A RepRap comes out of the cluster when it has printed twice the weight of a RepRap's replicated parts.' This still allows exponential acceleration, but accommodates other uses of a RepRap.

Of course there would be other modes: non-queued, queue-only... we'd have to decide what to do when multiple queues appear on the same network, things like that.

We would start from the current codebase of a current RepRap software driver. There is a Java version in the RepRap repository on Sourceforge. There is also a Python version somewhere.

We want to be careful to design the communication between the queue and print components to be platform independent, so a Python queue could talk to a Java print driver and so forth. This is why use zeroconf instead of something like Jini, for example.

the bigger idea

What we're really trying to do here is to establish second-order Darwinian dynamics, evolving the evolvability of the RepRap design. We want to make this technology more widely available to engineers who want to improve RepRap design, so that it can exploit a larger pool of expertise. And we want it to be available to more people more quickly.