The project is taking a step in a different direction, before I stated that the project would run on several software levels to control various functions of the printer. The multilayered design/architecture will still be utilized but in a different manner.
The printer that is being used for this project is the
Rap@Home Cartesian Box (Incorrectly Identified as the Fab@3D Cartesian Box in previous posts), which is part of the RepRap printer family. The fact that this printer is part of the RepRap family led us at Neuron Robotics to take a look at the open source software that all RepRap printers use written in Java. As it turns out there is a
GenericRepRap.java class to be used for adding support to the RepRap software for other printers. This discovery has moved the project forward a few steps, the initial intention was to have a software layer written to control the printer that would interface with the RepRap software but since the RepRap software contains the components (Java Interface structures to be exact) to add support for other printers I only have to create an implementation of their framework to support all the functions of the
Rap@Home printer .
These new developments eliminate the need for a custom software layer to interface the printer's functions to the RepRap software instead the RepRap software will be able to do all of this. After the printer's functions are implemented using the
GenericRepRap.java template the low level C code component needs to be written and interfaced to the implementation of
GenericRepRap.java representing the printer. At the time of writing this I do not believe it is necessary for an additional software layer that would sit between the C level and the
GenericRepRap.java implementation I believe that all the C level code will be able to be invoked and addressed from the implementation of
GenericRepRap.java.
Essentially after the implementation is complete the ReRap software can be loaded up and the printer should function entirely as desired and work just like any other printer supported in the RepRap software.
Just some pictures of the printer itself and the hardware controlling it:
 |
| The Printer, Rap@Home Cartesian Box, currently in need of a new print hed |
 |
| The naked DyIO that is being used as the controller of the printer, all this custom software is for this little guy to drive this whole printer and then some. |
 |
| This is a logic controlled relay power switch, it is plugged into an available port on the DyIO so that the DyIO can turn the power to the printer on and off. |
 |
| A Shot of the whole set up |
 |
| What a DyIO looks like in its Casing, this is the one issued to me for testing purposes and development this summer |
I'm sorry you stopped updating your blog. I wish I'd seen it earlier. That said, I have a few questions.
ReplyDeleteIs the SDK for this DyIO this compatible with open source licenses? GPL? Can I distribute modified versions of it to my friends? How about the software you've written while working for them?
And here's another big question: How much does this thing cost compared to an arduino mega?
And now to try to answer a few of yours. I'm thinking you've already found most of these answers, but whatever.
The java software isn't used by "all repraps" Personally, I despise java in all its incarnations and refuse to use it if there's a halfway workable alternative.
The software for repraps is generally divided into three parts: slicer, host, firmware.
The slicer takes the model, usually (always?) an .stl file, and generates g-code or other machine compatible instructions.
The host sends those instructions (usually over usb, but nophead uses UDP over ethernet for example) to the electronics. Most hosts also include a graphical tracking of the build progress. Some, the "official" (reprap doesn't really do Official, thus the quotes) host software included, also include a slicer. As far as I know, all hosts that do include a slicer still allow you to load a seperate g-code file as well.
The firmware accepts g-code (or whatever) and actually deals with timing stepper pulses, PID control of heater elements, etc.
The "official" firmware is known (by me, anyway. Others opinions vary, and some even get it right, and agree with me) to have several problems. It's way to big and clumsy, it's timing sucks, it doesn't handle queueing commands adaquately, etc.
I recommend teacup. It's much easier to grok, especially if you're a firmware guy. It's written in C instead of C++, and is designed by somebody who has actually written firmware for small 8-bit processors for a living. It's much better, works fine, and is still under active development. i.e. bugs will get fixed and features are still being added, even if they won't all fit on a diecimilla anymore.
Let me see if i can answer some questions about the DyIO for you:
ReplyDeleteThe SDK is all dual licensed, BSD for non commercial use, and contact us for a commercial one. All the code for our Java SDK is available here: http://code.google.com/p/nr-sdk/
The cost of the DyIO is $150 and that includes feature-adds and firmware updates forever. We do active development and find and fix bugs and add features with releases about once a month.
As for the requirement for the "firmware layer" to be accepting g-code, i would like to disagree with that as a good model. We have designed a far more modular system. We have taken advantage of "abstract" classes to wrap together most of the "Printer" interface. There are only a few simple abstract methods that the implementation needs to fill in. By doing this, we have dropped the bar of entry to making totally custom printers.