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
- Import CAD model — open the STEP/IGES file in CAM.
- Define stock and fixtures — tell CAM the raw material size and where the clamps are.
- Set datum (G54 origin) — tell CAM where X0 Y0 Z0 is on the part.
- Assign tools — pick end mills, drills, taps from the tool library. Set speeds and feeds.
- Generate tool paths — CAM computes roughing, finishing, drilling paths.
- Simulate in CAM — watch the material-removal simulation. Check for collisions.
- Post-process — run the chosen post-processor to generate G-code.
- Review G-code — open the .nc file. Check the header, tool changes, and cycle syntax.
- Transfer to machine — load via USB, network, or DNC.
- Dry run and first part — verify on the actual machine before full cut.
Where Things Go Wrong
| Stage | Common Error | Result |
|---|---|---|
| CAM setup | Wrong stock size | CAM thinks there is more/less material than reality |
| CAM setup | Datum offset mismatch | All coordinates shifted from actual G54 |
| Tool library | Wrong tool diameter | Cutter compensation off; dimensions wrong |
| Toolholder | Holder not modeled | Simulation misses holder collisions |
| Post-processor | Wrong machine post | G-code syntax the controller does not understand |
| Post-processor | Tool number mapping wrong | CAM T01 becomes physical T03 on the carousel |
| G-code review | No human check | Errors go straight to the machine |
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 50% feed and 100% rapid, then a single-block first cut.
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?
Ans
Translates generic CAM tool paths into machine-specific G-code, including cycle syntax, tool change format, and output code structure for a particular controller.
2. Why must you model the toolholder in CAM?
Ans
So simulation detects collisions between the holder (not just the tip) and the fixture, part, or machine. An unmodeled holder causes unexpected crashes.
3. Does CAM simulation replace the machine dry run?
Ans
No. CAM does not know your actual G54 offset, H tool lengths, or tool positions. The machine dry run with real offsets is still required to catch setup errors.
4. You post-process with a Haas post but the machine is a FANUC. What happens?
Ans
The G-code may use Haas-specific cycle formats, M-codes, or output formatting that FANUC does not recognize. The controller may alarm, misinterpret cycles, or produce wrong motion.