I posted a couple of weeks back (in the bugs section) about mods I made to Phlatscript to output metric gcode.
At that time I simply put the files on my web site for download, which was probably a bit hard to use.

I have now made an actual web page that explains how to install them, and a zip file for downloading the
4 files. Hopefully this makes it simpler for folks who need metric gcode to get going sooner, and I hope this can be merged into the next release.

The page is at http://iwr.ru.ac.za/~david/phlat/
(removed from that server 20 May 2013 - superceded a few times over by more recent code)

gasmasher, I have made some further mods to my local copy that allows the gcode to have different precision depending on the output mode. Few metric machines will need more than 2 decimals (hundredths of a millimeter), while imperial machines will be happier with 3 or 4 digits (thous or tenths of thous) after the point. Let me know if you want the code.

I've been working on pocketing too, but so far my level of computational geometry has been way exceeded by the complexity and I'll have to come back to it unless someone else gets to it first.
I envision pocketing being useful for lightening balsa ribs, yet without cutting all the way through.

For the curious, my machine build (not a phlatprinter) has got as far as finding all the stepper motors in the garage, and ordering the driver boards, then figuring out that the earmarked laptop has a parallel port that cannto drive the optoisolators, so next up is finding a PC to run TurboCNC and testing the electronics with that. Once the motors all move, I'll design and build the Z axis for the gantry mill.

 

Indeed I found this out last weekend when I tried to drive a stepper with my old laptop and it would not drive the step pin low enough. As I saidm I have some old PC's so a solvable problem, I just wanted to use the laptop due to space restrictions.

 

My pleasure on the patches. Pocketing can be trivial but watch out for the acute angles where it will tend to leave an island. Google will bring up a lot of learned papers on the topic of optimizing for speed and eliminating islands. My plan was to split the polygon into triangles and then pocket each triangle optimally (the easiest case it seems), but I got lost in the geometry stuff, math is not my strong point. If you just keep offsetting into the poly your cut lines will eventually cross and cut air for some polys, and yes that will happen so you cannot ignore it.

I'll have a look at that other code mentioend above and see if I can use it as a starting point.