After I switched my RepRap to run on g-codes a few weeks ago, I started writing little Python scripts to do various things like lay down a raft, shut the extruder off and move the platform out of the way, extrude in preparation for a build, and send a g-code file to the controller. All of the scripts rely on a common module that sends a series of g-codes to the controller and waits for acknowledgements. The code has grown and become more interesting:
- I optimized the communication by having the host send enough commands to keep the controller’s 128 byte serial buffer full. The host does this by sending commands before an acknowledgement has been received for commands sent earlier. This works surprisingly well and helps the controller handle many commands per second, which is important for drawing short segments.
- I added code that automatically resumes a build where it left off if the controller restarts during the build. I implemented this because my controller spontaneously restarted several times this week in the middle of a build. I implemented this feature by creating a simple, fast machine simulator in the host. To resume a build, the code resets the controller, sends the g-codes necessary to put the machine back in the state recorded by the simulator, then resubmits the commands the controller never acknowledged. This also works surprisingly well.
- I created a g-code runner that can resume any stopped build. I implemented this because yesterday my controller not only spontaneously restarted, it actually lost its firmware in the process! (I then discovered and fixed a loosely connected ground wire which could have been the culprit all along.) Now I can stop a build at any time, turn off the power, disconnect the USB cable, clean the heater, restart the host computer, turn on the power and reconnect, upload a new firmware, run some g-code to test and prime the RepRap, and finally resume printing exactly where I left off. It’s kind of magical to see it actually work.
So now I have worked around the most common ways a print can fail partway through. This should make it much easier to work through problems with large builds. I can even stop a build with ctrl-C, shut everything off, go to bed, and resume the build another day! I definitely need to start doing that. 😉
By the way, I had to make a minor update to the g-code firmware to make it possible to restore all of the machine state: the G92 code needs to notice and use the X, Y, and Z parameters. The fact that no one has yet done this to the firmware in Subversion suggests that none of the other g-code runners can resume a build like mine can. So I guess this code might be useful to the community. Speak up if you’re interested.
3 thoughts on “Home Grown RepRap Software”
Hello! I’m just another software engineer here in Utah, who happens to be an avid GNU/Linux user… and I’m curious about the RepRap. I’ve read through the output of the dynamic parts-list generator, and the build looks somewhat intricate, but fairly straightforward.
Basically, my question is whether or not you’ve reached a point where you’d be willing to reprap repraps (to the greatest extent possible) for other locals in the community. I’m not sure what the cost would be for a requisitely sized spool of plastic/resin (or if it’s possible to “get in” on a bulk order with other interested parties), to build a full-reprappable parts set for another (Darwin, I assume) machine… but I’m very interested in doing so, and this is the first I’d heard of a Utahn with a reprap (basically) up-and-going.
I do know that I’d have to buy a bunch of the gear anyway, the hardware, controller-board & wiring, extruder head, etc. I’d really rather not go the path that you’ve already taken (laser-cut repstrap parts), even though your kit will likely be of higher-quality, because the geek-factor is high for a second-gen machine 🙂
I’d be willing to buy all necessary materials ahead of time and just bring them to you (spool of plastic thread, I assume??). Of course, I can’t “deliver” the time & attention necessary to babysit such a build (and, of course, would NOT expect the parts to be filed-down & groomed, I have tools for that), but perhaps that good will could be generated by wife-made cookies or some such tasty morsel.
Anyway, cheers & if you ever find yourself wanting to build a box of parts to sell to other folks in the state, please add me to your list!
Great, that’s what I wanted to hear, Sunit!
The build quality from my machine is not yet quite high enough to make parts for another machine. I’ve solved the problem with sticking the parts to the bed: all I have to do is lay down a layer of ABS slowly on 1/4″ acrylic. Laying it down slowly causes the acrylic to melt very slightly, forming a good temporary bond with the ABS.
The main problem now is warping. I am about to try the oven roasting bag idea that Adrian has been talking about. He says that putting the whole build in a 60C environment eliminates the warping. If that works, I should be able to start producing real parts. Stay tuned!
I’m sorry to hear about parts warping. The oven roasting bag idea sounds like a nice cheap fix!
If that doesn’t work, and the bed temperature is an issue, you may try to find a way to affix an AC-powered car battery warming blanket beneath it; I haven’t seen anyone suggest that yet, but they are inexpensive (usually $50 or less… oh, and if that idea works, then it was *my* idea 😀 ). Though, I doubt the blanket will get you up to 60C on it’s own, you could accompany it with a heating element from above, such as an incandescent lamp or hair-dryer (I *have* seen pictures of that one!).
Anyway, thank you for replying. I posted my first message (and this reply) with my e-mail address; please shoot me a message if your rig reaches the point of self-replication, and we’ll “talk turkey”.
(Ok, please forgive the bad roasting bag pun, I couldn’t resist)
Comments are closed.