Making a digital board game from paper and copper tape

Earlier tests proved successful, but actually making our board game modules is still a bit fiddly (and, let's not pretend, about a quid - ok, 96p - more expensive than it needs to be!). So this time, we tried a design whereby the base of the board would be slightly magnetic, and the playing pieces contained steel/iron pieces. This allowed us to use a much thinner "membrane" between the two layers of copper strips.

We printed our board game layout and put some strips of copper tape along a sheet of paper, following the design, spaced 25mm apart (centre-to-centre). The copper tape crinkles and creases very easily, and even when pulled tight before sticking it down, there are loads of little bumps and creases in the tape. This is no good for us, since the gap between the two copper layers is going to be only a sheet of paper thick, so we need the copper traces as flat as possible.
Luckily an old trick I was taught many, many years ago (while still at school and working weekends in a stained glass craft unit) came in handy: simply rub the tape, quite firmly, with a firm-but-flexible tool. Back in the day, I used to use a wooden peg - it is hard enough to rub the copper tape flat, but not so harsh (like the edge of a steel ruler, for example) as to damage the tape. Our scissors have a "comfort-grip" handle, and they worked perfectly!

(note how the top strip is much flatter and shinier than the strips lower down, which have yet to be rubbed flat)

After this, we loaded our board design into CraftRobo and cut out the circles from a sheet of sticker paper (in the final version, we'll use double-sided sticky sheets, but for now this was all we had to hand).

(ours is one of the very early CraftRobo machines, so the cutting force is pretty poor, compared to later machines. However, it's fine for carving through a layer of sticker paper)

Once the sticker paper was cut, we "weeded out" all of the little circles using a craft knife.

We're still not sure if this was a good idea or not - it made the final sticker quite difficult to handle, but the alternative would be to leave the circles in the sticker (though some may already fall out as the sticker is peeled off the backing sheet) but then they would need weeding off the sheet with our copper tracks, which may be just as cumbersome.

After placing the sticker sheet over the paper with our copper tracks on, we cut and placed little strips of double-sided tape in-between each of the circular cut-outs. In future versions, this should already be in place before cutting out the circles.

The top sheet, with thinner copper tracks at 90 degrees was stuck down, on top of this. It is important while performing this task, that both layers are pulled taught, so that no wrinkles get caught in either of the two layers (which would create a permanent short between two layers, where they buckled together).

Each "square" on the board was then tested using a multimeter set to continuity testing.

First checking that a button press was recorded, and then that it returned to "normally-open" when released:

So far so good. But we did notice one problem - we're effectively working with three sheets of paper, stuck together in parts. During testing we didn't stick the bottom layer down to anything, and if part of the page was allowed to curl (creating a wrinkle somewhere in the paper) then one button, right in the middle of the board, became unreliable. When released, the continuity tested recorded a partial signal:

This is only to be expected, and we can explain why it's happening - but it just goes to show that we need to take care during the construction of each board section; every part needs to be as flat as possible and there's no room for error when sticking the middle membrane down. Even the smallest wrinkle could cause parts of the board to stop functioning properly, so we need to be extra careful.

But, errors aside (we don't mind errors so much if they are repeatable, expected and can be explained) it was a pretty good test for our board game idea. And much quicker (as well as cheaper) than making multiple PCBs, soldering SMT shift registers, messing about with pin headers and ribbon cables and all that! Our last test, before we decide for sure if this is the way forward, will be to create a top layer from photo-quality inkjet paper (so the playing surface can be printed on the top side) and call in a few favours from Nick at CustomStuff to see if we can get it laminated too.

We expect a laminated playing surface to be slightly less flexible than just a sheet of paper, but this in turn might be useful as it will help ensure that the top layer is flat as it is affixed to the rest of the board.

Simplifying the digital board game

We've had our silkscreen made, and got a working prototype for a board game "module" with shift registers, leds and printed circuit board - but there's something that feels a little uneasy about the whole manufacturing process - it's very long winded, requires a lot of effort, can easily go wrong and- ultimately - very expensive.

We're determined to come up with something that's cheap(er) and easier to make.
So the first thing to do was simplify: lose the leds and concentrate on making a large input matrix. Suddenly we were back to an earlier idea - copper tape and cardboard!

The basic idea is to create a membrane style matrix - criss-crossing lengths of copper tape and separating them with a "mesh" between the two layers (a layer with lots of larger holes cut into it). Then by applying pressure onto one surface, the two bands of copper tape touch and create a crude pushbutton. A description of this approach can be found here (http://forum.arduino.cc/index.php/topic,13091.0.html)

Unlike a push button matrix, we don't have a great amount of force pressing onto the contacts, only the weight of the playing piece, to activate the button. What we needed was a cheap way to pull the playing piece down onto the contacts - magnets of course! If we placed a ferric-based (steel/iron) board under our playing surface and embedded a small magnet in the bottom of each playing piece, there would be enough "pull" on the piece to drag it down, making the pushbutton contact. But A4 sheets of steel are not easy to come by, even in the BuildBrighton hackspace.

Now not everyone appreciates that the change in UK coinage in about 1992 meant one important thing - changing from a cupro-nickel to a copper-plated steel for one penny pieces means that any penny coin made after 1992 is attracted to a magnet. So we set about making a matrix of penny pieces:

On the lower board we ran some tracks of thin copper tape. Over this we placed a laser-cut separator, made from 2mm mdf (a penny coin is about 1.6mm thick). Into these holes we dropped some one penny pieces

The penny pieces sit slightly recessed from the top surface, so that when we glue another layer of copper strips onto this, there is a slight gap between the copper strip on the top layer and the piece piece below.

Note the slight gap between the top of the penny and the laser-cut board surrounding it - this will give us our deflection, allowing the top layer to flex, creating the button press, but - just as importantly - causing the top layer to return (restoring the air gap between the top and the penny) when released.

(of course, the keen-eyed will have noticed that we've drawn this top layer incorrectly - the copper traces on the top should be running the other way, at 90 degrees to the traces on the bottom layer)

With the top layer in place, we did manage to create a working keyboard matrix. But the amount of deflection was too great, even for a small, strong magnet. The buttons could be activated by pressing them with a finger, but placing a playing piece over the buttons yielded nothing!

So with a quick revision to our design, we got rid of all the pennies and used a sheet of cardboard as a separator, where the 2mm laser-cut mdf had been before. To make the base magnetically attractive, we simply stood the whole assembly on a small piece of galvanised steel, just to prove the concept worked:

This time, the results were much better!

Everywhere that we placed the magnet (when over a hole in the separator membrane layer) resulted in a positive connection. When the magnet was removed, the button returned to it's normally-open position. 

We're going to play about with different membrane thicknesses; obviously, a thinner separator will result in a more responsive board to play on and will also mean we can use a slightly less powerful magnet. It may even be possible to swap the magnetic parts over - using an A4 magnetic sheet as the base layer, and penny coins or washers in the bases of the playing pieces. We'll have to wait until our next eBay order is delivered in a few days time......

BuildBrighton HPC laser cutter

For what seems like months now, the laser cutter at BuildBrighton has been out of action. First the tube went, then the new tube cracked. Then a replacement tube went in but it wouldn't cut. Now it does cut, but only in certain parts of the cutting bed.

So a few months ago, a few of us clubbed together to pay for a second hand LS3020 laser cutter that was going cheap. It's always a risk, buying stuff like this second hand. But we were already familiar with the LS3020 (we've got one at Nerd Towers which works like a dream) so were confident it should be a half-decent machine.

Today, I finally located a Windows XP machine down at the hackspace and got NewlyDraw installed on it (NarlyDraw does install on Windows7 and I've had my laser cutter working with my Win7 notebook, but it's a pain getting the drivers working properly, so Windows XP is much more favourable). I don't know where the PCs at BuildBrighton go to - one day there's a glut of XP machines, the next, some bugger has put Linux on, or replaced them with Raspberry Pi's or something! But with a WinXP machine finally located, and NewlyDraw installed on it, there was no need to delay trying the machine out.

Amazingly, it cut, first time!
Not perfectly, but it did scribe a circle onto some acrylic (a fairly wide, melted shape instead of a circle, but it was definitely a good start).

At some point, someone has changed the optics in this machine, and put a different lens in it. The lens focal guide is much smaller than the one that usually comes with the machine (or at least, the one that comes with later LS3020 machines - this one was definitely an earlier model than the one we're familiar with, albeit very similar). This means that the cutting bed is much higher up, and the cutting head is very close to the material being cut. It also makes it very difficult to see the little laser dot, for lining  up cutting on a sheet which may already have shapes cut out of it.

One thing to note is that when the machine powers up, the cutting head goes to the top-right of the machine, not the top-left as one might expect. This is easily resolved using NarlyDraw - just move the head to -80,0 and when prompted, reply that you know this might make the head move out of the cutting area. The head should now move to the top left corner of the cutting bed:

We cut a few test circles, 20mm in size, in opposite corners of the cutting bed, to see if the alignment was good (if the alignment was out, we'd expect one corner to cut better than the other). The cutting was the same in both corners. We tried a few different settings - the power is controlled by a knob on the actual machine, the speed is controlled in software:

At 15mA and 12mm/sec, the laser almost cut through the entire sheet in one single pass:

The pieces could easily be pushed out, but a slight ragged edge remained in two points on the circumference of the circle. We needed either a slower speed or more power to get a perfect finish. In the end we settled on 20mA and 10mm/sec speed.

(pressing both laser buttons together fires a test beam which allows you to adjust the power setting and see the output on the dial above)

At 20mA and 10mm we got a perfectly circle (no ragged edges) which cut all the way through the 3mm acrylic in a single pass, and the circle fell away from the sheet when lifted out of the machine.

We repeated the cutting process in the opposite corner of the cutting bed, to check that the cutting action was the same (and thus confirm that the bed was straight and the mirror(s) correctly aligned). Both times, the circle cut exactly as we expected:

Placing one circle back into the hole it came from and rotating showed that the shape wasn't actually 100% circular. It started to bind in opposite corners of the hole (if the shape was totally circular, it show rotate freely with no binding at all)

The difference is in the regions of tens, if not hundreds of a millimetre - but it is possible to see. This suggests that either the mirrors are not exactly lined up, or one (or both) axis have a tiny little bit of backlash in them. It will take a bit of time of entering numbers, cutting and re-cutting shapes and measuring the results to reduce this entirely.

For now, we're happy that we've got a working laser cutter again down at the local hackspace. Someone else can take over now!

CNC testing with Mach3

It has taken a bit of trial and error and a good, old-fashioned, low-tech method of validating our CNC setup, but we're thrilled to see that it finally looks like it's working.

To begin with, we placed a pen (instead of a drill) in the z-axis and fiddled with the motor tuning settings in Mach3. We had no idea how many turns per unit (i.e. millimetre) we needed, so went with a default of 200 (assuming that the steppers were 200 steps/rev). The grid it plotted looked like we'd used inches instead of millimetres - the gaps between the dots were massive!

To simplify things, we replaced our grid with a row of three dots, using the g-code

G0 Z0
G0 X0 Y0
G0 Z2
G0 Z0
G0 X10 Y0
G0 Z2
G0 Z0

G0 X20 Y0
G0 Z2
G0 Z0

to draw a row of three dots on a sheet of paper. We checked our Mach3 settings and confirmed that we had, indeed, set the default units to mm and not inches. After measuring with a steel rule, we confirmed that the dots were not actually an inch apart either.

So we were pretty sure that the machine was set up for millimetres (but not 100% convinced) but had no idea of the leadscrew pitch. Inspired by Steve's coding method - where if something works but not quite, you keep applying multipliers and choosing different numbers until it's close enough - we set to work changing the values in the Mach3 settings. Firstly by reducing the steps per millimetre down to 100.

This time, the spacing between the dots looked better, but we were now about 12mm apart, not 10.
Reducing the steps per millimetre to 90 brought the dots too close together, but it seems that 95 is the magic number for our machine:

Each dot was perfectly 10mm apart - exactly as the g-code described.

(the pattern of dots in this photo shows a grid supposedly drawn at 0.1" pitch, but at 100 steps per mm, our machine drew them slightly too far apart. Repeating this later, at 95 steps per mm, resulted in a perfect 0.1" grid)

SVG to g-code. Now we're getting there!

Using a different coloured dot as our origin marker works perfectly!

And the great thing is, by changing the multiplier (at the minute we're using 25.4/90 to convert an image at 90dpi into millimetres) we can output our g-code in any units that the cnc machine requires.

One thing we have noticed, however, is that there's no real control over the order of the dots - the svg file appears to write them in the order they were drawn on the screen. That's fine for a simple example like this, but could be a bit of a nightmare when importing files from other applications.

The generated g-code (obviously) follows the drawing order of the svg file, which may not necessarily by the most efficient path between points.

By following the points in our svg file exactly, we would end up with a drilling pattern something like this:

So the last little bit of our project to do now, is to add in some path optimisations. We've already done something similar in the past, with our miniature CNC drill, so it shouldn't be a major problem.

Because our CNC is pretty accurate this time (the miniature one had loads of backlash because of the super-cheap stepper motors) we should be able to implement a "move to nearest point" routine to reduce the amount of time the drill head spends travelling from one point to the next (and hopefully reduce the overall drilling time for each entire board).

Inkscape makes complex SVG files

Now we've got a working SVG-to-GCode converter working, it's time to think about calibrating the CNC machine. So we drew a simple grid of dots, spaced 0.1" apart (standard breadboard distance) and saved the SVG before running through our gcode generator. And something peculiar happened; it didn't quite work.
All the x axis values for every dot were the same.

When we looked at the svg file, every single dot had the same x-axis value, irrespective of where it appeared on the screen:

Our entire group of dots still had a "master translation" applied to the entire group, but this didn't explain why all the x-axis values were the same for every dot.

Further investigation revealed that every dot had it's own individual transformation matrix applied to it:

Now it's worth noting that our PCB svg (generated by loading a PDF, generated by CutePDF from inside ExpressPCB) is noticeably different to this latest file: this file we created by drawing a circle then copy-and-pasting the dot(s) repeatedly until we had a grid of 6x6 drill holes. In the PDF, every shape was a "path" - even the circles that made up our drill holes. In this file, we had "circle objects" rather than paths and it was each of these objects that had an inline transformation.

Now what we really should be doing is updating our g-code generator to parse all different types of svg files. But then we're in danger of spending more time building our tools instead of getting something working to enable us to drill some copper boards and - ultimately - make batches of PCBs. So for now, we just use the Inkscape menu - Path -> Object to path - and turn all our circles into paths. Saving the file as a plain svg seems to fix the problem: every drill hole is now a path and there are no nasty inline transformations to deal with

 <g inkscape:label="Layer 1" inkscape:groupmode="layer" id="layer1" transform="translate(0,-962.35975)">
    <path inkscape:connector-curvature="0" style="fill:#000000;stroke:none" d="m 3.5433072,1050.5905 c 0,0.9785 -0.793196,1.7717 -1.7716532,1.7717 -0.97845717,0 -1.7716535523622,-0.7932 -1.7716535523622,-1.7717 0,-0.9784 0.7931963823622,-1.7716 1.7716535523622,-1.7716 0.9784572,0 1.7716532,0.7932 1.7716532,1.7716 z" id="path2985" />
    <path inkscape:connector-curvature="0" style="fill:#ff0000;stroke:none" d="m 12.543307,1050.5905 c 0,0.9785 -0.793196,1.7717 -1.771653,1.7717 C 9.7931964,1052.3622 9,1051.569 9,1050.5905 c 0,-0.9784 0.7931964,-1.7716 1.771654,-1.7716 0.978457,0 1.771653,0.7932 1.771653,1.7716 z" id="path2987" />
 
</g>

But there's still one last thing.
As you can see from the svg snippet above, the holes are now correctly spaced (the difference between x values is 12.54-3.54 = 9 pixels and at 90dpi, 9 pixels = 9*25.4/90 = 2.54mm or 0.1") but their absolute location is still incorrect (3.54 pixels = 3.54*24.5/90 = 1mm). Our first drill hole should be a 0,0 but the x-axis value is 1mm.

Even applying the "master translation" doesn't fix this, since the x-part of the command translate(0,-962.35975) is zero.

So what's going on?
If we read the path co-ordinates that follow the m command in the svg attribute, it looks like the path is being drawn from the right-most side of the path, to the left (the x-part of each of the first few curve points is negative, suggesting the path is being drawn from right-to-left).

Now we've no idea if this is going to be consistent for all shapes drawn in future, or what happens if the user were to copy and paste, then rotate or flip their image before exporting as svg. So the easiest solution we can think of is to place a dot at 0,0 and give it it's own unique special colouring (we're thinking black for now).

After parsing the entire document, we should have a set of co-ordinates for our black dot (the origin) which we can then add/subtract from every other dot on the board, to get the correct, absolute position for all our drills holes.

Watch this space........

Parsing Inkscape SVG files to create g-code

Here's a screenshot of our first test - and it's all looking rather encouraging!

I actually got the generate g-code (after parsing the SVG file and applying modifiers) to match the positioning of the objects in Inkscape - in the example above, you can see that the x co-ordinate is the same in both the VB app and in Inkscape.

The y value is different but only because Inkscape insists on putting the origin (0,0) at the bottom left hand corner of the document, whereas most of us (and most other apps) expect it to be top-left. In fact, when I consider that my svg image is 99.5mm high, the numbers do stack up.

In my g-code I had the y axis value as 10.41 whereas Inkscape insisted it was 89.11.
However, subtract my 10.41 from 99.5 and you get....erm.... 89.01
So it looks like my outline is actually 99.52mm (so I was 0.02mm out!). I think this kind of tolerance is acceptable for a machine that has a 0.1mm accuracy.

All that remains now is to work out how many turns on our CNC we need to make to travel 1mm and get all that coded into the Mach3 interface. With a bit of luck we'll be able to drill some test boards (and hopefully actually print some PCBs) very, very soon!

Making NC drill files and GCode from a PDF (via Inkscape)

Mach3 is a serious bit of kit. There are options and settings for everything!
Which a lot of people would be really pleased with. Just like Eagle is the de-rigueur PCB layout software, because it's so configurable. But here at Nerd Towers, we're not really fans of spending ages getting things set up and working (hence the love of Windows over Linux, and ExpressPCB over Eagle) so - bizarrely - we'll often spend ages making our own tools, in order to "just get the job done". It's not always quicker, and it's most often less simple. But it does give us a certain degree of control over what we're doing.

Which is why we're struggling so much with Mach3 - and in particular importing dxf files.
Mach3 is simple when it comes to "load some g-code and run it". We can even make our own simple g-code files, load them and run them in Mach3. But getting the drill data out of our ExpressPCB files is pretty tricky.

We've already successfully created a .dxf file from ExpressPCB, via Inkscrape, but now, getting the drilling data into Mach3 is proving difficult: so we're writing our own Inkscape-to-gcode app to get us up and running. After all, the pdf loads easily enough into Inkscape, and saving as .svg gives us a whole load of co-ordinates in a nice, easy to read/parse, xml-formatted file.

Here's our PCB layout, loaded from a PDF (which in turn was generated by printing via CutePDF from ExpressPCB). We've picked out the drill holes and coloured them red, the board outline and coloured it gree and ditched everything else. We used a technique discussed earlier to do this.

Saving as plain svg and opening the file in Notepad/Editplus (or any other text editor) gives us our xml which we can parse away at leisure.

One thing to note is that all the co-ordinates listed in the file are in pixels (not mm) as per the .svg specification. It's worth noting that Inkscrape, by default, exports at 90dpi. Knowing this, we can multiply all co-ordinates in the file by 25.4/90 to get the distances in millimetres. (there are 25.4 millimetres in an inch, and the co-ords are saved in a file, where 90 pixels = 1 inch, so 90 pixels = 25.4 millimetres)

Also, Inkscape makes use of translations quite a lot. In this case, the image was drawn in a particular area of the screen. After we got rid of all the extra data that wasn't needed, the result was placed in the bottom left hand corner of the document. It seems that rather than update the points positions, Inkscape simply applies a master translate command over the whole of the image data.
This needs to be kept in mind when parsing the plotting points in the xml file

Where are point is listed as, for example, (390.044, 735.075) it's actually placed at (390.44, 39.06) since the entire image has a translation of [0,-698.16927] applied to it and 735.07543-698.16927=36.90616)

The reason for choosing green and red in our image file is to make identifying the parts easier in the xml. Anything that has a fill colour #ff0000 is red - and therefore a drill point. Likewise, anything with a fill colour of #00ff00 is green - and makes up the board outline.

All of our holes are described as a series of points describing a circle. We're only really interested in the initial (start) point of each hole, not all the junk that comes after it:

With all this in mind, it should be a simple job to knock up some VB to parse an SVG file and create the necessary move-and-peck-and-drill g-code (move to point, z-down, z-up, move to point, z-down, z-up etc). Updates coming soon....

Manufacturing PCBs at home

A while back we started looking at the feasibility of manufacturing at home. The reasons are many, but that's a discussion for another day. So far, we've been looking at how to screen print double-sided pcbs before immersing in ferric chloride for etching.

Now double-sided boards mean finding a way of lining up the prints on both sides of a board. And the most obvious way to do this is to pre-drill the boards before printing. Which in turn means using a CNC machine.

We built a CNC drilling machine for under £50 last year which was pretty accurate - up to about 0.5mm which still made for some pretty useable PCBs. One idea (which we're not dismissing - just haven't time to implement just yet) is to add a camera to the drill head and drill a pre-printed (but not-yet-etched) board. The drill head can move into position, then we use the image from the camera to ensure the drill goes exactly into the centre of each hole by jogging the x/y axis a little until perfectly lined up. This should at least remove the 0.5mm inaccuracies we got during testing. With one side printed and the board drilled, we could then line up the board and print the second side before etching the entire thing.

But just right at this minute, we've not really got time to do more development - especially not when we've a 0.1mm accurate CNC milling machine gathering dust under a table somewhere....

It's been a few years since this thing was fired up, and it was supplied with RoutoutCNC software (incidentally, this is now being given away with free licences since it's no longer supported) but we couldn't get it to work properly. Each time the x-axis moved, the z-axis travelled downwards about once every 10 steps.

Mach3, however, worked just fine (once we'd spent a few hours setting it up and replacing the 25-pin serial cable we thought was a parallel one with a proper, straight-through parallel cable). Here's the CNC in jog mode.

The CNC machine has been made for milling. It's a sturdy, chunky beast and uses really good quality lead screws on each axis. So it's pretty accurate and has very good repeatability. The only thing is - it's so sloooowww.

It'll have to do for now. Maybe hacking our own mini drill machine in future isn't such a bad idea after all!

RoutoutCNC Free Licence Keys:
Viewer: M72DXDU-8X5TQ6L-KPVADQT-9EK0DUD
Manager: L4CD9XT-DK5P5PK-TKHA2AK-D7WRCGC

Magentic bearings

Last night's BuildBrighton Open Evening was a pretty busy affair, and there were some pretty cool projects being worked on. We particularly liked James's Magnetic Bearings idea - especially since he's coupled it with solar panels, to generate the electricity to make a motor spin:

The entire assembly magically "floats" above an array of magnets, as current causes the coils beneath the solar panels to attract, then repel, against the magnets placed around them.

It's not 100% friction free, because the lead of the pencil (which is being used as a shaft) is rubbing against a CD placed at one end of the assembly. But graphite itself is often used as a lubricant in bearings, so it's probably about as friction-free as we could hope to get!

As mentioned in the earlier idea, Jason had the suggestion of hanging the motor from a pivot using another magnet, to see if this could further reduce any friction in the entire system. The result is below:

Quite what he has in mind for the project, no-one really knows (and if James does, he's doing a very good job of making it look like he doesn't). But it's using electronics, motors, solar panels and magnets - so it's already up to 11 on the cool scale!

PSoC4 Pioneer Kit from Farnell

Here's an interesting little development board, recommended to us by Jason from BuildBrighton. It's an ARM-based dev board, from those cool kids at Farnell, called the PSoC4 Pioneer Kit (or the CY8CKIT-042 for you part-number junkies). It's an Arduino sized/shaped dev board, is Arduino shield-compatible but with an ARM processor  and costs just £16+VAT!

It comes in a lovely fatter-than-usual DVD case, with mini usb lead and - bizarrely - about four or five little jump leads in a bag. Software is downloadable from http://www.cypress.com/go/cy8ckit-042
What's really exciting is that the processor alone is available for an amazing £1.58 each (in multiples of ten). That's almost as cheap as even the lowest 8-bit PIC microcontroller we use - and much cheaper than the 18F2455 chips we're so keen on using for their USB capabilities.

But it's not just a souped-up usb-capable PIC.... it has up to 6 FPGA modules - meaning you can program what the hardware peripherals actually do: need 6 uart/serial ports on your next device? No problem!

What got us talking about these was CNC Paul's need for a number of quadrature encoders for servo-motor drives on his CNC design. We're still not 100% sure why these are so much more awesome than stepper motors, but he's insistent that servo motors are the way to go and that steppers are just sooooo last year. Which means we need to be able to drive the things which means decoding super-fast high-speed quadrature encoded signals.

So far we've only seen the introductory video, but it was enough to encourage us to buy three of these little beauties - one for me, one for Steve, and one for CNC Paul (Jason already has one, and has a couple of days development head-start on the rest of us!)

The software is already in our download queue and hopefully we'll get a few hours spare to play with it tomorrow and see what the examples are like....

PCB routing at BuildBrighton

They say all the best things come in little packages. I'm not convinced, by yesterday a tiny little parcel arrived, and it was indeed pretty exciting. It was a range of v-shaped cutting bits for cnc routing:

They are made with a 3.2mm shank (ideal for Dremel type rotary tools) but the BuildBrighton router on the cnc machine has a 6mm shank. So we made sure we also ordered collet/adapter, which worked perfectly.

So last night, Mike, Stephen and a few other cool kids had a play about with the cnc routing software and actually got it cutting. Exciting stuff!

We used ExpressPCB and Inkscape to create an isolation path around the outside of the tracks we wanted on the board, using this earlier technique. The final board was pretty impressive. The tracks were drawn at 0.5mm wide. The cutting bit used was 0.2mm and had a 60 degree angle.

(hot off the cutting bed - quite literally, at 35,000 rpm, the cutting bit gets hot and some of this can transfer onto copper surfaced board)

Cutting was aborted after a few minutes. Not because it's slow and laborious (though cnc routing is!) but because the sparks and really bad smell coming out of an increasingly noisy router eventually told us that it was time to consider replacing it!

But before the router gave up, it cut some really fine traces onto our copper clad board.

If anything the traces are maybe a little too fine. This is because our tracks were drawn at 0.5mm wide. We used a 0.2mm wide cutting head and plunged it 0.15mm into the board. Obviously, the deeper the cut, the more of the blade that goes into the material and even with a relatively sharp 60 degree angle on the cutting tip, a deeper cut means a wider cut. We didn't get the software to draw on the outer edge of the tracks, the cutting head followed the line exactly.

So where we had a 0.5mm trace with cutting lines running parallel on either side, the first cut reduced the effective width of the track to about 0.35mm and when the cutting head passed along the other side of the track, it reduced it by about 0.15mm further - so our final trace was more like 0.2mm wide, instead of the 0.5mm we'd planned on.

But that aside, the pcb it produced looked very, very good. (It should be a simple fix, in the software we simple need to tell the cutter to follow the outer edge of the cutting line, rather than the following the dead centre of the cutting line)