Glossary

The top-level CAM document object that owns a single machining project. Holds the Model, Stock, Operations, Tool Controllers, Setup Sheet, Post-Processor selection, and Machine.

A saved blueprint of a Job's configuration (post-processor, fixtures, output settings, setup-sheet defaults, tool controllers, stock, machine reference) for reuse on new projects. Serialized via the JobTemplate class as XML attribute strings. Distinct from a Machine Template — different file format and scope. Avoid: bare "template" (always qualify as Job Template or Machine Template).

The App::DocumentObjectGroup named "Model" that the Job owns and exposes through its Model property. Holds one or more Models as Resource Clones. Access the individual models via Job.Model.Group. Avoid: "Models" (plural noun for the collection), bare "Model group" (always qualify as Job Model Group). Note: the property name is singular (Job.Model) but the contents are plural — a frequent source of confusion. The singular property holds the group container; the group holds the models.

A part being machined. Referenced by the Job Model Group as a Resource Clone so the original geometry is not mutated. A Job may carry multiple Models (e.g. for multi-part fixturing or assemblies machined together); they are all held in the single Job Model Group. Avoid: Part, workpiece (in code/UI — "Model" is the canonical name).

The raw material the Tool Bit cuts away from. Visualization-only — does not constrain toolpaths. Stock has a type: FromBase (derived from the Model with offsets — "base" here = the Model, not Base Geometry), CreateBox, CreateCylinder, or NoStock. Avoid: blank, billet, raw.

A Draft.clone of a base object tagged with a PathResource property identifying its role (e.g. "Model"). Used so the Job has its own reference to geometry without owning it.

A container on the Job holding default values and Job-specific defaults (rapid speeds, safe-height expressions, depth expressions, fixtures). New Operations read defaults from here. Avoid: defaults file, config (these are domain-vague). Note: clashes with the industry term "setup sheet" (a printed shop-floor document describing how to set up a part). In this codebase, "Setup Sheet" always means the defaults container — never the shop-floor document. The closest analogue to the industry meaning is the Sanity Check report.

A work-coordinate-system selection (G54–G59.9) under which a set of Operations is output. A Job can output multiple fixtures. Avoid: WCS (used in code occasionally), work offset, clamping (this is not the physical workholding). Note: clashes with the industry term "fixture" meaning the physical workholding device. In this codebase, "Fixture" always means the WCS. A future initiative may revisit this naming. Note: distinct from Work Plane. A Fixture is a control-side selection that carries no geometry; a Work Plane is part geometry the workbench knows exactly. See Work Plane.

A single machining step that produces a Toolpath — e.g. a pocket, a profile, a drilling cycle. Op is a synonym, used as code shorthand (filenames, variable names, Path/Op/). Inherits from the internal base class ObjectOp (Path/Op/Base.py). Configured by Feature flags + properties + Base Geometry + a Tool Controller. Avoid: step, task, action. ObjectOp is internal — not a domain term.

A named selection between alternative algorithms within an Operation that share the operation’s framework but differ in their motion or behavior. Currently exposed concretely as the App::PropertyEnumeration property Strategy on Drilling (values: "Drilling", "Tapping"), which supersedes the standalone Tapping op. The concept extends informally to other algorithmic choices — for example, a linking strategy governs how rapids and lead-ins connect successive cuts; a clearing strategy chooses between offset, zigzag, and spiral patterns within a pocket — though those choices are not all yet exposed as named Strategy properties. Avoid: mode (acceptable in legacy properties like CutMode, but Strategy is the canonical forward-going term for "which algorithm"), pattern (use only when describing a geometric pattern itself, not the algorithm choice), kind, type. Distinct from Generator — a Strategy uses one or more Generators to build its motion; they are not interchangeable.

A bit-flag (FeatureTool, FeatureDepths, FeatureHeights, …) that an Operation ORs together to declare which standard properties it supports. Distinct from FreeCAD’s generic notion of "feature" (a document object).

The user-selected geometry on the Model (faces, edges, vertices) that an Operation acts on. Stored on the operation as the Base property. Canonical term — the bare word "Base" is not a domain term and only appears as code-internal naming (Path/Base/, ObjectOp.Base, FromBase). Avoid: target, selection, input geometry, "Base" alone.

