But the image converter simply treats the image as a depth map which is cut by raster-scanning with the cutting head. For the designs I used, this was slow, and produced rougher results than would be produced using vector cuts.
So I looked at a couple of approaches to improve things. One is using CAD software that works well with a CAM package to covert the CAD design into machine control instructions to cut out the CAD shapes. The other is to go straight to writing my own machine control programs by hand. I know that I'll want to have both methods in my toolkit, but which to use first?
After a bit of back and forth yesterday morning, I decided to start with programming by hand first. So I dove into the EMC2 documentation for gcode, the programming language more properly called RS-274-NGC. What a catchy name, eh? You can bet that the folks who picked programming language names like "python" and "Java" are kicking themselves after seeing how "RS-274-NGC" rolls off the tongue.
Results of My First GCode Program.
Well, the EMC2 site has a link for a gcode tutorial, but what's there is...not much. Maybe I'll pitch in, since that's what wikis are for, right? The I went an read the EMC2 documentation, which has the standard cart-before-horse format of discussing details before generalities. Then I found the excellent LumenLabs GCode Tutorial. Much better!
I read some bits, scanned others, then hit the keyboard on my CNC control system. It's an old Athlon 800 with 768MB of RAM loaded up with the EMC2 LiveCD install for Ubuntu Hardy Heron, with EMC2 upgraded to the current version after install.
I fired up EMC2 with the SIM-Axis configuration for developing the gcode. I've got three different configurations of EMC2 on my desktop. I've got the SIM-Axis setup, and two different configurations for my microCarve A4, each with different origins for the axes.
I used gedit to create an initial gcode file, then opened it in EMC2. The gcode preview window is great. Whenever I edited the gcode file and saved, I'd click the reload button in EMC2 and immediately see the changes. Likewise, the error messages were good enough to let me find my problems, though the problems were usually typos rather than what was reported.
I used iterative development, of course. No sense writing too much code before finding out that I didn't understand some element of syntax. I started with initializing the mode settings, lifting the head to a safe traversal height, traversing to a point in space, then returning to machine zero. After fixing a couple of problems, I got what I wanted. Then I added a few additional move commands, and got the simulated CNC to follow them. At that point I could see that things would get out of hand pretty quick if I didn't learn some basic flow control.
So I read up on subroutines in gcode. I laid out a simple key pattern on graph paper, and wrote the necessary routines. That's the border you see in the picture above. That was the easy part. It's all straight lines.
Next was curves. I read up on G2 and G3. I hadn't thought about the ability to shift the depth of cut across the curve when I started reading, but by the time I was done I was thinking, "Hmmm, if I vary the depth of the cut with a V groove bit, I can vary the width of the cut just as I would vary the width of a line with a calligraphy pen."
So I broke out a fresh sheet of graph paper, and started drawing some letters. Well, it took me about three times as long to lay out the letters as it took me to lay out the key pattern, but I managed that. Not only that, but I set things up with scaling factors and variable settings that allow me to easily scale and move the letters.
The results you see above are what I got from the first "live" run of my first gcode program. The cuts are a bit deeper than I'd like, and the 90 degree bit I'm using right now doesn't help. Also, the cutting was a bit fast for the plywood, causing the wood to be frayed on the cross-grain cuts. Still, the varying of "line weight" on the letters turned out well. Overall I'm happy with it, and the defects should be easy to fix when I run it again. I'm planning on building a complete alphabet for this font and throwing it into a file for later use.