How should a shop validate a SOLIDWORKS CAM post processor?
Validate the post against written machine and controller requirements, then use layered evidence: reviewed NC code, CAM and machine simulation where available, machine-builder-approved safe checks, controlled prove-out, measured first article, and repeat testing across every supported operation class. Release the post by version and machine only after defects are corrected and retested.
CAM programmers, manufacturing engineers, CNC leads, post developers, and quality teams commissioning a new or modified SOLIDWORKS CAM or CAMWorks post.
Only qualified personnel following the machine builder’s manuals, guarding requirements, shop safety procedures, and approved prove-out methods should run machine tests. Software simulation cannot guarantee safe physical operation.
Write the post specification for one exact machine
“Fanuc mill post” is not a usable acceptance specification. Record the machine manufacturer and model, controller and software level, axes and kinematics, rotary conventions, travel and limit behavior, spindle and coolant options, tool changer, work and tool offsets, probing, canned cycles, high-speed settings, macros, subprograms, program transfer, and shop formatting standards.
Include the safety behavior the control and shop expect: startup blocks, unit and plane selection, absolute or incremental modes, compensation cancellation, safe retract method, tool-change position, rotary unwind or reset, optional-stop use, spindle orientation, coolant control, and end-of-program state. Obtain examples of accepted hand-written or proven programs, but do not copy historical habits without checking them against current machine documentation.
Create a requirements matrix that maps every behavior to a test program, expected output, evidence layer, and qualified reviewer. If the post will not support an operation, option, or machine state, state the limitation visibly. Unsupported capability is safer than plausible output that has never been proved.
| Requirement group | Examples to define | Acceptance evidence |
|---|---|---|
| Program state | Units, plane, mode cancellation, work offset, safe startup and end | Reviewed NC blocks and controlled machine state |
| Tooling | Tool call, offsets, compensation IDs, pre-call, tool-change position | Correct control display and verified tool sequence |
| Motion | Rapid, feed, arcs, helical moves, rotary direction, limits, retracts | Code review, simulation, and safe physical motion |
| Cycles and options | Drilling, tapping, probing, macros, subprograms, high-speed modes | One explicit test for every claimed supported behavior |
| Documentation | Program number, comments, revision, setup sheet, post version | Traceable output tied to the released source |
Record the acceptance evidence, not only the verdict
The downloadable matrix ties one post version to one machine and controller, the exact NC file, simulation configuration, physical test, inspection result, defect, retest, and release decision.
Build small diagnostic programs before the representative part
A complex production part is good for final proof but poor for isolating defects. Build small programs that exercise one behavior at a time: tool change, each work offset, drilling cycle, rigid tapping, cutter compensation, helical interpolation, rotary indexing, probing macro, subprogram, coolant mode, and program end. Keep the geometry obvious enough that a reviewer can predict the required code.
Add boundary cases that expose formatting and state errors: negative coordinates, small and large arcs, full circles if used, repeated tools, operation suppression, multiple setups, unit changes only if supported, long program names, optional operations, and restart points. Include operations the post explicitly rejects so the error behavior is also known.
For a common ISO-style control, examples may include G17, G18, and G19 plane changes; G90 and G91 positioning; G40, G49, and G80 cancellation; work offsets; length and diameter compensation; and each approved cycle. These are test categories, not universal required codes. The machine builder’s programming manual defines the expected syntax and state.
Version the test suite with the post. When the post changes, regenerate the same cases and compare the output. A text comparison may include harmless changes such as timestamps or program numbers, so classify expected differences separately from changes to motion, state, speed, feed, or machine commands.
- Use one test file for each distinct machine and controller configuration.
- Keep expected NC snippets or review notes for critical behaviors.
- Include safe invalid cases that should stop posting or produce a clear warning.
- Store the CAM file, posted output, post version, machine configuration, and acceptance record together.
- Repeat affected and adjacent tests after every post modification.
Review the actual NC program before it reaches the machine
A qualified reviewer should trace the NC code against the requirements matrix and CAM operations. Check program identity, units, planes, coordinate mode, work offsets, tool calls, length and diameter compensation, spindle direction and speed, coolant, feeds, arcs, cycles, rotary commands, safe positions, macros, subprogram calls, optional stops, and program-end state.
Look for state that leaks between operations. A modal cycle, compensation mode, tilted plane, local coordinate shift, inverse-time feed, or high-speed control option may remain active unless the post cancels it deliberately. The visual toolpath can be correct while the control interprets the posted modal state differently.
Manual edits are defects in the post or process when they are required every time. Record them against the source post and test case. If an edit is truly job-specific, define who may make it, how it is reviewed, and how the released NC file records the change. Untracked edits destroy repeatability.
Simulation input matters
HCL markets CAMWorks Virtual Machine as actual G-code simulation and says it can eliminate dry runs. This guide does not adopt that safety conclusion. The machine model, controller emulation, fixtures, tools, offsets, parameters, physical setup, and approved shop controls must still agree.
Use simulation to answer specific questions
First use CAM simulation to inspect stock removal, tool and holder clearance, fixtures, leftover material, retracts, and operation sequence. Then use machine simulation if the configuration represents the machine’s kinematics, limits, rotary behavior, tooling, and workholding. Know whether the simulation consumes cutter-location data or the posted G-code because they test different parts of the chain.
HCL describes CAMWorks Virtual Machine as using the actual G-code rather than only cutter-location data. That can expose post-related motion and synchronization behavior that upstream simulation cannot. It still depends on an accurate virtual machine and does not prove the physical setup, offsets, clamp state, control parameters, or operator actions.
Document what the simulation includes and excludes. “Simulation passed” is too broad. Record the input file and hash, post version, machine and controller-template versions, stock, fixtures, tools and holders, limit and collision settings, warnings, reviewer, and unresolved assumptions. Preserve the exact NC file that will move to the control.
Simulate the CAM intent
Check stock, toolpath, holders, fixtures, retracts, remaining material, and operation order.
Simulate the machine layer
Use the approved machine configuration and understand whether the input is CL data or posted G-code.
Inspect every warning
Resolve or document limits, collisions, singularities, missing components, and unsupported control behavior.
Carry assumptions forward
List what software did not validate so the machine prove-out plan addresses it explicitly.
Move to the machine under controlled conditions
Prepare a prove-out package containing the approved program, setup sheet, stock, fixture, tools and holders, offsets, drawing, inspection plan, post and machine versions, known assumptions, and stop criteria. Record the released NC file’s name, size, timestamp, and hash before transfer, then verify that the file at the control is the reviewed output. Follow the machine builder’s and shop’s approved safe-start procedures.
Qualified personnel should verify setup, workholding, tool data, offsets, machine state, and clearances before commanded motion. Use the approved dry-run, graphics, single-block, feed override, rapid override, distance-to-go, or safe test methods that apply to that machine and organization. This article cannot prescribe a universal sequence because controls, machines, and risk controls differ.
A current Haas control manual illustrates why named limitations matter. On supported machines, Safe Run is intended to reduce damage and alarm sooner, but Haas states that it does not prevent crashes and detects jog and rapid motion rather than feed moves. Haas Graphics mode illustrates motion without moving the machine. Neither control feature replaces code review, setup verification, or the shop’s approved physical test.
Begin with diagnostic cases and then the representative part. Record every unexpected motion, alarm, output edit, operator intervention, surface issue, dimension result, and cycle behavior. Stop when the output differs from the requirements or the physical assumptions are uncertain. Correct the post or setup, regenerate from the controlled source, and repeat the affected tests.
| Gate | Pass condition | Stop condition |
|---|---|---|
| Identity | Machine has the exact reviewed NC file and setup package, matched by the approved identity check | Unknown revision, transfer change, hash mismatch, or undocumented edit |
| Setup | Qualified person verifies workholding, tools, holders, offsets, and machine state | Mismatch with the approved simulation or plan |
| Motion | Approved controlled checks behave as expected | Unexpected direction, state, limit, clearance, alarm, or command |
| Cut and inspect | Representative material, features, finish, and dimensions meet the plan | Unexplained process or quality result |
| Release | Defects closed and regression suite passed | Open safety, code, machine, or traceability issue |
Release the post as a controlled machine asset
Give the approved post a version, machine and controller assignment, owner, release date, supported capability list, known limitations, test-suite result, and storage location. Limit production editing and distribute the same released package to approved workstations. Make the post version and NC-file identity traceable in the program or setup record.
Route changes through a defect or improvement request containing the triggering CAM file, output, expected behavior, actual behavior, machine and control, risk, and reviewer. Modify the controlled source, run regression tests, repeat the required simulation and physical cases, then release a new version. Do not overwrite the only known-good post.
Review the post after CAM or control updates, machine option changes, post-engine changes, new operation classes, or repeated manual edits. A post is not universally “proved.” It is accepted for a defined machine configuration and tested scope, with a process for handling everything outside that scope.
Frequently asked questions
Is CAM simulation enough to approve a post processor?
No. Simulation is one evidence layer. Approval also requires review of the actual posted NC code, an accurate machine and setup context, machine-builder-approved controlled prove-out, first-article inspection, and documented acceptance for the named machine and controller.
What should a CAM post-processor test program include?
Include startup and shutdown state, tool changes, offsets, compensation, spindle and coolant commands, feeds, arcs, drilling and tapping cycles, rotary behavior, probing or macros, subprograms, safe retracts, and every claimed supported option. Add boundary and invalid cases.
Should programmers manually edit posted G-code?
Recurring manual edits should be treated as post or process defects. If a job-specific edit is authorized, define who can make it, how it is reviewed, and how the released NC file records the change. Untracked edits break repeatability and traceability.
When must a released post processor be retested?
Retest after post changes, CAM or post-engine updates, control updates, machine-option changes, new operation classes, machine-model changes, or repeated manual corrections. Run the regression set and repeat affected physical prove-out cases.
Vendor references and method
- SOLIDWORKS CAM product page, official desktop CAM and post-processing context
- HCL CAMWorks Virtual Machine, official description of actual G-code simulation
- HCL CAMWorks 2026 product page, official current machine simulation, kinematics, posts, and machine-model context
- Haas operator manual: Safe Run and Graphics Mode, official example of control-specific safe-check capabilities and explicit limitations
- Autodesk Support: proving a post processor, official cross-vendor example of diagnostic test files, manual NC review, and controlled physical testing
- Morphos 3D: CAM Migration Representative-Part Test, companion seven-gate acceptance method
- Checklists, sequencing, and decision gates on this page are Morphos 3D implementation guidance. Adapt them to the exact software release, infrastructure, machine, controller, quality system, and approved company procedures.
Prove one post on one real machine
Bring the machine and controller details, current post, accepted NC examples, representative part, tooling, and the specific behavior that needs to pass.