A predicate applied to a candidate face. A face is drillable with respect to a given Tool Bit diameter and an approach vector (machine pose). The Path/Base/Drillable.py module supplies the classifier predicates (e.g. isDrillableCylinder) used by Circular Hole operations to filter selectable Base Geometry. Avoid: "drill candidate", "hole feature" (those are not the predicate).

Still loads, executes, and post-processes, but is superseded and will be removed in a future release. A deprecated op declares a Deprecation Notice by overriding opDeprecationNotice(obj) on its ObjectOp subclass; the base class logs the notice when a document is restored and the op’s task panel shows it as a banner. The notice names the replacement and says whether new instances can still be created — an op whose command has been removed from the menus (Tapping, Face) cannot be created, only edited. A notice may be conditional on property values, so a single configuration of an op can be deprecated while the op itself is not (Surface with ScanType="Rotational"). Wording comes from Path.Op.Base.deprecationNotice() so every notice reads the same. Avoid: legacy (says nothing about removal), obsolete, retired, "old X". Removing a command from the menus without a Deprecation Notice is not deprecation; it is silent removal.

Avoid: "axial stepover", "radial stepdown" (qualifier is redundant — Step Over is always along-surface, Step Down is always into-material). For rotary ops, just say Step Over and Step Down; the axial/radial mapping is implicit.

A final cutting pass that follows a new toolpath offset from the roughing passes, removing only a thin, controlled amount of material (the Finish Depth when depth-based, or a lateral allowance when offset-based). The purpose is surface quality: a light, consistent cut produces a better finish than the variable remainder left by roughing. A Finish Pass is not a repetition of the previous pass — it has its own geometry. Avoid: conflating with Spring Pass.

An exact repetition of the immediately preceding cutting pass with no change in depth, offset, or feed. Its purpose is deflection recovery: the first pass leaves a thin witness of uncut material because tool and workpiece deflect under load; the repeat pass, seeing almost no load, springs back to true and cleans the witness. Not currently implemented as a first-class feature in the CAM workbench, but the concept is distinct from Finish Pass. Avoid: conflating with Finish Pass. A Finish Pass follows a new toolpath with a controlled allowance; a Spring Pass re-runs the same toolpath to recover deflection.

Note: the F&S subsystem groups these into a smaller cutting-kind vocabulary (OP_TYPES in Path/Tool/FeedsSpeeds/types.py: profile, pocket, slot, drill, adaptive, surface_finish). The mapping is many-to-one — Tapping/Drilling/Helix all map to "drill", Mill Facing maps to "surface_finish", etc. The two vocabularies are intentionally different: the Operation catalog enumerates user-facing op kinds; OP_TYPES enumerates F&S-relevant cutting kinds.

Not a domain term. Always disambiguate to Tool Bit, Tool Controller, Tool Library, or Tool Shape. The compound names below are the only canonical forms.

The runtime pairing of a Tool Bit with Spindle Speed, Horizontal Feed, Vertical Feed, and rapids. Operations reference a Tool Controller, not a Tool Bit directly. Lives under the Job's Tools group. F&S values may be hand-entered (recorded as "user" provenance) or filled by the Resolver via the F&S dialog; per-field source is tracked in Feed/Speed Provenance. Avoid: tool slot, tool assembly (in CAM-workbench code; "Tool Controller" or "TC" only).

The cutter itself — geometry, cutting edges, dimensional parameters. Has a Tool Shape classifier: Endmill, Ballend, Bullnose, Chamfer, Drill, VBit, Dovetail, Reamer, SlittingSaw, Tap, ThreadMill, Probe, TaperedBallNose, Radius, Custom. May carry one or more F&S Presets, persisted in the .fctb file and editable in the ToolBit editor’s Presets tab. Avoid: cutter, bit, end mill (when speaking of the abstraction — use the specific shape name when speaking of the kind).

A persisted collection of Tool Bits, serialized to disk. Independent of any Job — libraries are shared across projects.

The geometric template for a Tool Bit. Defines the parametric shape used to render and (for some operations) compute engagement.

