Friday, October 17, 2008
ReplicatorG 0002 Release
Today has been a busy day... I'm also releasing ReplicatorG 0002. If you're not familiar with this software, its a generic GCode host software designed for use with RepRap machines. You feed it a GCode file, it parses it and then uses a driver based system to control a RepRap machine. Its simple, modular, and expandable. Its based on the Processing/Arduino codebase so it has a nice, friendly GUI system. Its also cross-platform straight out of the box. The installation process is pretty straightforward: download it and run it! You might have to install Java if you dont already have it.Anyway, here is the changelog:
* add units to simulation window
* add proper bounds to simulation window
* add warmup/cooldown to machine config
* add simple exerciser / status window
* add color to simulation window
* add up/down arrows to simulation windows
* implement Peter Edworthy ideas on driver instantiation
* have simulation move to a proportional wait time
* fix build time estimation
* add estimate menu item
* add basic machine configuration stuff to XML (axes, resolution, extruders, toolheads, clamps, etc.)
* move to a controller/model/driver system.
* Add an extruder section (temp, start/stop extruder, extruder direction, extruder speed)
* added text boxes to control/display feedrate data
* fix shutdown of driver
* fix windows icons
You can download ReplicatorG from google code, or head over to the Replicat.org website to learn more about the software.
Comments:
<< Home
Zach, do you have time to sleep between all the releases? :)
I have a question regarding G-Code, just to see of I understand the basic of it:
when generating G-code you have to be aware of the machine (it's capabilities and limitations) that will use the G-code, right?
So the flow is:
Model (1)-> STL (2)-> G-code (3)-> ReplicatorG (4)-> RepRap
(1) is done by the modeling software
(2) is by skeinforge (?)
(3) is trivial
(4) is via a driver
Did I screw up the process somewhere or did I manage to get the jist of it?
-Leav
I have a question regarding G-Code, just to see of I understand the basic of it:
when generating G-code you have to be aware of the machine (it's capabilities and limitations) that will use the G-code, right?
So the flow is:
Model (1)-> STL (2)-> G-code (3)-> ReplicatorG (4)-> RepRap
(1) is done by the modeling software
(2) is by skeinforge (?)
(3) is trivial
(4) is via a driver
Did I screw up the process somewhere or did I manage to get the jist of it?
-Leav
hey leav,
only when i have to.
essentially yes. you could easily write gcode that would make the machine go too fast, extrude too fast, heat up too hot, or move beyond its bounds.
thats why its important we have safeguards at every level:
physically, we have opto endstops on both the minimum and maximum of each axis
in the firmware, we have a maximum feedrate for XY and Z which keeps you from moving it too fast
in the slice and dice we input various parameters to ensure that the gcode it generates is up to par with your machine.
finally, in ReplicatorG there is a modeling system that attempts to model your machine accurately, and hopefully someday we can use to prevent the machine or gcode from doing damage to said machine.
some of this is still in the rough and early stages (like ReplicatorG) but we're working on improving it every day.
only when i have to.
essentially yes. you could easily write gcode that would make the machine go too fast, extrude too fast, heat up too hot, or move beyond its bounds.
thats why its important we have safeguards at every level:
physically, we have opto endstops on both the minimum and maximum of each axis
in the firmware, we have a maximum feedrate for XY and Z which keeps you from moving it too fast
in the slice and dice we input various parameters to ensure that the gcode it generates is up to par with your machine.
finally, in ReplicatorG there is a modeling system that attempts to model your machine accurately, and hopefully someday we can use to prevent the machine or gcode from doing damage to said machine.
some of this is still in the rough and early stages (like ReplicatorG) but we're working on improving it every day.
Zach,
I just downloaded replicatorG, and I may be missing something obvious, but I don't see info on what replicatorG expects to talk to: PIC vs. Arduino (I'm guessing arduino), and what firmware (e.g. version#) it needs. If there are options, saying a bit about what can work, and how would be much appreciated.
Context: I now have X and Y axes of my machine ready to go (Zoming soon), and I really want to get them moving (esp. cutting extruder parts with a rotozip.)
Thanks much for your efforts,
Larry Pfeffer
ursine at gma1l d0t c0m
I just downloaded replicatorG, and I may be missing something obvious, but I don't see info on what replicatorG expects to talk to: PIC vs. Arduino (I'm guessing arduino), and what firmware (e.g. version#) it needs. If there are options, saying a bit about what can work, and how would be much appreciated.
Context: I now have X and Y axes of my machine ready to go (Zoming soon), and I really want to get them moving (esp. cutting extruder parts with a rotozip.)
Thanks much for your efforts,
Larry Pfeffer
ursine at gma1l d0t c0m
Zach,
Never mind. I see it *is* documented under the serial pass through driver, and works with the arduino Gcode interpreter: http://replicat.org/serialpassthrough-driver
Sorry for posting before fully RTFM!
-- Larry
Post a Comment
Never mind. I see it *is* documented under the serial pass through driver, and works with the arduino Gcode interpreter: http://replicat.org/serialpassthrough-driver
Sorry for posting before fully RTFM!
-- Larry
<< Home
