Converting G-code to Acu-Rite commands for the Sharp CNC Mill

From Artisan's Asylum

Jump to: navigation, search

Contents

Introduction

The Sharp CNC Mill in the metalworking area can cut under computer control. The CNC system that drives it is an Acu-Rite v.1.3.1 controller. That's got a nice conversational interface which allows programming cutting patterns for pockets, circles and arrays of bolt holes, facing operations, and so forth.

But what if you've got something more complicated, like an image that you want to turn into a stamp? What if you want to engrave using a different font than the one built into the machine? What if you started your workflow in SolidWorks or AutoCAD or any other common CAD/CAM package? Those can generally be made to produce output in G-code, but not in the Acu-Rite conversational programming interface.

Newer versions than the v1.3.1 controller can accept G-code and use it, but ours is too old. Fixing that requires replacing the entire controller---the display, CPU, motherboard, enclosure, and more, to the tune of many thousands of dollars.

So I whipped up a translator program that can inhale G-code from a variety of packages (most notably CamBam, but others should work), and will produce a valid Acu-Rite program (a so-called ".mpt file") you give directly to the mill.

Caveat emptor!

This program is EXPERIMENTAL. Use at your own risk!

In particular, you must make absolutely sure that its output makes sense for the pattern you wish to cut. You should do a graphics-only dry run, and also do a cutting run with the spindle above your piece, no tool, and the spindle motor off, to make sure that the mill will properly command you to raise and lower the quill at the right times so a rapid move won't cut through your workpiece, break a tool, or chew up the vise or table.

Limitations

The converter has currently been tested on two rather different versions of CamBam; these versions are a couple years apart and produce markedly different output. It's also been tested with a few of the examples from Tormach. It has not been extensively tested with every random G-code generator out there. That's your job.

Remember that the Z-axis on this mill is DRO only and cannot be moved under computer control. If your G-code output is going to do something stupid like raster-scan a complicated pattern (as one version of CamBam attempted to do), you're going to have to raise and lower the quill a zillion times. Try to arrange your output to minimize Z-axis moves, because you're going to be doing every single one of them by hand.

Since neither CamBam nor the small number of Tormach examples I tried use cutter radius compensation, this isn't implemented. If your code depends on that, let me know and I might be able to support it. (The Acu-Rite does support some form of radius compensation, so it might be adequate to just pass that through, but I'd like an actual use case to test first so I know I've implemented it correctly.)

There's no direct way of having G-code portably specify exactly which tools are where; all it can do is ask for particular tools in a carousel to be selected. (Some CAM programs emit comments indicating which tool goes where, but those comments are free-form and are not standardized, so you can't depend on them.) My converter does allow for tool changes, and allows you to set them, but you'll have to specify which tools are what manually, as part of the conversion, so the prompts at the controller are approximately right. (You'd have to do this anyway so your tool diameters in real life match those you told to your CAM program, so this isn't much different.)

The converter accepts, but ignores, a large number of G-codes. See the comments in the code if you want details. The ones it ignores are generally mode-setting boilerplate that many CAM programs emit at the start of a job, such as coordinate systems, offsets, turning various kinds kinds of cooling on and off, and anything that tries to control the rate or direction of the spindle, since none of that stuff is under computer control in this mill. It also ignores looping constructs (at least until I see an example used in the wild), line numbers, and most end-of-job codes. It warns about certain codes which ask the mill to do things it can't do, and errors on all codes that have not yet been implemented; many of these ask for canned cycles which the mill doesn't support, or turning operations (the mill is not a lathe), or arcs not the XY plane, and so forth.

The mill has a built-in limitation of 999 steps. To the mill, a single pocketing operation entered via its conversational interface is one step, but a series of short moves emitted by something that spits out G-codes looks like one step per move to the mill, even though it's conceptually one operation. This means that really complicated milling operations might lead to programs that are too long for the mill to accept. In such cases, you'll just have to break your program up into sections and run them sequentially. In practice, you have to get pretty complicated to hit that limitation.

Long programs take the mill a long time to digest. A program with 800-900 steps to parse may take take it up to 5 minutes or more before it displays it on the screen. Don't panic---it's not stuck. If it hits something it can't digest, it will generally either toss some sort of syntax error up on the screen (which you can recover from just by hitting Cancel), or it will get a general protection fault and crash (which requires power-cycling the controller). Neither of these things should ever happen if you're using the unmodified output of this converter; if one does, it is absolutely a bug and you should report it. See Reporting Bugs below.

You should not attempt to hand-edit the output of the converter unless you know exactly what you're doing. In particular, if you get the formatting of a step wrong, you'll get a syntax error at best. If you remove a step and fail to adjust the total number of steps in the preamble, you'll cause a crash that will require a power cycle. If you find you have to hand-edit the output, please let me know what you're doing, and I may be able to modify the code to do the right thing without additional work.

How to use it

