Table of Contents

Heidenhain Controller Support

Heidenhain programs run on a single controller preset that reads both dialects — TNC klartext (TNC 640 / TNC 530 conversational) and Heidenhain DIN/ISO. There is no separate selection to make: pick Heidenhain as the project's controller and the program is read in whichever dialect it is written in.

Coverage is stated in the same three states as General NC Code Support — supported, recognized but not simulated, and not supported. Recognized but not simulated is a deliberate state: the construct is consumed and reported under its own message id, so it can never be silently misread as something else. A PLANE AXIAL B+45 will never be mistaken for a rotary-axis command.

Program format

Separators are optional

Klartext is normally written with spaces between the letter instructions, and that is what the control shows. Some post-processors emit the same program with no separators at all. Both forms parse, and so does the detached feed spelling.

Equivalent, all parsed:

  • L X-26.3 Y+43.1 Z+100.3 A-90.0 C+13.123 FQ3 and LX-26.3Y+43.1Z+100.3A-90.0C+13.123FQ3
  • L X+0 Y+0 R0 FMAX and LX+0Y+0R0FMAX
  • FMAX M03 M08 and FMAXM03M08
  • F20000 and F 20000

Multi-line blocks

A statement broken across lines with the tilde continuation — the usual shape of a CYCL DEF body or a long PLANE statement — is joined back into one block before parsing, so it is read as the single statement it is.

Motion

Construct Support
L Straight-line motion with its axis words, absolute or I-prefixed incremental. See Incremental axis words.
LN Surface-normal block — a straight line carrying the endpoint plus up to two normalized vectors, in the fixed element order X,Y,Z → NX,NY,NZ → TX,TY,TZ. The endpoint words take the I prefix; the vector words have no incremental form. See Vector blocks.
FMAX Rapid traverse.
CC / C Circular motion — CC sets the pole, C states the end point. DR- is clockwise and DR+ counter-clockwise, the centre always comes from the modal CC rather than from the C block, and an arc that closes on its start point is a full circle. Both heads accept I-prefixed words — an incremental pole on CC, an incremental end point on C. See Arc centres.
RL / RR / R0 Radius compensation left / right / off.
M91 One-shot machine-coordinate move for that block.
M126 / M127 Shortest-path rotary traverse on / off. With neither stated, shortest path is the default. An I-prefixed rotary word is exempt either way — see Incremental axis words.
M140 MB+n / M140 MB MAX Tool-axis retract — by n mm, or to the positive Z stroke limit. Without a configured stroke limit, MB MAX reports M140--NoStrokeLimit and is skipped. The statement's own F drives the retract without entering the modal feedrate.
STOP Program stop, alongside M00 / M01.
CYCL DEF 32 TOLERANCE Path-smoothing tolerance.
BLK FORM Recorded as a stock declaration. It does not replace the workpiece configured in the project.

Incremental axis words (I prefix)

An axis word may carry the I prefix — IX+20, IY-15, rotary IC+90 — and is then a relative value rather than a coordinate. Five statement heads read the prefix: L, C, CC, LN and CYCL CALL POS. On the first four it is a distance from the last programmed position; CYCL CALL POS spells it the same way but measures from the coordinates of the previous CYCL CALL POS, and is described under Cycles and calls. L, C and LN take the full axis set, rotary letters included; CC and CYCL CALL POS take X / Y / Z only, because neither positions a rotary axis.

The prefix is per word, not a mode — klartext has no modal G90 / G91 counterpart, and only the I-marked words of a block are read as distances. Absolute and incremental words therefore mix freely inside one block.

Parsed:

  • L IX+20 IY-15 — both axes relative
  • L X+60 IY-10 — to X 60, and by −10 in Y
  • LIX+20IY-15 — glued, exactly as the separator-free absolute form parses
  • L IX5 — the sign is optional
  • L IZ+Q2 and L IY-Q2 — the value grammar behind the prefix is the shared one, so a Q parameter or a bracket expression reaches it like any other value