The rotational speed of the cutter, in rpm. Stored on the Tool Controller as SpindleSpeed. The range a machine can actually deliver is stored separately, on the Machine's Toolhead as min_rpm/max_rpm. Avoid: rpm (a unit, not a name), S-word (G-code term, not a domain term).

A commanded rate of travel along a Toolpath, in mm/min. Horizontal Feed and Vertical Feed are the stored forms. A feed is a property of the path, not of any one axis: relating a feed to a machine’s per-axis limits means resolving the move through the machine’s kinematic chain, and for a machine with rotary axes the meaning of the emitted F word is controller-specific. Avoid: velocity (reserved for the per-axis machine limit — see Axis Velocity), speed (reserved for Spindle Speed), feedrate.

The cutting feed for XY motion, in mm/min. Stored on the Tool Controller as HorizFeed. Avoid: feedrate (ambiguous between horizontal and vertical), F-word (G-code term).

The plunge feed for −Z motion, in mm/min. Stored on the Tool Controller as VertFeed. May also be expressed as a ratio of Horizontal Feed (the Vert Feed Ratio on a Preset). Avoid: plunge rate (acceptable in user-facing prose; in code use Vertical Feed).

The speed of a point on the cutting edge relative to the workpiece, in m/min. Equivalent to "SFM" (Surface Feet per Minute) in imperial units. Determined primarily by the workpiece material and the tool’s material; together with tool diameter it gives Spindle Speed: rpm = (Vc × 1000) / (π × diameter_mm). Avoid: SFM (imperial-only — the codebase uses m/min throughout). "Cutting speed" is acceptable in user-facing prose; in code identifiers use surface_speed.

The thickness of material removed by one cutting edge per revolution, in mm/tooth. Together with Spindle Speed and flute count it gives Horizontal Feed: feed = rpm × flutes × chipload. Avoid: feed per tooth (acceptable but verbose), chip thickness (overlaps with effective chip thickness in chip-thinning contexts).

A named F&S record stored on a Tool Bit specifying Surface Speed, Chipload, and an optional vertical-feed ratio for a (material, op-type) combination. Multiple presets per tool. Storage is engineering-only — raw feed (mm/min) and raw spindle speed (rpm) are derived at use-time from preset values plus the tool’s geometry; they are not persisted. Avoid: default, recipe, profile (overlaps with the Profile op), rule (rules are a separate, broader concept planned for Phase 2).

A pluggable object that suggests F&S values from one source (a Preset, a future vendor catalog, a future formula). Implements suggest(tool, material, op) → PartialResult | None. Phase 1 ships ToolPresetProvider and ToolDefaultsProvider. Avoid: source, lookup, calculator (these collide with adjacent concepts).

The pure function resolve(tool, material, op) → FeedSpeedResult that walks a chain of Providers in priority order and merges their contributions. GUI- and FreeCAD-Document-independent at the boundary; testable from fixtures without a running FreeCAD process. Avoid: calculator, suggester, engine.

A per-field record on a Tool Controller identifying where each F&S value came from: "user" for hand-entered values, or a source string from a Provider (e.g. "preset:tool/aluminum-6061/profile"). The Resolver never overwrites a field whose provenance is "user". Avoid: source (too generic — the property is named FeedSpeedProvenance), origin.

A sequence of motion commands (G0/G1/G2/G3/…) attached to an Operation. The output of opExecute(). Canonical user-facing and docs term. Avoid: trajectory, motion plan, "path" (lowercase, as a noun).

The Python namespace Path. and source tree Path/. Legacy name, retained for backwards compatibility after the Path → CAM workbench rename. Not a domain term — never use bare "Path" to mean *Toolpath in docs or UI. The PathScripts.* namespace (e.g. PathScripts/PathUtils.py) is also legacy and is being migrated into Path/; treat it as code-internal only.

A low-level motion-pattern function in Path/Base/Generator/ (drill, helix, tapping, spiral facing, zigzag facing, linking, etc.). Operations call generators to produce specific motion segments. Avoid: strategy, planner, G-code generator (use Post-Processor for that — never conflate the two).

