So here we have the first set of parts for the ServoStock,

So here we have the first set of parts for the ServoStock, a derivative of the Rostock using Closed-Loop control, a whole new com architecture, Servos for drive and NO STEPPERS. Pictured is the first attempt of the single axis using the Vitamins from a Printrbot.

Software/Communications:
The system we developed over 4 years and have now applied to a 3d printer is an extensible, namespaced communication protocol. Think of it like a domain specific language over a generic serialized communication link. The protocol allows devices to report to the computer their capabilities, then the computer can generate packets based on that report. We have complete implementations in Java and C99. Clojure, Jython, Jruby and Matlab have been tested working with this library. There is a partial implementation in pure Ruby as well.

Electronics:
We have redesigned the entire control system from the ground up. From the get-go we started using magnet orientation encoders plus low cost continuous servos. The motherboard is a Pic32mx440f128h with each axis receiving a servo pulse and an SPI channel for the encoder. The motherboard uses a 7x2 ribbon cable to connect to each axis. Each axis has a small board with the encoder chip and the connector for the servo.

Firmware:
The control loop runs at 20 ms for the servo pulse calculation, interpolation and forward/inverse kinematics. The device identifies itself as having the PID control namespace, the kinematics namespace, and the 3d printer configuration namespace. Through the communication layer you can change kinematics models, change PID constants and store all the Slic3r/Cura configurations. The configurations are stored non-volatile in Flash and travel with the printer to be read at runtime. NO MORE CONFIG FILES!!

The firmware also has auto-config system. The servo dead band is measured at boot time. The end stops are measured using the encoder with no limit switches. I am thinking about doing a bed calibration as well, but that is future work.

Bootloader:
a (new to you guys) bootloader that i developed for the DyIO controller. It is a serial bootloader that uses the same communication protocol as the printer or any other device for that matter. The bootloading interface is just another namespace that any device can implement. The toolchain for generating bootloader file is all written in Java and attaches to any Makefile build chain.

Hardware:
We have taken the idea of the Rostock and started from scratch using a full set of parametrics. A single file with measurements from the vitamins you are using is all that is needed to generate a whole new printer.

We have also made a library set for vitamins in OpenSCAD. This means we have special SCAD files that are only used to cut out voids for real vitamins. New ones can be added using the same model and committed back the the GIT. I have found that designing with this Vitamin Cutout system really speeds up development of our new printer. I can not wait to finish and try another design using that framework.

The hardware is not to Alpha yet, but the electronics and Firmware/Communications are already rolling. I will be doing a demo of our printer board and the DyIO (a bowler communication system development module) at the NE RepRap meetup tomorrow. I hope to see some of you there!

The OpenSCAD files can be found here:
https://code.google.com/p/the-technocopia-project/

The Firmware can be found here:
https://code.google.com/p/neuron-replicator/

And the communications library can be found here:
http://code.google.com/p/nr-sdk/

Kevin, I developed an extensive OpenSCAD hardware library here -> https://github.com/sjkelly/Magpie. It might help you, but I hit a lot of dead ends with importing parameters and such.
I have been working on a project called textcad (formerly called parametricCSG). I renamed it about 30 minutes ago, so I will need to update the naming. https://github.com/textcad. Anyway, it is essentially Python bindings for OpenSCAD, but done slightly different. We serialize the Python into JSON files which are then parsed to .scad files. The rational for doing serialization to JSON is that any language can become a CAD development tool under the condition it can implement the member definitions and be serialized. I am still developing the paradigm and learning much about software development.
What is currently working…
-ODS parameter files, exported to JSON, imported into modules. This makes expanding libraries super easy.
-All 3D primitives and operations from OpenSCAD.

Today I explored the ‘subtractive’ method you describe here. I was able to add an argument to the constructor which states whether or not the component should be for rendering or subtraction. This let me use the ‘hole’ method (or ‘polyhole’ method in Magpie) which has the radius set to the apothem and correct facet count. I think this might interest you.

Sorry for the wall of text. Can’t wait to get back to the woo and check this out!

What is the advantages of using servos ?
Are they not much more expensive than steppers ?

@Shachar_Weis Servos are cool because they can span a whole range of price and performance all in the exact same package. The ones we are using are $3.75 and a whole axis (servo, encoder board, magnet and cable) is $18 in quantity of 1 and less than $10 in quantity of 1000. You can also get high torque servos, high speed servos all in the same package. Also, the electrical interface is supported for large motors like kiloamp DC motors or even brushless AC motors (like R/C airplanes). Any of those can be used by the ServoStock board with no modifications in firmware or hardware, just a different PID configuration.