NFR Partners editNC CNC G-Code Editor - CNC FAQ (APT Architecture)

APT Architecture

Note: This page might be more interesting than you think.

The designers of APT had several major problems to overcome, and their solutions have proven to be far sighted and, in some cases, brilliant. Here, we will try to highlight some of the problems they faced and how they addressed them.

Note: APT is often called a compiler or an assembler. Technically, it doesn't fit either definition - it's really an incredibly complex translator. The term processor is often used to refer to the APT translator. APT program refers to an NC program written in the APT language.

Problem: Slow computers with limited memory

Solution: Processing was handled in 4 sections.

Section 1 (Translation Section) reads the users APT program and builds tables containing the part geometry information. It verifies syntax and lists the program and geometry information if requested. In some APT processors it stores this information on disk. The part geometry is now in canonical form.
Section 2 (Calculation Section) takes the section 1 output and computes the tool path geometry. Tool offsets can be applied here. A preliminary CL file is created here.
Section 3 (Edit Section) modifies and expands on section 2 data if necessary. The final CL file is created here. A CL listing is printed if requested.
Section 4 (Postprocessor Section) controls postprocessing.

For complex programs, these sections took hours to process and could be run as separate steps. Some of the newer APT processors pass data between sections directly rather than through temporary disk files but the section identities remain.

Problem: Countless machine tools as targets

Solution: APT was intended to be a general purpose language, not just oriented towards one type of machine tool or one manufacturer. It was therefore designed to create a machine tool independent, generic NC program which was called a Cutter Location, or CL file. (Some older folks call it a Center Line file.) The CL file is then read and processed by a postprocessor supplied by someone with a good knowledge of the specific machine tool and its requirements and limitations - originally this was often the tool manufacturer but is now usually a specialist supplier.

Problem: Extremely complex geometry issues with some cutter shapes

Solution: APT allows use of complex cutter shapes, requiring up to 10 parameters to define. Positioning a complex cutter shape along surfaces, potentially very complex themselves, requires some nearly impossible calculations if done using traditional methods. APT uses several methods, depending on the problem to be solved. Simple analytical approaches are used for 2D problems with sophisticated iterative methods used for 3D calculations. For this reason, the user specified required tolerances can have a big impact on the resulting program - APT is often asking itself "Am I close enough yet?". Use of iterative methods is one reason why APT was not used directly in more modern CAD/CAM systems (where response time is a major concern) than it has been. Not everyone agreed on how to perform many of these processes and some companies had special geometry requirements and several major Section 2 "engines" or ARELEM's were developed. (ARELEM = Arithmetic Element).

Problem: Multiple software and hardware vendors were often needed

Solution: The basic APT processor is public domain code and the language rigidly defined by an ANSI standard. Most APT processors were written in Fortran and were reasonably computer and operating system independent. The biggest issue, however, was postprocessors. The APT designers did not want to have to support every machine tool available, yet they couldn't expect the tool companies and others to supply postprocessors that supported every variety of APT CL file. Although the CL file format was similar from APT vendor to vendor, they were tailored to individual computer system characteristics. Therefore, they created an API (they didn't call it that) that would insulate the postprocessor from the actual CL file format. (An API, or Application Programming Interface, is commonly provided today for complex programming such as WIndows, and is basically a defined way for programs to interact). APT postprocessors traditionally do not read the CL file directly, but use (APT) vendor supplied routines to access the CL data. This method lets a single postprocessor function with multiple APT systems, operating systems, and computers and has allowed many postprocessors written for mainframes run on PC's with only minor changes.

CL File Formats (or Boy, am I confused!)

Although the actual formatting on disk varied, until about 1982 APT processors produced similar CL files. They were difficult for humans, but easy for computers, to read and contained mostly integer and floating point numbers. These days, we have dozens of "APT" CL file formats. These are mostly variations of APT motion statements, like GOTO x,y,z and many can be used as APT source. These are often called "ACL" files (for ASCII), "SCL" (for Source), "Standard" CL files (well, maybe), "APT" CL files (total confusion, we'll stop here........)

APT with CAD/CAM (or suddenly it's 1966!)

An APT processor is often used as a "back end" for a CAD/CAM system. The CAD/CAM system produces an APT source program (although it's often called a "CL file") which is then run through APT. This is done for several reasons.

Allows use of existing postprocessors - Many companies used APT before converting to a graphically oriented system and wanted to retain their investment in postprocessors.

Allows use of APT features - Some of the earlier CAD/CAM systems had limited or no ability to transform or to repeat portions of a tool path. For example, there was no way to drill a hole and then repeat that operation 10 times to create a bolt hole pattern. Instead, they would repeat the operation using APT INDEX/ and COPY/ statements which were inserted automatically into the output data.

Intelligent handling of arcs - A CAD/CAM system usually doesn't know how (or if) the target machine tool handles circular interpolation. This often means that arcs are produced as a series of short linear moves, especially if not in the XY plane. APT doesn't know either but it takes a very intelligent approach - it puts both the arc definition and the short linear moves into the CL file and lets the postprocessor (which does know) decide what to do. As CAD/CAM systems improve, this appears to be less of a problem. Also, in many cases, the the CAD/CAM system can describe the arc in the CL file and the postprocessor can convert it to a G2/G3 command or expand it to linear moves, as appropriate.

Simpler postprocessor library - By using APT as a link to the postprocessor, a company can use a single postprocessor per machine tool, even if multiple CAD/CAM systems are in use.