The frame an Operation works in: a named Part::LocalCoordinateSystem held in the Job's Workplanes group, which several Operations may link to. Its local +Z is the Tool Axis. An Operation with no Work Plane works in the Job's own XY, which is ordinary Z-up milling. A Work Plane that is not parallel to the table makes an operation Indexed: the machine’s rotary axes position the part so the tool points along the frame’s +Z, then cut a conventional three-axis program in that frame. An Operation generates in its Work Plane's frame: the plane’s origin is zero, its X is the plane’s X, and the Tool Axis is Z, so every depth and height is a distance along the Tool Axis from the plane and every direction-sensitive parameter is relative to the plane’s X. Its Toolpath is stored in that frame with no rotary words, and the Operation's Placement positions it — the convention the simulators, Inspect and the posts read through getPathWithPlacement(). A Dressup generates in its base Operation's frame and carries that operation’s Placement, so everything downstream reads a dressup as it reads an operation. Generation knows nothing about the Machine: the Post-Processor solves the rotary positions from the Placement at output time and expresses the path in the form the Machine's Rotation Strategy names, so changing the Machine means re-posting, not recomputing. A plane the Machine cannot index to is refused there, naming the plane and the rotary limits; the Operation only warns. A Work Plane may name a Fixture: the Post-Processor selects it before positioning for the plane and returns to the Job's Fixture afterwards; the Job's Fixtures list, which repeats the program per part, is not involved. Any plane can be created on any Job, and every Operation generates its path in its plane; whether the Machine can reach a tilted one is the Post-Processor's question, not creation’s or generation’s. Avoid: work coordinate system, WCS, local coordinate system, indexed frame, bare "plane", tilted plane. Note: PathScripts.PathUtils.makeWorkplane() uses the word for something unrelated — a circle at a shape’s ZMin handed to Path.Area as its projection plane. That is a non-use of the term; the function should be renamed.

The direction the tool points, from the part toward the tool. For an Indexed Operation it is the Work Plane's local +Z and is constant for the whole operation. Named separately from Work Plane because beyond indexed work it varies along a Toolpath and stops being a property of the operation. Avoid: tool vector, spindle axis, approach direction, "up".

Rotary axes position the part or head and are stationary while cutting; each cut is three-axis-shaped in the Operation's Work Plane. Contrast Simultaneous, where rotary axes move during the cut, which is not supported. Avoid: multi-axis as a synonym — it spans both; positional.

A wrapper object that takes an Operation's Path and modifies it in-place: holding Tags, Boundary trimming, DogboneII corner relief, Array duplication. A dressup replaces its child operation in the Job's output sequence. It has no Work Plane of its own: it reads its base operation’s stored Path, in that operation’s plane frame, edits it there, and stores the result in the same frame with the base operation’s Placement, re-derived on every recompute (Path.Dressup.Utils.placeWithBase()). workplaneForOp() resolves a dressup’s frame through its base. Avoid: post-modifier, path filter, decorator.

A small bridge of uncut material left on a Profile so the part doesn’t move when fully cut through. Created via the Tags Dressup. Avoid: tab (industry alternate; we use "tag").

The component that converts a Job's Paths into machine-specific G-code text. Selected per-Job. Lives in Path/Post/scripts/ as <machine>_post.py. Avoid: G-code generator, exporter.

A description of the physical CNC machine: axes (linear/rotary, table/head), units, limits, plus post-processor formatting settings (line numbers, comment style, header content). Configured via the Machine Editor UI and saved as .fcm files. Avoid: controller (overlaps with Tool Controller), CNC.

The powered element of a Machine that carries the tool: a rotary spindle, laser, plasma torch, or waterjet. Stored on Machine as toolheads, each carrying its type, power, tool-change mode, and — for rotary toolheads — the min_rpm/max_rpm range. Canonical term, because "spindle" names only the rotary kind. Machine.spindles, add_spindle and get_spindle_by_* are legacy aliases kept for compatibility; new code should say Toolhead. The model does not currently mark one Toolhead as active for a Job. Avoid: spindle (unless the rotary type specifically is meant), head, tool holder.

The maximum rate at which one machine axis can move, stored on Machine as max_velocity per LinearAxis (mm/min) or RotaryAxis (deg/min). A per-joint hardware limit, distinct from Feed, which is a commanded path rate. Consumed by simulation and cycle-time estimation, not by Sanity Check. Avoid: max feed, feed limit, rapid rate.

