CAD, CAM & Post-Processing

Most production programs are generated by CAM software, not hand-written. This page explains the CAD → CAM → post-processor → G-code chain, where each step introduces errors, and why CAM output always needs human review before machining.

Concept

CAD (Computer-Aided Design) software creates the 3D part geometry — SolidWorks, Fusion 360, Inventor, CATIA. CAM (Computer-Aided Manufacturing) software takes that geometry and automatically generates tool paths — Mastercam, Fusion 360 CAM, SprutCAM, Edgecam. The post-processor translates the generic tool-path output into machine-specific G-code that your particular controller (FANUC, Haas, Siemens) understands.

Hand programming is fine for simple parts: a straight shaft, a few holes, a rectangular pocket. But once parts have 3D surfaces, complex contours, or dozens of features, CAM software does the work. The trade-off: CAM produces thousands of lines of G-code quickly, but it can also produce collisions, wrong speeds, and unsafe moves if the input parameters are wrong.

Why It Matters

Operators who trust CAM simulation without review are the ones who crash machines. The post-processor only knows what you told it about the machine. If you did not model the toolholder, the CAM sees only the tool tip — and the holder crashes into the fixture. If the work offset (G54) in the CAM setup does not match the actual machine, CAM faithfully produces wrong coordinates. If the post-processor is for a different machine, the G-code uses the wrong cycle syntax.

Understanding the CAM chain makes you a smarter programmer: you know what to check, what to override, and when to hand-edit the output.

How It Works

The Complete Workflow

1. Import CAD model — open the STEP/IGES file in CAM.
2. Define stock and fixtures — tell CAM the raw material size and where the clamps are.
3. Set datum (G54 origin) — tell CAM where X0 Y0 Z0 is on the part.
4. Assign tools — pick end mills, drills, taps from the tool library. Set speeds and feeds.
5. Generate tool paths — CAM computes roughing, finishing, drilling paths.
6. Simulate in CAM — watch the material-removal simulation. Check for collisions.
7. Post-process — run the chosen post-processor to generate G-code.
8. Review G-code — open the .nc file. Check the header, tool changes, and cycle syntax.
9. Transfer to machine — load via USB, network, or DNC.
10. Dry run and first part — verify on the actual machine before full cut.

Where Things Go Wrong

Why CAM Simulation Is Not Enough

CAM simulation shows you what the machine would do if everything matched the setup exactly. It does not know: your actual G54 offset values, your actual tool length (H) offsets, your actual tool numbers in the carousel, or your machine's actual travel limits. Only the machine itself — through a dry run with the program and actual offsets loaded — reveals the truth. CAM simulation catches obvious collisions; the machine dry run catches setup errors.

Example

Scenario: You receive a CAM program for a steel bracket. The CAM simulation looks perfect. Before running the first part, you verify:

• Post-processor: open the .nc file. Does the header look right? Does it start with G21 G17 G90? Are the canned cycles G83/G84 syntax correct for your Haas?
• Work offset: does the CAM datum match your G54? If CAM set Z0 on the top of the stock, is your G54 Z also on top?
• Tool numbers: CAM says T01 is an Ø10 end mill. Is T01 in your carousel actually an Ø10 end mill?
• Tool lengths: H01 in the program — have you measured that tool's length into H01?
• First move: what is the first G00 X Y Z? Is it safe? Does it clear the fixture?