A rotary I word is a chain dimension — a signed traverse — and keeps the value it accumulates instead of being folded into the ±180° shortest-path window: IC+270 from 75° ends at 345°, not at −15°. That exemption is per word and per block. It does not turn shortest path off for the rest of the block: an absolute rotary word on the very same block is still taken the short way round, and M127 remains the modal switch.

One further I spelling on this control is not this mechanism at all: the CYCL DEF 7 datum-shift words shift the active datum rather than positioning an axis, and are described under Datums.

Arc centres (CC)

A C block never states its own centre. Each in-plane component is resolved from the modal CC section: the CC block's own axis word first, then the same axis of the previous CC, and last the arc's own start point. A CC stating no coordinates is the one spelling that supplies all three at once — it takes the last programmed position, read at the CC block rather than at the arc, and replaces the modal centre instead of inheriting it. That is what makes the manual's own shape work: CC on the centre, a move out to the arc start, then the C block.

An incremental centre is not that spelling. CC IX+0 IY+11 states a centre — a distance from the last programmed tool position, never from the previous centre — and it is absolute by the time the arc consumes it. Nor is a CC whose coordinates cannot be read: it leaves residue and reports UnparsedText--Remaining, and because it states no centre every axis falls through the modal chain — to the same axis of the previous CC where there is one, and only otherwise to the arc's own start point as below. Either way the position of the unreadable CC block is never read as the centre.

A centre that lands on the arc's own start point leaves the block with no radius and so no arc geometry: it reports Arc-CircleCenter--OnStartPoint and is degraded to a straight move to the endpoint. One in-plane coordinate is enough to escape that — an arc whose modal chain still leaves the other coordinate to the start point keeps real geometry and plays normally, and is refused only by the optimizer's splition, described under Optimized output.

Vector blocks (LN)

CAM-generated five-axis programs state the posture as vectors rather than as rotary words. An LN block carries the endpoint plus the surface-normal vector NX/NY/NZ — the 3D tool-compensation direction — and, optionally, the tool vector TX/TY/TZ. HiNC resolves whichever vector governs into the machine's rotary axes and feeds the result through the same RTCP machinery the rotary-word programs use, so there is no second motion path to reason about.

Which vector governs follows the control's own rules:

Situation Tool axis
T present, M128 or FUNCTION TCPM active The T vector — the tool keeps the set orientation.
T absent, RTCP active The surface normal N — the tool is held perpendicular to the contour.
RTCP inactive The T vector is ignored, exactly as the control ignores it. Reported as Orientation-Vector--IgnoredNoTcpm, with the posture left untouched.

RTCP counts as active when the same block turns it on, so a block that both activates RTCP and carries a vector is not skipped.

Two limits are worth knowing before trusting the result:

  • The vector is read in the untilted program frame. An LN block under an active PLANE tilt is reported as Orientation-Vector--TiltedFrameAssumed rather than remapped.
  • Compensation along the surface normal (DR2 / 3D-ToolComp) is recognized, not simulated — SurfaceNormal--CompNotSimulated, raised once per run.

A vector that is not unit length is normalized and reported (Orientation-Vector--NotNormalized); a zero vector is reported as Orientation-Vector--ZeroVector.

Tools

TOOL CALL performs the tool change on its own — klartext has no separate M06 trigger. A tool number or a quoted tool name is accepted.

Parsed:

  • TOOL CALL 1 Z S5000
  • TOOL CALL "1" Z S5000
  • TOOL CALL "B40R" Z S3000 DL+0.5
  • The spindle speed S is recorded modally.
  • DL is a length delta — the effective tool height is the tool-table height plus DL.
  • DR is read and recorded but not applied: radius compensation uses the tool-table radius as-is, and the block reports ToolChange--DeltaUnsupported.
  • A DL/DR that is not a literal value — an unevaluated variable, for example — is ignored and reports ToolChange--DeltaNotLiteral.
  • A tool axis other than Z reports ToolChange--AxisUnsupported.
  • A TOOL CALL whose tool number could not be captured — an unevaluated variable, for example — reports ToolChange--MissingToolId.

Datums

