Table of Contents

Namespace Hi.Numerical.ClsfParsers

Classes

ClArcMcMotionSemantic

MC-machine counterpart of the ClArc branch of ClMotionSemantic: builds the workpiece-frame ClCircleArc from ClArcEvent, transforms it into the kinematic Pn frame (the workpiece→Pn transform wired on ProgramZeroToPnProvider), and emits ActClArcMcXyzabcContour — a true CL-space arc with per-step inverse kinematics. Endpoint machine coordinates come from MachineCoordinateState (this block, solved by ClToMcTransformSyntax + McXyzSyntax) and the previous block's modal state. Feedrate/rapid timing mirrors ClMotionSemantic; like the RTCP linear semantic, a feed move without a usable feedrate drops the motion (with a validation warning) instead of emitting zero duration.

ClMotionSemantic

Resolves the pure-CL motion forms into cutter-location acts that drive a ClMillingDevice chain directly — no machine coordinates involved: ClTeleport → ActClTeleport, ClLinear → ActClLinear, ClArc → ActClArc. Feed moves also emit ActFeedrate (from the modal Feedrate section); rapid moves emit ActRapid at RapidFeedrate_mmdmin. Durations are path-length / effective feedrate.

Contrast with ClLinearMcMotionSemantic, which handles the RTCP form ClLinear of the NC pipeline by deriving CL from machine coordinates — this semantic is its CL-source counterpart and reads endpoints from CutterLocationState instead.

ClMotionValveSemantic

Valve that routes each block to exactly one motion-semantic family, so the leaves keep a single duty and never need cross-guards:

The semantic-side counterpart of BundleSyntax composition: children are serialized nested under group elements and reconstructed via XFactory.
ClTeleportMcMotionSemantic

MC-machine counterpart of the ClTeleport branch of ClMotionSemantic: emits an instant ActMcXyzabcTeleport from the block's MachineCoordinateState endpoint solved by ClToMcTransformSyntax + McXyzSyntax. Mirrors the pure-CL teleport semantics — no machining step, no time accumulation.

ClToMcTransformSyntax

Endpoint inverse kinematics for driving an MC machine from CLSF input, expressed in the NC pipeline's transform vocabulary: when the pipeline's NcKinematicsDependency resolves to a live solver (the machining chain is an IXyzabcChain), each pure-CL motion block gets

Without a solver (pure-CL ClMillingDevice project) this syntax is inert and the pipeline stays pure CL.

Entry Kind follows the block's posture: when the solved rotary endpoint cyclically equals the previous block's modal state the entries are KindStatic (contour-valid), else KindDynamic (endpoint snapshot; path interpolation stays in CL space with per-step IK in ActClLinearMcXyzabcContour / ActClArcMcXyzabcContour). A ClLinear block whose finished chain has no Dynamic entry downgrades to McLinear — the same HasDynamicEntry(JsonObject) dispatch the NC pipeline uses, where MC-linear and CL-linear tip paths coincide and per-step IK is unnecessary.

When the endpoint cannot be solved (e.g. a tilted normal on a 3-axis machine) the block's MotionEvent (and arc payload) is removed together with its ProgramXyz and transform chain — so McXyzSyntax composes nothing and the modal MC lookback skips the unreachable block — and a validation error anchors to the CLSF line; the machine holds position over the bad block.

ClsfKeys

JSON section names and keys specific to the NX-CL (CLSF) pipeline. General sections shared with the NC/CSV pipelines (MotionEvent, Feedrate, SpindleSpeed, Coolant, ToolChange) keep their contracts from Hi.NcParsers.Keywords / ToolChangeSyntax.

ClsfRecordCleanupSyntax

Inspection-stage tail of the CLSF record chain. A record that survived every RecordTo* syntax is dispatched here:

  • words in ExcludedWords — intentional skips (PAINT, TOOL PATH, …), consumed silently;
  • UNITS — MM is the pipeline's native unit (silent); anything else keeps running but warns that coordinates are not converted;
  • SET_WORKPIECE — reported as ignored (the workpiece is project-level configuration, not runner input);
  • anything else — ClsfRecord--Unconsumed validation warning.
Must run after every other RecordTo* syntax.
ClsfRecordSyntax

Per-record CLSF parsing syntax. Normalizes the block text (strips $$ comments, joins $ continuation lines), splits it into the record word and its comma-separated parameters, and stamps them into JsonObject under ClsfRecordKey for the downstream RecordTo* syntaxes to consume. Numeric parameters are pre-typed to double.

The word is everything before the first / with whitespace runs collapsed — multi-word heads (TOOL PATH) and hyphenated records without parameters (END-OF-PATH) are single words, fixing the legacy parser's first-token-only dispatch.

ClsfRunnerConfig

Configuration dependency for the NX-CL (CLSF) runner: the rapid traverse rate (a CLSF has no machine axes, so RAPID timing needs an assumed rate), the tool-creation policy, and the intentionally skipped record words. Also serves as the pipeline's IRapidFeedrateConfig so the machine-coordinate motion semantics reused from the NC pipeline (McLinearMotionSemantic, ClLinearMcMotionSemantic) time rapids from the same assumed rates — axis-uniform: every linear axis gets RapidFeedrate_mmdmin, every rotary axis RotaryRapidFeedrate_degdmin.

ClsfSegmenter

Segments an NX CLSF (cutter location source file) stream for the SoftNcRunner pipeline. A record normally occupies one physical line; a line whose text (after stripping the $$ comment) ends with a single $ continues on the next line, so continued lines are joined into one multi-line Sentence for ClsfRecordSyntax to parse.

ClsfToolBuildSemantic

