Updated @ 16:28 13th April 2012
I’m playing catch-up here. The contents of this post refer to work over two days old, delay in writing it up is due to other, more pressing matters.
The good news is that after using LineGrinder to generate the G-Code from my little PCB, the two mysteriously-missing areas on the PCB are correctly rendered. I halted cutting of the traces due to the fact that a) there was insufficient depth-of-cut, and b) because of (a) the convex shape of the board made undercut inevitable.
Just about everything is better in this attempt. !st, the ‘JB’ and ‘1′ completely missing from the previous try are clearly visible. The pad outlines are a better shape, and not chewed to ribbons by repetitive tracing as in pcb-gcode. All that remains is to ensure correct depth-of-cut and present as flat a surface as is possible to the tool. This means a better clamping method than I used to-date.
Above you can see my test board, sitting atop a sacrificial fibre-board. The aggregate thickness of these is around 4.5mm. I cut and milled one side of some 20mm gauge-angle so that the inside width of the cut side is 6mm – sufficient to generate a small angle when tightened to the mill table. I drilled 6mm holes to correspond to the mill table slots, and opened these slightly with a 6mm slot drill. The result is as you see above.
Probing the surface shows up a distinct, but slight convex hull, highest in the centre – furthest from the clamps. I will be investigating two methods of overcoming this, the first and most obvious of clamping the sides of the board as well, the second using pre-probing of the tool-route, outputting a compensating Z-axis dimension, and re-combining this with the original gcode. ( a little ‘z’ if you like)
This is not a new idea, and as I’m currently ‘logging’ the g-codes in the file-system as they are sent to the controller, it is a simple matter to send adjustments as the probe run is done, so to this end I’ve implemented the code, but have yet to try it out in anger.
As for pcb-gcode? Well I won’t bother investigating further, as the results from LineGrinder are just far superior. You may be interested to know that proper arcs (in gcode) are output for the pad ends, using LineGrinder, whereas rough polygons are output in pcb-gcode. Also, the drill holes are ’spotted’. I’m convinced which is the winner.
Below is the VEGA DATA simulator output.
I’ll report on my pre-probed cut in the next post of this diary.
JWB 12th April 2012
Supplemental – added April 13th 2012
No, I haven’t done the probing yet, but did try out re-arranging my setup.
First of all, I used a longer piece of circuit board.
Secondly, I didn’t tighten the clamps so enthusiastically as previously.
I then ran a clock gauge across the surface. No discernable distortion was evident in the centre two-thirds of the board.
Next, I increased the depth of cut in the gcode file to 4 thou.
The result is as below:
This is useable!
A few comments:
1st, the space there should exist between the pad with ‘1′ to it’s right and the SMD pad immediately below didn’t make it – it was always very fine, and adjustment of the Eagle project will sort this out.
Secondly, the apparent S/C between bottom-row pad 3 and isolated scrap is simply swarf – it dusted away.
Third. Although I like the DIL socket and SIL pin-holes ’spotted’, some of these ’spots’ are deeper than I would have preferred. (Edit: This is entirely my fault, due to my over-enthusiastic global-replace of the Z-axis dimension!)
These are simply niggles, and the machine can now be considered fully-operational.
The Eagle project I based these tests on is linked elsewhere, but the gcode file I used to generate these cuts is here: http://joebrown.org.uk/images/MillTable/Diary/t2.nct
The 1mm cone cutter I used is available from ESR: Order Code 275-140, Description 1.0mm Miller Cutter – Conical, priced GBP £0.84.