Here’s a beautiful desktop CNC mill which had one big drawback: it used a proprietary interface for driving it. To increase the flexibility of the tool it was hacked to work with G-Code.
The project is a Hackaday Hackerspace Henchmen submission from rLab, the Reading Hackspace in the UK. [Barnaby] explains the entire project after the break. The machine itself wasn’t altered, but a translator script was written in Python after capturing a bunch of packets and working out the protocol. This script listens for G-Code and does the translation into the type of commands the machine is expecting to receive.
If you know of a CNC hack from your own hackerspace send us the story for a chance to win some loot.
One of the first tools Reading Hackspace received was a small but sturdy 3-axis CnC Mill. It was designed for school use so was fully enclosed with lots of interlocks; ideal for training. Despite its limited work area the mechanics are nice with strong bearings, NEMA23 motors, and a 1/2 horsepower spindle. As you can see from the second picture the drive electronics are particularly neatly wired.
Denford also supplied some closed-source software to control the mill. This software is serviceable but we wanted something we could adapt to our needs. We now have several other machines running g-code (the Mill itself shares a bench with two RepRaps) so it seemed a pity it was stuck with a proprietary protocol.
One option was to simply replace the controller on the Mill. However as the current controller was working this seemed unnecessary. Another interesting option was that part of the firmware can be uploaded from the host software as a Mint Basic source file. This would have allowed us to change the meaning of some messages, but the actual structure of the communication messages is handled elsewhere so we could not have added G-Code support. In the end we fired up the official software in Wine and logged all the communication going though the serial port to disk.
As it turned out the protocol was relatively simple, small packets with a simple XOR checksum and often an acknowledgement back from the Mill. Once we realized there was a firmware interlock that you couldn’t move an axis until it had been homed it was fairly quick to get some basic motion out of the mill.
Next we wrote a simple Python program that created a virtual serial port where it listens for G-Code and in turn sends the messages the mill expects to the real serial port. This allows us to drive the Mill with the same interface we use on the RepRaps, and use PyCAM to generate the G-code.
Lucky PyCAM and most modern CAM programs actually only output a very simple sub-set of G-code. Rather then specifying tool offsets etc. it precomputes everything down to a simple list of co-ordinates to move to. This ensures that our G-code interpretor could be very simple yet still cope with anything PyCAM produces.
The only other thing that nearly caught us out (so far), is that some commands (e.g. spindle stop) aren’t buffered, so you have to poll the mill to ensure it has finished the proceeding cuts before you can send them.