Toolpath Generation & G-code Output
Relevant source files
The following files were used as context for generating this wiki page:
Toolpath Generation and G-code Output represent the final stages of the CAM (Computer-Aided Manufacturing) workflow. This system translates internal geometric toolpaths into machine-specific G-code instructions. The process involves defining machining operations, calculating tool movements based on geometry and cutting parameters, and utilizing a Post-Processor to format the output for a specific CNC controller.
The architecture is designed to support professional CNC workflows while remaining extensible through Python scripting. Key components include the Job, which acts as the top-level container, and the Post-Processor, which handles the final dialect conversion. The system emphasizes open standards and supports various machining strategies such as pocketing, profiling, and drilling cycles.
Sources: src/Mod/CAM/Roadmap/README.md:16-21, src/Mod/CAM/Roadmap/ADR/ADR-000.md:14-17
Architecture and Data Flow
The output pipeline follows a structured flow from the high-level Job definition to the physical G-code file. A Job encapsulates the model, stock, tool controllers, and operations. Each operation executes to produce a Toolpath, which is a sequence of motion commands (G0, G1, G2, etc.). These toolpaths are then passed through the Post-Processor.
The diagram shows the sequential flow from Job definition to the final G-code generation, including the intermediate sanity check stage.
Sources: src/Mod/CAM/Roadmap/ADR/ADR-000.md:14-17, src/Mod/CAM/Roadmap/ADR/ADR-000.md:111-125
Toolpath Generation Logic
Internal toolpaths are sequences of motion commands attached to an Operation. The system uses Generators—low-level motion-pattern functions—to build specific segments such as drills, helices, or zigzag facing patterns.
Core Components
- Operation (Op): A single machining step (e.g., Pocket, Profile) that inherits from
ObjectOp. - Generator: Functions in
Path/Base/Generator/that produce specific motion segments. - Dressup: A wrapper that modifies an operation's path in-place (e.g., adding tags, boundary trimming).
- Toolpath: The output of
opExecute(), consisting of motion commands like G0 (rapid), G1 (linear), G2/G3 (arcs).
Sources: src/Mod/CAM/Roadmap/ADR/ADR-000.md:65-71, src/Mod/CAM/Roadmap/ADR/ADR-000.md:111-135
Machining Strategies
The system supports several operation types, each with specific logic for generating toolpaths:
| Operation Type | Description | G-code Support |
|---|---|---|
| Drilling | Canned-cycle drilling on circular holes. | G81, G82, G83, G73 |
| Pocketing | 2.5D or 3D area clearing inside a boundary. | Linear/Arc segments |
| Profile | Cuts along a contour (inside/outside/on-line). | Linear/Arc segments |
| Adaptive | Constant tool engagement clearing. | High-efficiency paths |
Sources: src/Mod/CAM/Roadmap/ADR/ADR-000.md:88-105, src/Mod/CAM/Roadmap/Functionality/Operation Configuration.md:60-70
Output Pipeline and Post-Processing
The Post-Processor is the critical component that translates internal motion commands into the dialect required by a specific machine controller (e.g., LinuxCNC, GRBL, Mach3).
Post-Processor Architecture
The project is currently transitioning from "Legacy" post-processors to a "Refactored" object-oriented architecture.
- Legacy Post-Processors: Contained in a single file per machine. Easy to modify individually but hard to maintain due to code duplication.
- Refactored Post-Processors: Utilize inheritance and shared code in the
PostProcessorclass withinProcessor.py. This approach reduces file size and makes testing more efficient.
Sources: src/Mod/CAM/Roadmap/Epics/ImprovePostprocessors.md:13-50
Machine Definition
The output is also governed by the Machine definition, which describes physical attributes:
- Axes: Linear and rotary configurations.
- Limits: Machine travel constraints.
- Formatters: Settings for line numbers, comment styles, and headers.
Sources: src/Mod/CAM/Roadmap/ADR/ADR-000.md:144-150
Sanity Check and Validation
Before final G-code generation, a Sanity Check (CAMSanity) pass is performed. This produces an HTML report flagging potential issues such as missing tools, unset feed rates, or suspicious machining depths.
The sequence shows how the Sanity Check system analyzes a Job and uses the ReportGenerator to produce user-readable feedback.
Sources: src/Mod/CAM/Path/Main/Sanity/ReportGenerator.py:53-125, src/Mod/CAM/Roadmap/ADR/ADR-000.md:158-161
Data Structures in ReportGenerator.py
The ReportGenerator class processes several data blocks to build the final output validation:
baseData: Core job information.toolData: Attributes of the tools used in the job.fixtureData: WCS and work offset information.squawkData: Error and warning messages (labeled as "Squawks").
Sources: src/Mod/CAM/Path/Main/Sanity/ReportGenerator.py:105-115
Conclusion
The Toolpath Generation and G-code Output system provides a robust framework for converting 3D models into CNC instructions. By separating motion generation logic from post-processing dialects and incorporating pre-flight sanity checks, the system ensures both flexibility for developers and reliability for machine operators. Future initiatives focus on improving post-processor customizability and expanding support for multi-axis configurations.
Sources: src/Mod/CAM/Roadmap/README.md:27-35, src/Mod/CAM/Roadmap/Epics/ImprovePostprocessors.md:73-85