You can find the current code here. It's written in Emacs-Lisp. If you're already an Emacs user, you know what to do: put the code somewhere, byte-compile it, and load it. If you're not an Emacs user, ask me. It is possible to arrange for Emacs to be run in "batch mode", which means you can run your job through Emacs for conversion from the command line without having to know anything about Emacs itself. I haven't implemented the scaffolding required to do that because I don't know if anyone needs it, but if you do, let me know and I'll do the work. (The most complicated part of doing that work is setting tool types and capturing any error output, both of which currently expect that you're using Emacs interactively.)

Setting tool types

To specify which tool is in which slot position, use M-x set-tool. It will ask you for the tool index, its diameter, and the name of the tool. The mill has a hardcoded list of acceptable tool names; using any other name for a tool in your job will cause it to barf with a syntax error on that step of your program. You can use completion for tool names. The only names which will be accepted by set-tool are those which the mill finds valid. Use ? to get a list. In most cases, you can just use FL END ML or DRILL and ignore the other choices.

The tools you set must agree with what you told your CAM program! This is obvious, but easy to screw up. Check carefully.

To see your current tool carousel, use M-x show-tools.

Converting your G-code

Set your tool types first, as above.

Once you've set your tool types, visit the file containing the G-code you want to convert, and type M-x gcar-convert-buffer. (M-x gcb is a shorthand for this.) This command takes the current buffer and produces a new buffer, with the same name but with .mpt appended, in which the G-code has been translated to Acu-Rite commands. You must actually save that buffer somewhere in the filesystem to use it. If a buffer of that name already exists when you start conversion, it will be wiped without warning and replaced with the conversion output.

The buffer produced includes inline comments. Most of these comments are the original G-code, interspersed with the generated Acu-Rite command blocks, so you can figure out which piece of G-code produced which piece of output.

If some G-code in your input isn't implemented at all, or asks the mill to do something we know it can't do (like switch unit systems in mid-job), you'll get an error. If your job is too large, you'll also get an error, although conversion will complete. (If you try to run such a large job, however, you'll crash the mill controller and have to power cycle it.)

Running your job

You must take your output and write it to a DOS-formatted floppy. Yes, really. (At some point, I intend to reverse-engineer the serial-line mass-storage format used by the mill, and then we can skip the floppy step.) I'll try to keep a floppy or two near the mill in order to let you do this. We also have an industrial touchpanel Linux box with a working floppy drive. I plan to hang it near the mill, so you can do your conversion on that machine and then load it into the mill.

To run your job, open the floppy access hatch at the left side of the mill controller, insert your floppy, and hit PGM. Use the "program functions" menu to select "floppy drive" and "text format", and you should see your file appear. Use "load" to load it. Be patient for large files; it may take on the order of 30 seconds per hundred steps to load your job.

Please remove your floppy when you're done, and put it back near the mill so others can use it. (If you leave it in the drive and someone has to power cycle the controller, it will attempt to boot from your floppy, most likely confusing the poor person trying to use the mill into believing the mill is broken.)

Simulate your job first, in both graphics-only dry-run, and in run mode but with the spindle raised and stopped, before you trust the mill to cut any actual parts. See the important caveats above.

When you're done, please clear your job, or leave a note on the mill that someone else may do so. These jobs generally look complicated enough that people may not want to gratuitously delete them without spending the time to make sure they're saved or not in use.

Reporting bugs

I want to fix any bug you find. What's a bug?

  • Some G-code that the mill could actually accomplish, but isn't implemented yet.
  • Incorrect output: you asked for one shape and the mill cut a different shape.
  • Spurious warnings: the conversion program complained about something it shouldn't have.
  • Controller errors: something you gave to the mill caused it to complain of a syntax error.
  • Controller crashes: something you gave to the mill caused it to get a general protection fault.

What's not a bug?

  • Wacky output from your CAM program.
  • Taking a long time to load your program. (Unless it takes 10 minutes or more, in which case it'd at least be nice to know.)
  • Something the mill can't possibly do at all, or can't do under computer control. (Spindle speed control, Z-axis moves, cooling, etc etc.)
  • Expecting the converter to figure out things like "this series of moves started out as a pocket" to save on steps; in the worst case, decompiling your CAD/CAM toolchain back into your workpiece is AI-complete.

To report a bug, send me mail.

You should include (at least!) the following in your report:

  • The version of gcar.el you were running.
  • What happened. Be as specific as possible.
  • Where your G-code came from. What package, what version, any special modes, a URL to the tool, etc etc.
  • If the converter choked on something, the G-code it choked on. Try to narrow it down to the smallest-possible test case first; please don't send me 50K of G-code unless you really have no idea.
  • If the converter misconverted something, I'll need both the input and the output. Again, a minimal test case would be appreciated, but if that's hard, just send me the complete input and output files. If you know what it should have emitted, please let me know; don't necessarily assume I'll know exactly what some random set of G-code will do.
  • If the mill gets a syntax error or crashes, I'll need all of the above, and I might need a picture of its screen. Just in case, please take a picture of the entire screen if you can, and make sure it's not too blurry to read. Don't send it immediately; if I wind up needing to read it, I'll let you know. If you don't have a camera, at least record whether it's a total crash, or just a syntax error; if it's the latter, write down the step you were on and the exact error string, which is generally on a line just above the "soft buttons" on the screen.
Personal tools
Wiki Maintenance