How a Machine runs an Indexed Operation, declared in its kinematics and read by the Post-Processor. One of: * DWO (dynamic work offset; Haas G254, Fanuc G54.2/G54.4) — the post commands the rotary positions and emits the path rotated into the frame the machine reaches; the control applies its pivot offsets. * TWP (tilted work plane; Fanuc G68.2, Haas G268, Heidenhain PLANE SPATIAL) — the post declares the Work Plane's origin and orientation in its Plane Command, and emits the path in the plane’s own coordinates, exactly as stored; the control positions the rotaries and applies the pivot. The plane is cancelled before a tool or fixture change. * Post-transform — no control support; the post would rotate every coordinate about the machine’s measured pivots. Declared but not emitted yet. A Machine with rotary axes and no strategy refuses to post an Indexed Operation. The strategy is the machine’s, not the operation’s: the same Job posts to any of them. Whenever the rotary axes move, the Machine's Pre-Rotary Move and Post-Rotary Move blocks wrap the move; the moves that bring the tool clear of the part belong in the first, in machine coordinates, and the Sanity Check warns when the rotaries move between Operations and that block is empty. Legacy Post-Processors refuse Indexed Operations: multi-axis output is for Post-Processors of the current kind. Avoid: output mode, rotation mode, 3+2 mode.

The Tilted Work Plane command family a Post-Processor writes for the TWP Rotation Strategy: the command words and, with them, the angle convention (G68.2/G268 take intrinsic Z-X-Z Euler angles, PLANE SPATIAL takes spatial angles about the fixed machine axes). It belongs to the post, not the Machine, because the control family is what selecting a post means; the Machine declares only which strategy its control can run. Whether the command positions the rotaries itself (G53.1, TURN) is a Post-Processor Property at Machine scope, as are the declare, align and cancel lines for a control with a variant spelling. Avoid: TWP dialect, plane mode.

JSON serialization of a Machine definition. Templates ship in Machine/machines/ and are loaded into a Job. Distinct from a Job Template — different file format and scope. Avoid: machine config, machine profile, bare "template".

The dialog shown when generating G-code from a Job (DlgPostProcess). Its Overview tab carries Run scope Post-Processor Properties; its Options tab carries Job scope ones. Avoid: export dialog, output dialog, post dialog.

A single named setting in a Post-Processor's property schema (get_full_property_schema()), stored by name in a Machine's postprocessor_properties. Every property declares a Property Scope. Avoid: post argument, post option, post parameter (those name the legacy --arg command line, which is a different mechanism).

The tier at which a Post-Processor Property may be edited. Exactly one of: * Machine scope — edited in the Machine Editor only, and suppressed in the Post-Processing Dialog. Describes the machine or controller itself and must not vary between runs (e.g. file extension, comment style, axis precision). * Job scope — the Machine Editor sets the default; the Post-Processing Dialog's Options tab overrides it for a single run. Persisted in the Machine Template, overridden via Job.PostProcessorPropertyOverrides. * Run scope — edited only on the Post-Processing Dialog's Overview tab, never shown in the Machine Editor, and never persisted. Applies to one export (e.g. dry-run and marking-only switches). * Internal scope — never presented in any UI; derived rather than user-set.

Scope declares where a property may be edited, which is independent of where it was declared (the common schema on PostProcessor versus a Post-Processor's own get_property_schema()). The scopes correspond one-to-one with the merge tiers in build_configuration_bundle(). Avoid: runtime property (the deprecated runtime: True spelling means Run scope), per-run flag, override level.

A pre-output validation pass over a Job that produces an HTML Sanity Check report flagging missing tools, unset feeds, suspicious depths, etc. Canonical user-facing term. Avoid: linter, validator, pre-flight check, job report.

A single finding emitted by a Sanity Check. Carries a note, an originating operator, and one of four types: NOTE, TIP, WARNING, CAUTION. WARNING and CAUTION are treated as critical and can block output. The term is aviation-derived and is used throughout the code; keep it. Avoid: warning (that is one of the four types, not the category), message, issue, error, violation.