Only after these checks should you run a dry run at reduced feed and rapid override (the exact percentages depend on your machine shop's procedure), then a single-block first cut.

Why CAM Output Still Needs a Human Review

CAM software is excellent at generating hundreds of cutter-location points. It is not excellent at understanding that your machine has a 12-inch Z travel, that your vise jaws stick up 18 mm, or that your coolant line hangs 30 mm above the spindle. The post-processor only knows the machine geometry you told it; if you did not model the toolholder, the CAM sees a naked tool tip and happily crashes the holder into the fixture. This is the #1 reason "CAM programs look fine on screen" still crash the real machine.

The work offset in the CAM setup must match the G54 on the controller. If the CAM setup uses the lower-left corner of the stock and the operator set G54 at the center of the plate, the program faithfully cuts 50 mm to the left of where it should. Always open the .nc file and read the first motion: does the first G00 XY go to a position that, given your G54, is actually in clear air above the part?

The post-processor is machine-specific. A Haas mill post emits G83 with R plane and Q peck syntax that Haas understands; a FANUC post uses the same letters but may format them differently; a Siemens post uses cycles like CYCLE82. Running a Haas post on a FANUC machine (or vice versa) produces code that either alarms immediately or, worse, runs the wrong motion. If you change machines, re-post — do not hand-edit the G-code to fit.

Whether the CAM simulation shows the toolholder and fixture depends on how the setup was configured. If the model includes holder and fixture geometry, the simulation can check interference; if it only models the tool tip, it cannot. Before running on real stock, walk through the first moves on the controller in single block. Watch the holder clear the vise on cross moves. The on-machine dry run catches what the screen simulation cannot.

What to Check in the Post-Processed .nc File

After CAM posts the program, open the .nc file in a text editor and check the first 20 lines before sending it to the machine:

1. Does it start with % and an O-number?
2. Does it have the startup block (G21, G17, G90, G40, G49, G80)?
3. Does the first tool change (T01 M06) match the tool the CAM setup says?
4. Does the first G43 H01 use the right H for that tool?
5. Is the first G00 XY position in clear air above the part, given your G54?
6. Is tool length compensation and the safe Z plane established before cross-traversing XY, and does the cutting approach happen only after XY is over the target?
7. Does the program end with M30 and a closing %?

If any of these is wrong, the post-processor setup or the CAM setup is wrong — do not hand-edit the .nc file to fix it. Re-post with the correct post and setup. Hand-edited CAM output is how uncommented magic numbers end up in production programs.

Also check: does the .nc file use canned cycles (G81/G83) or did it output every hole as a G01 down and G00 up? Both are valid; cycles are usually shorter, but the line count alone is not a defect. Compare the actual output against the setup, cycle time, and version history rather than judging length.

CAM Toolpath Strategies in Practice

CAM software offers many toolpath styles: zig-zag, one-way, spiral, trochoidal, raster, contour. Zig-zag is fastest but alternates climb and conventional, which can leave a small step on the surface. One-way always cuts climb (or always conventional), gives a better finish, but has rapid retracts between passes. Spiral cuts around the pocket perimeter outward (or inward), which is good for pockets. Trochoidal cuts a circular path with small radial engagement, used for hard materials or deep pockets.

For a beginner, start with zig-zag for roughing and contour for finishing. Add spiral when you need to keep chips small. Add trochoidal only when you are cutting hardened steel or deep slots where a full-width slot would overload the spindle. Do not use a fancy toolpath because it looks cool — use it because it solves a specific problem.

CAM also lets you simulate the toolpath. Watch the simulation for the whole part: does the tool actually reach every wall? Does the holder clear the fixture? Does the retract height go high enough between pockets? The simulation is a preview, not a guarantee — the on-machine dry run is still required, but the CAM simulation catches obvious errors fast.

CAD to CAM to Post: The Pipeline

The pipeline is: CAD (draw the part) → CAM (assign tools, feeds, and toolpaths) → Post (convert the toolpath to G-code for your specific machine) → Machine. Each step is separate and each can be wrong. A correct CAD model posted with the wrong post gives a program that looks right but crashes on your machine. A correct post fed by a wrong toolpath gives a program that runs but cuts the wrong shape.

The CAD model must have the correct dimensions, datum, and stock allowance. The CAM setup must use the correct tool definitions (diameter, corner radius, length) and the correct feeds/speeds for your material. The post must match your controller (Haas, FANUC, Siemens). If any of these three is wrong, the output G-code is wrong. Inspect each step before moving on — do not let errors compound.

For a beginner, hand-code simple parts and use CAM only for complex geometry. Hand-coding teaches you what the machine actually does; CAM hides it. Once you can read G-code, CAM is a speed tool, not a crutch. If you cannot read the G-code your CAM produced, you cannot debug it on the machine.

Post-Processor Basics

A post-processor converts CAM's generic toolpath into the G-code your machine understands. It knows: your controller (Haas, FANUC, Siemens), your machine's travel limits, your tool change sequence, your cycle syntax (G81 vs CYCLE82), and your program format (O-number, percent signs, block numbers). A wrong post produces a program that looks correct but uses codes your machine does not understand.

Common post errors: wrong G-code dialect (Siemens cycles on a Haas machine), wrong tool change (T01 M06 vs T0101), wrong feed units (mm/min vs mm/rev), wrong retract height, missing startup block. After posting, always open the .nc file and read the first 20 lines. If the post is wrong, fix the post — do not hand-edit the .nc.

For a beginner, use the post that came with your machine (Haas post for a Haas VF, FANUC post for a FANUC control). Do not download a random post from the internet. If you need a custom post, the CAM vendor or a post-processor specialist writes it; it is not a weekend project.

Common Mistakes

• Not modeling the toolholder — CAM sees the tool tip, not the holder. Collisions happen with holders, not tips.
• Wrong post-processor — running a Haas post on a FANUC machine produces cycle syntax the controller rejects or misinterprets.
• Ignoring machine envelope — CAM does not know your X/Y/Z travel limits. A tool path that looks fine in CAM may exceed the machine's travel.
• Trusting CAM speeds/feeds blindly — CAM uses generic recommendations. Adjust for your material, machine rigidity, and tool condition.
• No G-code review — always open the output file. Look at the first 20 lines and the last 20 lines. Spot anything that looks off.

Practice

1. What does a post-processor do?

2. Why must you model the toolholder in CAM?

3. Does CAM simulation replace the machine dry run?

4. You post-process with a Haas post but the machine is a FANUC. What happens?

Sources

• Autodesk Fusion post-process reference