Materializes a milling tool from the modal ClsfToolData geometry (CLSF TLDATA/MILL) into the MachiningToolHouse when a ToolChange section requests a tool id the house does not hold — CLSF files carry their own tool definitions, so a project does not need to pre-configure every tool. With PreferToolHouse (default) an existing entry always wins. Emits no acts; must run before ToolChangeSemantic so the tool exists when the tooling act is executed.

MsysCoordinateOffsetSyntax

Expresses the modal CLSF MSYS frame in the NC pipeline's transform vocabulary on machine-coordinate motion blocks: the rotation part becomes a TransformSource entry (the G68.2 tilted-work-plane analogue) and the translation part becomes a TransformSource entry plus CoordinateOffset section (the G54 work-offset analogue, CoordinateId MsysCoordinateId) in ProgramToMcTransform. It also restores the commanded ProgramXyz — the MSYS-local GOTO point — from the workpiece-frame CutterLocationState endpoint, so the shared McXyzSyntax composes machine XYZ exactly like the NC pipeline: ProgramXyz × composed chain → MachineCoordinateState.

Entry order carries the math: the MSYS matrix maps local points as p·R + t (row-vector convention), so the rotation entry precedes the translation entry. Both are KindStatic — an MSYS is a fixed frame for every point of the blocks it governs. The rotation entry is omitted for a pure-translation MSYS (and for the absent-MSYS identity), keeping the common dump exactly G54-shaped.

Inert without a wired kinematics solver (pure-CL ClMillingDevice project) and on non-motion blocks: the pure-CL pipeline keeps its own CL vocabulary and must never receive ProgramXyz or a transform chain — McXyzSyntax would otherwise fabricate a MachineCoordinateState and misroute the block to the machine-coordinate semantics. ClToMcTransformSyntax continues the chain with the tool-height and kinematic-pivot entries.

NxClRunner

Factory for a SoftNcRunner that reads NX CLSF (cutter location source file) input. On a ClMillingDevice chain it resolves into pure-CL acts (ActClTeleport/ActClLinear/ActClArc); on an MC machine (IXyzabcChain, detected through the wired NcKinematicsDependency) each motion block is expressed in the NC pipeline's transform vocabulary — MsysCoordinateOffsetSyntax writes the MSYS work-offset entries plus ProgramXyz, ClToMcTransformSyntax inverse-solves the endpoint rotary state and writes the tool-height / kinematic-pivot entries, the shared McXyzSyntax composes MachineCoordinateState from ProgramXyz × chain — and ClMotionValveSemantic routes the block to the machine-coordinate semantics instead. The record chain maps each CLSF record into the same standardized JSON sections the NC/CSV pipelines use (Feedrate, SpindleSpeed, Coolant, ToolChange, MotionEvent), so the general semantics are reused unchanged; only the motion and tool-creation semantics are CLSF-specific.

The modal carry runs first in the record bundle (unlike the NC pipeline's carry-at-the-end): each piece receives the previous block's modal sections (Msys, CutterLocationState, tool data, feedrate, …) before its own record is resolved, so a GOTO reads its begin point and MSYS from its own piece and then overwrites the state with the new endpoint.

RecordToClMotionSyntax

Translates the CLSF motion records into the pure-CL motion contract:

  • RAPID → one-shot ClRapidEvent (armed until the next GOTO; a passed motion or FEDRAT cancels it).
  • CIRCLE/MOVARC → one-shot ClCircleEvent in workpiece coordinates, with the NX axis-direction negation applied.
  • GOTO → the modal CutterLocationState endpoint (MSYS applied) plus a one-shot MotionEvent whose Form is ClTeleport (first motion), ClArc (an armed circle record), or ClLinear; an arc GOTO also receives the consumed circle geometry as ClArcEvent.
Requires the pipeline's modal carry to run before this syntax on each node, so the previous endpoint / MSYS are already present on the current piece when the GOTO is resolved.
RecordToCoolantSyntax

Translates a COOLNT record into the standardized ICoolantDef section consumed by the general CoolantSemantic: ON/FLOOD → Flood, MIST → Mist, OFF → Off; other CLSF coolant modes fall back to flood with a configuration warning.

RecordToFeedrateSyntax

Translates a FEDRAT record into the standardized modal Feedrate section (always G94 — mm/min) plus the one-shot FeedrateEvent marker that cancels a pending ClRapidEvent. Accepted dialects: FEDRAT/MMPM,1400, FEDRAT/1400,MMPM, FEDRAT/1400 (MMPM assumed), and IPM (converted to mm/min).

RecordToMsysSyntax

Translates an MSYS record into the modal Msys section. The record's nine fields are a translation vector plus the first two rows of a rotation matrix whose third row is their cross product; the section stores the resulting 16-element row-major Mat4d mapping tool-path coordinates to workpiece (absolute) coordinates.

RecordToSpindleSyntax

Translates a SPINDL record into the standardized ISpindleSpeedDef section consumed by the general SpindleSpeedSemantic. Parameter order is tolerated (SPINDL/8000,RPM,CLW or SPINDL/RPM,8000,CLW): the first numeric field is the rpm, a field containing CCLW selects counter-clockwise, and SPINDL/OFF maps to STOP.

RecordToToolingSyntax

Translates the CLSF tooling records:

  • TLDATA/MILL,… → the modal ClsfToolData geometry section (kept for ClsfToolBuildSemantic); non-MILL tool types are reported and skipped.
  • LOAD/TOOL,n[,XOFF,x][,YOFF,y][,ZOFF,z] → the standardized ToolChange section (SectionName) consumed by the general ToolChangeSemantic; IsChangeKey is set when the tool id differs from the previously loaded tool. Offsets are recorded informationally (no consumer yet).