Hello All,One of the many side projects I've been working on lately has now come to fruition! Its name is ReplicatorG, and it is an open source RepRap controller based around GCode. It is designed to solve many of the problems that I've run into when working with the current state of the art RepRap control software.
1. It is easy to install. Its forked from Arduino, so it comes with the simple installation.
2. It is easy to use. It comes with a gorgeous user interface, again courtesy of the Arduino project.
3. It is modular and expandable: It is built from the ground up with a Driver system to make adding support for new electronics systems and new protocols to be very simple.
4. It takes GCode as input, so you can use any one of the awesome GCode generators out there.
5. It is generalized, so you can use it for more than just RepRap: you could easily control a CNC machine with it.
6. It does one thing, and one thing only: control a RepRap machine. It doesn't try to do everything, and leaves the hard slice/dice work to smarter programs.
The first version is being released today, so please download it, give it a try, and let me know if you find any bugs. You can find out all sorts of into on the Replicat.org website.
Once again, Zach, you rock! This thing--so far as I have explored it--is amazing. A much needed development/fork for the community. Keep up the good work!
ReplyDeleteDemented
Great stuff!
ReplyDeleteThe more I think about it, Zach, the more G-codes seem technically important. I don't just mean because they are standard and they separate the path generation from the control (though both those are really high priority), but because they easily allow you to generate the layers in an order different to that in which you print them in.
Specifically, to do support material, you have to generate the paths from the top downwards, and then to build (as always) from the bottom upwards (see previous posts about the polygon set-theory ad naus.). Writing each layer separately as G-codes into /tmp (o.w.e.) will easily allow them to be subsequently stitched together in reverse order into a single file.
Just what we need. In particular, I can now get ABS foundations to separate reliably from the built object. Clearly that is all one needs to do (apart from the geometry...) to be able to use ABS as its own support for overhangs too.
Neat. There's just one thing I can think of that would make this more useful is a plugin system to allow for different import types. For example, a plugin could take xml input (discussed as a possible intermediary stage). Even more ambitiously, skeinforge could be loaded as a plugin and import stl files directly.
ReplyDeleteAlso, I loaded the simulator up with a gcode file and it seems that lines are drawn instantly, not at any kind of simulated speed... this seems counterintuitive to me?
Anyway, this software fulfills a much-needed niche as-is. Great work.
Hi, Zach:
ReplyDeletethanks as always for your contributions!
This is interesting because I came to the same conclusion as you did-- "itd be great to be able to take gcode and run any machine". But, I ended up choosing to use EMC ( www.linuxcnc.org ) for the task.
Can you compare/contrast ReplicatorG with EMC, which I use for machine control?
Thanks a lot Zach, hope to test it soon :)
ReplyDeletethanks for the kind words everyone!
ReplyDeletekyle c: i'd love to add support for that in the future. i'll start a TODO list for future features, and i'm very accepting of patches ;)
also, the simulator is very barebones right now. i need to add a proportional delay to the simulator, colors, etc.
this release was just to get it out to the world for comments and to get people using it. its definitely functional. i plan on making it really really awesome, so stick around =)
dave:
ReplyDeleteEMC is extremely powerful, but there are some drawbacks.
EMC is an application that only runs on their special flavor of Realtime Linux.
ReplicatorG is much more lightweight, and is a cross-platform application. Its intended for much wider use.
EMC is much more mature and has many more drivers, support, and history. I don't know a ton about it, but that is the major difference.
Unfortunately their requirements vs. my requirements just do not match up. I absolutely wanted it to be cross-platform, whereas they need you to install RTL. I intend to put a RepRap on every desk in the world, and asking people to change their OS is a big hurdle to that.
Hi, Zach:
ReplyDeleteI understand. Though EMC has made big strides with their ubuntu-based distro, it does not make for a very lightweight installation at all, and it is definitely not cross-platform.
That said, emc might work well as a "packaged" solution-- i think an EMC install would fit easily onto a very small single board computer. Tivos, Linksys routers, and many other "appliances" do just that.
It woudl be a far cry from easy to use though, and from the looks of it your GUI has much gains on EMC in the ease of use department...
Most excellent as ever.
ReplyDeleteThe plug-ins sound realy cool and could be an excellent place to put a digitizing plugin using the touch probe tool head.
Umm a Post/Ghostscript plug in would be great too to run it as a pen plotter and plot etch/photo resist direct to sensitised PCB's
Almost certainly a gerber plug in too for PCB production.
All rather wishful I guess but it would be more awesome still.
Zach, I have one quick question...
ReplyDeleteDo you ever have time for sleeping? :)
aka47: GCode actually has support for scanning / probes, and its one of the things i'd really like to get working on. a killer app for RepRap is definitely going to be a Scan / Print funtionality.
ReplyDeletethe other plugins would be pretty straightforward too. interested in digging through the code?
chris: every month or so ;)
Yeah pretty much.
ReplyDeleteI would like to get my Darwin PlyRap further along before diverting. Plus it would be great as a test bed.
Just looking at R.2R networks for a revised tool head.
I think Greenarrow is interested too and has some code to contribute.
I think it would be tremendously beneficial to have the toolchain be fairly standard on what the inputs and outputs of each "block" actually is.
ReplyDeleteThat makes it easier to use a different controller, or a different slicer, etc.
ReplicatorG has the block laid out kind how i was thinking:
stl/objectmodel/surfacemesh --> processor program, platform independent: slice, support, rafts,
--> gcode
--> machine control software
--> machine
the gcode needs to have a custom Mcode set for extruder temps, and the processor needs to have machine specific parameters built into it.
To me this seems to be a good separation of concerns that would still allow it all to run on one platform independent host if you wanted it to.
Wow, I've just made a dremel toolhead and you come up with this! Zach, you made my day!
ReplyDeleteHope I can mill (isolation route) a PCB soon. This software was a major missing piece...