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....
No comments:
Post a Comment