CYCL DEF 247 sets the datum preset and CYCL DEF 7 is an additive shift on top of it, which is the TNC semantic. The two compose as separate entries in the coordinate chain instead of replacing each other.

Parsed:

CYCL DEF 247 Q339=+1

CYCL DEF 7.0 DATUM SHIFT
CYCL DEF 7.1 X10.123
CYCL DEF 7.2 Y22.223
CYCL DEF 7.3 Z32.97

A CYCL DEF 7 axis word may itself carry the I prefix — CYCL DEF 7.2 IY+5 shifts the datum by a further 5 in Y on top of the shift last valid. Unlike the L / C / CC / LN words, this one is not a distance from the tool position at all: it stays inside the cycle's own record and never becomes per-word incremental positioning, so it can never reach the optimizer's incremental guard. Only X / Y / Z are applied; a non-zero rotary word there, IC+90 as much as C+90, is consumed and reported as Datum-Shift--Rotary.

Q parameters and FN

Q, QR, QL and QS parameters are read wherever a value is expected, so FQ1 reaches the feedrate, L X+Q2 reaches the program position and TOOL CALL SQ3 reaches the spindle speed. Q0–Q99 free parameters and QR0–QR499 permanent parameters are held as per-project data and saved with the project.

Construct Support
FN 0–FN 5 Assignment and arithmetic, including the DIV keyword of FN 4 and the prefix SQRT of FN 5.
FN 9–FN 12 Conditional jumps — executed, with a per-label iteration cap so a corrupt or hostile program cannot spin forever.
Other FN opcodes (FN 14, FN 16, FN 18 SYSREAD, …) Recognized, not simulated. The statement is claimed and reported, so its target parameter stays empty instead of taking a fabricated value.

Parsed:

  • Q1 = 5000
  • FN0: Q1 = 5000
  • FN1: Q1 = -Q2 + -5
  • FN2: Q1 = +10 - +5
  • FN3: Q2 = +3 * +3

Tilted planes and RTCP

Construct Support
PLANE SPATIAL Fully composed, including SEQ+ / SEQ-, COORD ROT / TABLE ROT, and the STAY / MOVE / TURN positioning behaviours.
PLANE RESET Cancels the tilt.
PLANE VECTOR Structurally captured, not simulated.
PLANE EULER / POINTS / RELATIV / AXIAL / PROJECTED Recognized, not simulated — consumed and reported as HeidenhainPlane--Unsupported, with the previous tilt retained.
FUNCTION TCPM Supported, read as the default REFPNT TIP-TIP. A center-referenced reference point (REFPNT CNT-CNT / TIP-CENTER) is recognized, not simulated: the coordinates are still taken as tip-to-tip, so CNT-referenced CAM output simulates offset by the ball radius along the tool axis. Reported as Orientation-RefPoint--CntNotSimulated.
M128 / M129 Tool centre point control on / off — real RTCP, the Heidenhain sibling of ISO G43.4 and Siemens TRAORI.

Parsed:

  • PLANE SPATIAL SPA-60.3 SPB+0 SPC-19.88 STAY SEQ- TABLE ROT
  • PLANE RESET STAY

Cycles and calls

  • CYCL DEF 2xx bodies are read with their Q parameters mirrored into the block. Cycles 200, 232, 251, 252 and 253 are mapped onto the shared drilling machinery and simulated; the mapping follows the cycle's own Q values, so a Q202 peck increment routes to peck drilling and a Q211 bottom dwell to dwell drilling.
  • A CYCL DEF body that is not one of those is recognized, not simulated — reported as HeidenhainCycl--Unsupported.
  • CYCL CALL and CYCL CALL POS fire the cycle once; M99 fires once and M89 arms modal firing.
  • A CYCL CALL POS position word takes the I prefix, and its reference is the control's own: the coordinates last programmed by a previous CYCL CALL POS, not the current tool position. With no earlier call for that axis the increment has no reference and the control refuses the block (its error 1A0-0108); the simulation reports HeidenhainCyclCall--IncrementalNoReference and resolves against the last programmed position instead. When the tool moved between the two calls the two candidate references differ — the control's stated one is used, and the divergence is reported as HeidenhainCyclCall--IncrementalAfterMove.
  • CALL LBL n inlines the label body up to LBL 0; CALL LBL n REP m repeats that section m times.
  • CALL PGM resolves the called program by file name.
  • Mirror image in both spellings — the klartext CYCL DEF 8 form and the DIN/ISO G28 form.

