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.
19 thoughts on “HHH: Sniffing Proprietary CNC To Hack In G-Code Support”
finally some info on this type of cnc machine, we have had one at my loocal school that we got donated and lost the software for it finally we can use it without paying hundred of dollars
hahaha nicely done!
poor proprietary controller will go to the un-used programs list
It looks like a Sherline. I think they come with LinuxCNC now.
It is a shoreline, but many companies took the basic mill or lathe and made little trainers out of them for schools and hobbyists. I had a lathe version, can’t remember who made it. I ended up pulling the brains out of it and installing a stepper driver and using Mach3.
Macona, are you the same Macona as on photonlexicon? Robotarmy here and this is at the hackspace I started where we play with all the lasers! Thanks for the tips on the spectron, there’s some more vids on our site.
Im pretty much any macona you see on any forum. HSM, PM, PL, etc.
I does indeed look like a Sherline.
I do like the comment on the link stating the OS doesn’t matter, what matters it that it does the job.
The OS only doesn’t matter until you begin using CNC, then it matters, unless how the job is accomplished doesn’t matter.
Read the link.
He gives the reasons for switching to LinuxCNC (pre-Mach3 perhaps, and certainly pre USB controls), and then states he has no idea what his ‘real’ CNC machines run on, and that he doesn’t care.
They work and that’s all that matters. Arguing that it matters is fanboi-ism.
Looking thru their site, it seems rather antiquated and full of questionable information. The stepper motor controller doesnt use SMD devices, they rant about Windows being a poor OS, how only a parallel port can be used because USB is too slow, and recommend transferring files with a floppy drive. If they’re trying to sell CNC mills for about $3k you’d think they could at least update the site once every 10 years.
You can’t use USB for real time control because USB does not support timing. The speed has nothing to do with it.
That’s not how USB controls work.
They don’t need the PC to operate as they process the g-code themselves and control the motors. The PC is only needed as the interface.
You can also get Ethernet based controls, so you can control multiple machines from one PC, a bit like printers.
(Attempting to control a parallel controller via a USB-parallel converter will fail due to timing issues)
You could use a USB microcontroller and have the mcu process the gcode. Do computers still come with parallel ports anymore? I know my eVGA X58 Triple SLI does have one on the rear panel and I doubt there is a header anywhere.
doesn’t have one*
That’s what the USB controllers are, the uC does all the processing rather than the PC doing it.
“USB can’t do CNC” has been untrue for a few years now, eg http://www.planet-cnc.com/index.php?page=hardware.
You still get a few motherboards with parallel ports, but they’re becoming rarer. A parallel card is only a few dollars so no big deal.
SMD devices are hardly known for their power handling capabilities either. Sure they make SMD motor drives but they suck for driving larger motors. You need something that you can bolt a heat sink onto. SMD being stuck on the surface of a board makes that difficult.
CNC isn’t very new, and not much has changed in it in the last 10 years either really. But they should update the name of the software suite they’re shipping, it isn’t EMC2 anymore, now it is called LinuxCNC. Apparently there is a firm in Africa that uses the name EMC. They slapped the EMC project with a cease and desist notification too.
“Rebranding name change
Due to a trademark dispute, after EMC 2.4 the project will be referred to as LinuxCNC – A longer but more descriptive name.”
Although in Sherline’s defense they might be shipping an older version that is still called EMC2. EMC2 is only up to version 2.5.3 now. 2.4 really was fine. I think 2.4 has the Axis front end. Here is the changelog
There is a lot more than the motor drivers on their board, from the passives to whatever the DIP chips in the sockets are.
I’ve seen a few of them on ebay for sale for under 1k. I thought for that much minus the headache of shipping it would be a neat package. Not to be a know it all but if you do have one of these things you could always just get rid of the controller and keep the rest of everything. It would be a hundred or two more but it would otherwise work nicely.
Well for a monkey such as my self that hides behind GUI and isn’t a programmer it would be easier.
Please be kind and respectful to help make the comments section excellent. (Comment Policy)