Table of Contents

Cutter-Location (CL) Playback

PlayClFile replays a CAM cutter-location file — an NX CLSF (.cls) / APT-source toolpath — directly as tool motion, without a post-processor. Use it to verify the programmed toolpath itself (gouge, overcut, engagement) before it is post-processed for any particular machine.

The same file can also be played onto a real machine-tool chain, and a played CL program can be written back out as Fanuc NC — see Two chains, two questions and Converting CL to NC.

CL vs. NC — two different inputs

PlayNcFile (NC / G-code) PlayClFile (CL / CLSF)
Source Post-processed G-code for one specific machine CAM cutter-location output, before post-processing, machine-independent
Content Axis moves (G01 X.. Y.. Z..), work offsets, canned cycles Cutter locations (GOTO), arcs (CIRCLE), tool axis vectors
Drives A machine-tool chain (X/Y/Z/A/B/C axes) through kinematics Either chain — see below
Answers “What does this machine do with this program?” “Is the programmed path correct?” — or, on a machine chain, both questions at once

A cutter location is a point plus a tool-axis direction in workpiece coordinates. PlayClFile places the tool at each location in turn and sweeps the removed material between them.

Two chains, two questions

The chain configured in project setup decides what a CL play means.

On a ClMillingDevice the cutter location is applied straight to the tool: no inverse kinematics, no work-coordinate offsets, no controller dialect. This is the machine-independent check — it answers whether the CAM output itself is correct, and it is the right chain when you do not yet know which machine will run the job.

On a machine-tool chain every CLSF motion endpoint is inverse-solved at parse time and expressed in the same program-to-machine transform vocabulary the NC pipeline uses — a tool-height entry from the active tool, a pivot entry anchored to the workpiece frame, and the solved rotary axes — so the shared machine-coordinate and rotary-wrap handling is reused unchanged. This answers what a particular machine would do with the path, including reach and rotary behaviour, without a post-processor in between.

Note

A machine-chain play needs the project's kinematics to resolve to a live solver. Where an endpoint cannot be solved, the motion is reported rather than silently dropped — watch for ClToMc--EndpointIkFailed and ClToMc--NoToolOffset in the diagnostics.

Converting CL to NC

ConvertClToNcFiles writes a played CL program back out as Fanuc NC, one file per source file, template-substituting [NcName] (default Output/[NcName].nc). It requires a prior play on a machine chain — a ClMillingDevice leaves no machine-solved data to serialize — and reports ConvertClToNc--NoPlay otherwise. A mission can declare the writeback through EnableConvertClToNcFiles and ClToNcFileTemplate.

File format

The reader parses NX CLSF records (the APT-source language):

Record Effect
GOTO Cutter location — first one positions the tool (rapid teleport); subsequent ones cut a straight CL path
CIRCLE / MOVARC Arms an arc; the following GOTO closes it into a true circular CL path
RAPID Marks the next move as a non-cutting rapid
FEDRAT Feed rate (MMPM / IPM)
SPINDL Spindle speed and direction
COOLNT Coolant mode (ON / FLOOD / MIST / OFF)
TLDATA Tool geometry (diameter, corner radius, length, angles)
LOAD/TOOL Tool change to a tool id

Comments ($$ to end of line) and line continuation (trailing $) are honored. Records outside this set (PAINT, TOOLNO, TOOL PATH, …) are skipped.

Note

“APT” here means the APT toolpath language (GOTO, CIRCLE, …). This is a different use of the word from the APT Tool page, which defines cutter geometry. A CL file's TLDATA feeds that same tool-geometry model — see below.

The dialect parsed is Siemens NX (.cls). Other CAM systems emit the same APT record family under different names (CATIA APTSOURCE, Creo CL files); those dialects are not yet parsed.

Tools from the file

A CL file usually carries its own tool definitions. On LOAD/TOOL,<id>, if the tool house has no matching id, the preceding TLDATA geometry is used to create the tool automatically. An id already present in the tool house keeps its configured tool — so you can pre-configure tools for accuracy, or let simple files be self-contained.

Example

// The machining chain must be a ClMillingDevice (set in project setup).
MachiningResolution_mm = 0.125;
EnablePhysics = false;             // geometry-only check first
PlayClFile("CL/part-op10.cls");    // replay the CAM cutter-location file
Diff("target/part-op10.stl");      // compare the cut against the design target

The project keeps a dedicated CL runner suit (ClsfRunnerSuit) alongside its NC and CSV suits; the parser itself is the NxClRunner preset.

See Also