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.