Zen Toolworks 7x7 Home Switches and Sanguinololu

I've been spending some time upgrading the Zen Toolworks 7x7 mill. I glued in some home switches and wired everything up to to the  the Sanguinololu, and glued some split-loom onto the machine to route wires through. That all came out pretty nice. I mounted the board with some hook-and-loop on the back of the X axis, and placed the switches where the moving parts would contact them.

Here is the back of the machine, showing the Sanguinololu and wiring.

Here are the home switches, Z, X, and Y, respectively.

I was having some trouble getting software onto the Sanguinolol, it wasn't responding to the serial port. I loaded Triffids Teacup firmware on it using the Pololu AVR programmer, and it started sending the initial 'start' and 'ok' messages, but nothing after that. After fiddling with it a bit I hooked up the Bus Pirate in RS232 mode to check at the AVR pins to see whether the messages I was sending were making it through. They were not. Using the Bus Pirate to inject data directly at the AVR pin made it work as it should. This confirmed what I suspected, there was a bad connection between the AVR and the FTDI chip. I touched up the appropriate pins on the FTDI chip, and it started working normally.

So now it's time to start getting into software to convert designs into parts. In the past I used the DOS-based TurboCNC program to control my machine, and previously I was running this machine using it. However, I didn't want to be tied to an old computer with a parallel port, so I decided it was time to move to a USB-connected external board, which is where the Sanguinololu comes in.

I had the option to use a number of Sanguinololu-compatible firmware packages, and I've started with Teacup. I had Kliment's Sprinter on it previously, but I switched to Teacup when I couldn't get Sprinter working (because of the bad solder connection). Now that I've put the effort into configuring Teacup, I'm kind of hoping I don't have to try a different one. Unfortunately, Teacup doesn't support G2/3 arcs, which kind of sucks. I may switch back to Sprinter or something so I don't have to decompose all my arcs into line segments. This would work, but because the ramp acceleration mode does a full start and stop for each segment, it would be very slow. RepRap acceleration mode would get around this, but it's kind of a weird mode that requires the software generating the gcode work a little differently. I'd like to use Grbl, but I'm not sure if it is compatible with the Sanguinololu. I'll have to look into that a little closer.

One of the nice things about TurboCNC is that it has a fairly rich set of gcode commands that make it easy to run existing gcode files that include features like loops, printing messages to the screen while it waits for you to switch tools, tool offsets, fixtures, etc. Teacup doesn't have these, and I kind of like those features. 

So, to address this, I've taken the TurboCNC source code, which is normally compiled in Borland Turbo Pascal under DOS, and pulled it into Delphi7 and generally torn it into itty bitty bits. I removed all the UI code (which was based on a third party library that worked similarly to the TurboVision UI package), and eliminated all of the stepper code, and kept mostly the gcode handling routines. I replaced the calls to step-generation routines with calls that output basic gcode commands, which allows Teacup to handle the step generation. I've also added an OpenGL-based tool-path viewer, so it's easy to do a dry-run and see if it looks sane. The viewer will track what has been sent to the machine, but it doesn't yet watch for the block-completed messages, so it isn't very smart about knowing where in the list of queued commands Teacup is. This really only shows up when making long moves, but it would be nice if I could make it more precise.

At this point it will handle some gcode features that Teacup will not (loops, gotos, etc), and does not decompose arcs into line segments (I'll have to add that as a feature for completeness, as much as I'd prefer to have it in hardware), and showing messages while waiting for the user, but it's still missing some of the more advanced features that I want it to have. In particular I'd like to get it working with a touch probe. 

Here's how it looks after running a simple sample file:

For testing purposes I just have it output the generated gcode to a text file that I feed to the machine with a debug terminal. And, since I don't want to get it mounted with a cutting tool yet, I figured I'd make a little ballpoint pen attachment that fits in my Dremel Flextool holder:

While I was looking around on the web for something I ran across the TkkrLab wiki, where they are building pretty much the same setup as I've got here. In fact, I was surprised to see a link at the bottom of the page back to my flexshaft mount blog post :) It looks like they've run into the same problem with Teacup not supporting arcs. I'll have to keep an eye on their progress and see if one of the other options works for them.

Anyway, here's the mill running the sample file:

If you compare to the tool path preview in the screenshot above you can see where it skips the G2/3 arcs. Other than that it's working fairly well. At this point I probably need to spend some more time working on my Windows derivative to TurboCNC, and maybe see what I can do about evaluating other firmwares with arc support.