Tormach PCNC 770 mill
The 770 represents my first exposure to CNC machining. I have been proceeding slowly, trying to do the least damage while I climb the learning curve. So far, blunders have cost me only one endmill, one wiggler edge detector, and one bellows-like way cover.
On the old SX3. I did a lot of my work by ear, feeding the table and changing the spindle speed until the machine stuttered, then backing off. It is (barely) possible to run a CNC mill that way, but it is inefficient, to say the least. For common tasks (shaving down a rough surface to make it level, drilling a (relatively) small hole, milling a bigger hole, chamfering an edge, etc.), one wants to be able to draw upon stereotypical CNC programming.
Programming of the 770 (and most other CNC machines) is done in gCode, a low-level programming language. CAD/CAM programs (I don't have one) produce gCode. gCode has recently been extended to include named variables and control structures (if/elseif/endif, call, sub/endsub/return, while/endwhile, repeat/endrepeat, break/continue) of the sort that have been present in ordinary programming languages for 50 or 60 years, but CAD/CAM programs don't seem to make use of them, and some otherwise modern-spirited organizations (Tormach, for example) deprecate their use.
Syntax checking. The Tormach controller provides a simulator for gCode programs, but not a syntax checker. As a result, syntax errors are not reported when they are present in lines that (data-dependently) are temporarily not reachable. For example, the syntactic error in
might not be detected by the PathPilot simulator, depending on the currently-selected tool. When the simulator does report syntax errors, those found within subroutines are reported as having occurred within the caller routine, so locating the error is often time-consuming. I have prepared a syntax-checker program that runs stably in the Windows 7/64 environment. It probably runs in other versions of Windows, too. The executable file is available here (updated 2017-11-23).
Oh-number management. The "100" numbers in the example just above are called oh-numbers. They are used as labels, with restrictions against duplication that are meant to apply across a calling program and all of its subroutines. These restrictions are only imperfectly enforced by some CNC engines, sometimes leading to unintended results. My OhLister program (available here, with no manual beyond some brief comments in the manual for MillWizard, as described just below) looks through a directory of gCode files, summarizing their use of oh-numbers, and identifying conflicts.
gCode generation. The common way to provide a stereotypical gCode program is through a "wizard" that accepts parameters and generates gCode to accomplish the specified task. The wizards I'm aware of (Tormach's own and that of GWizard) don't use any of the modern gCode features, so they produce code in which every repetitive operation has been unwound into many, many microsteps. In programming terms, it is premature binding run amok. In a typical case, an operation describable in 100 or so lines of readable annotated gCode is specified in wizard output of 3000 cryptic lines.
Because the need for canned solutions for recurrent mid-level machining problems is not well met by the available wizards, I wrote my own. My MillWizard program generates short gCode routines that pass parameters to a small library of permanent, parameterized gCode subroutines. The tasks it facilitates are
A manual and downloadable code are available in this directory (updated 2017-12-05).
Page revised: 2017-12-05 14:12