DIN/ISO dialect

The same preset, with nothing to switch.

  • % tape header and N block numbers.
  • T plus M06 tool change.
  • Arc centres I / J / K are absolute pole coordinates, not incremental offsets from the start point. This is the Heidenhain reading, and the pole carries forward modally.
  • The ISO label family — G98 L<n> definitions, and the head-anchored L<n>,<m> call whose comma count maps onto the repeat count.
  • G247 Q339 stamps the same datum preset as CYCL DEF 247.
  • G54 with axis words is read as a datum-shift declaration.
  • G70 / G71 units.
Warning

G28 on Heidenhain is MIRROR IMAGE, not a reference-point return. The Fanuc reading of G28 is deliberately absent from the Heidenhain preset. Select the Heidenhain controller for a Heidenhain DIN/ISO file — read as Fanuc, every mirror statement becomes a home move.

Optimized output

An optimized program is patched into the source text block by block rather than re-emitted, so it comes back in the dialect it was written in, and two rules keep the result a program a TNC will accept.

A feed the optimizer writes into a block that carried none lands after the coordinate words and after DR+ / DR- and RL / RR / R0, so the element order the control expects — coordinates, rotation direction, radius compensation, F, M — holds on the patched block: L X+10 Y+20 RL comes back as L X+10 Y+20 RL F500. A block that already states an F keeps that word where it stands, and only its number changes — unless the feed is FMAX, FAUTO or a Q parameter, which patch mode refuses to rewrite: the block is left exactly as written, reporting Writeback-Patch--KeywordValue or Writeback-Patch--VariableValue.

The optimizer's embedded source note is written in the klartext comment grammar — a ; comment, never a parenthesized one, because a TNC reads parentheses as code:

120 L X+35 Y-11.7 R0 F500 ;src(LineNo: 140, StepIndex: 256)

Re-interpolation itself is not refused for being klartext. A C … DR± arc splits like any other when the modal CC chain supplies both in-plane centre coordinates and the C block states its own words absolutely: no centre words are rebuilt, and each fragment carries the block's own words with its own endpoint and feed, around the one CC line they all share unchanged. An incremental CC does not disqualify the arc it feeds — the per-word mark sits on the CC block alone and never carries forward, and the centre reaches the arc already resolved.

Two shapes are optimized as whole lines instead. Each reports its own id, once per run.

  • The arc whose modal chain left an in-plane coordinate unstated — no CC ever gave it, so the arc's own start point supplies it, and every fragment would re-derive that centre from its own start: NcOpt--SplitionStartPointCenterUnsupported.
  • The piece that carries an incremental word of its own — a klartext I-prefixed word, as in the legal and fully simulated C IX+20 IY+0 DR-, or a G91 block in the DIN/ISO dialect. The fragment rewrite emits absolute coordinates, so every fragment would re-apply the distance from its own start: NcOpt--SplitionIncrementalUnsupported. The test reads the piece's own block only — the state of the modal CC chain neither triggers this one nor exempts a piece from it.

Not supported

TOOL DEF, FK free-contour programming, SL cycles, PATTERN DEF, and TCH PROBE. These are left unconsumed, and the block that carried them reports Parsing--Unconsumed naming the words.

Machine-specific M-codes that are not part of the Heidenhain vocabulary above are declared on the machine rather than built in — see the M-code note on General NC Code Support.

See Also

  • General NC Code Support — Fanuc, Syntec, Mazak and Siemens SINUMERIK.
  • NC Parsing Engine — the pipeline behind these constructs, the brand-by-brand support matrix in one table, and how a machine's own vocabulary is added without changing HiNC.