If we get a dusting of snow this year, there will be at least one person with a massive smile on his face. Stuart, one of our members and founder of NADHack – Newbury and District Hackspace – will be poised and ready to launch his ski-bike on an unsuspecting world.
No, nothing dangerous-looking about that
It started out life as a cheap aluminium-framed Reebok-branded full suspension bike. All mechanical components were removed (some quite forcefully!) and the brake mountings, shifter mounting etc were ground off. The pedal shaft was replaced with an arrangement of steel angle which was ground into the footpeg shape and welded using the Kempi MIG welder. The footpegs are exceedingly strong!
Simon Green has put together some amazing interactive shots of our facilities (although they are still a work in process!). Simon backed the Galileo Kickstarter and was after quite a while delivered one of these amazing devices that took the views you can see embedded below.
Here we have our community room, this is where we hang out on Wednesdays and work on projects from software and hardware development. As you can see there is a whole host of electronic scopes, soldering stations, wires, cables, components and desktop PC’s.
In our machine room members have access to laser cutters, CNC machine, vinyl cutter and multiple 3D printers.
Our downstairs workshop with tons of room has equipment for woodwork and metal work with chop saws, a Harrison Lathe, pillar drills, band saws, bench grinders… you name it and it’s probably here – if it’s not post on our mailing list and a member can usually find you it!
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.