We have had a good few spendy problems with our laser cutter over the past few months and it’s one of our most heavily used tools. We need to build up a bit of a kitty to make sure we can replace laser tubes (like this) and power supplies (like we had to recently) as well as mirrors and other consumables.
Step up Andrew Jacobs who built a PIC based monitoring solution, it monitors a pull up on the laser cutter PCB which pulls 8ve when the laser is firing. Andrews design monitors this and keeps a log in the eprom whilst displaying the session usage and overall usage so that members know how much to put in the pot after using the machine.
Simon Green designed and made the case which looks particularly good
The next stage will be to tie the system up to our member RFID cards so we can manage the tabs!
This project by Jon Totham is super cool, using cheap foam insulation boards from Wicks, static grass and acrylic paint with a tad of airbrushing the results are amazing not just for Warhammer but could be really cool on model railways too.
The laser cut buildings are also pretty awesome.
Jon is going to play a bit more with lasers and foam and nitrogen to see if he can get some cooler effects so lets watch this space!
Andrew Jacobs has been re-purposing a LED display board from an arcade machine for the hackspace. He built a new controller board for it late last year and spent sometime over Christmas writing some firmware to control it. This video shows the current state of play.
In the final version the small characters at the start will scroll in from the top and bottom of the display rather than sideways. He also need to make the characters proportional.
RLab and the TVRRUG had a super busy and very successful weekend exhibiting at the Model Engineer Show in Sandown Park. We also had the opportunity to show off our 3d print of St Pancras Train Station which was very well recieved. The event was a great success and we certainly hope to take part next year. Thanks to Malcolm and Ian for organising this event and everyone else who took part.
Photos, videos and more:
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.
David ran a ADSBScope with a £16 DVB-T usb dongle to track ASDB transponder signals from civilian aircraft flying overhead the rlab – v cool!
As seen on the Pi Site! http://www.raspberrypi.org/archives/4088