This repository has been archived on 2026-10-11. You can view files and clone it. You cannot open issues or pull requests or push a commit.
Files
HiNC-2025-win-desktop-Deploy/App/wwwroot/HiAPI-docsite/api/Hi.NcParsers.ParsingSyntaxs.Heidenhain.html
T
2026-09-09 17:35:23 +08:00

527 lines
32 KiB
HTML
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>Namespace Hi.NcParsers.ParsingSyntaxs.Heidenhain | HiAPI-C# 2025 </title>
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="title" content="Namespace Hi.NcParsers.ParsingSyntaxs.Heidenhain | HiAPI-C# 2025 ">
<link rel="icon" href="../img/HiAPI.favicon.ico">
<link rel="stylesheet" href="../public/docfx.min.css">
<link rel="stylesheet" href="../public/main.css">
<meta name="docfx:navrel" content="../toc.html">
<meta name="docfx:tocrel" content="toc.html">
<meta name="docfx:rel" content="../">
<meta name="loc:inThisArticle" content="In this article">
<meta name="loc:searchResultsCount" content="{count} results for &quot;{query}&quot;">
<meta name="loc:searchNoResults" content="No results for &quot;{query}&quot;">
<meta name="loc:tocFilter" content="Filter by title">
<meta name="loc:nextArticle" content="Next">
<meta name="loc:prevArticle" content="Previous">
<meta name="loc:themeLight" content="Light">
<meta name="loc:themeDark" content="Dark">
<meta name="loc:themeAuto" content="Auto">
<meta name="loc:changeTheme" content="Change theme">
<meta name="loc:copy" content="Copy">
<meta name="loc:downloadPdf" content="Download PDF">
<script type="module" src="./../public/docfx.min.js"></script>
<script>
const theme = localStorage.getItem('theme') || 'auto'
document.documentElement.setAttribute('data-bs-theme', theme === 'auto' ? (window.matchMedia('(prefers-color-scheme: dark)').matches ? 'dark' : 'light') : theme)
</script>
</head>
<body class="tex2jax_ignore" data-layout="" data-yaml-mime="ManagedReference">
<header class="bg-body border-bottom">
<nav id="autocollapse" class="navbar navbar-expand-md" role="navigation">
<div class="container-xxl flex-nowrap">
<a class="navbar-brand" href="../index.html">
<img id="logo" class="svg" src="../img/HiAPI.logo.png" alt="">
</a>
<button class="btn btn-lg d-md-none border-0" type="button" data-bs-toggle="collapse" data-bs-target="#navpanel" aria-controls="navpanel" aria-expanded="false" aria-label="Toggle navigation">
<i class="bi bi-three-dots"></i>
</button>
<div class="collapse navbar-collapse" id="navpanel">
<div id="navbar">
<form class="search" role="search" id="search">
<i class="bi bi-search"></i>
<input class="form-control" id="search-query" type="search" disabled placeholder="Search" autocomplete="off" aria-label="Search">
</form>
</div>
</div>
</div>
</nav>
</header>
<main class="container-xxl">
<div class="toc-offcanvas">
<div class="offcanvas-md offcanvas-start" tabindex="-1" id="tocOffcanvas" aria-labelledby="tocOffcanvasLabel">
<div class="offcanvas-header">
<h5 class="offcanvas-title" id="tocOffcanvasLabel">Table of Contents</h5>
<button type="button" class="btn-close" data-bs-dismiss="offcanvas" data-bs-target="#tocOffcanvas" aria-label="Close"></button>
</div>
<div class="offcanvas-body">
<nav class="toc" id="toc"></nav>
</div>
</div>
</div>
<div class="content">
<div class="actionbar">
<button class="btn btn-lg border-0 d-md-none" type="button" data-bs-toggle="offcanvas" data-bs-target="#tocOffcanvas" aria-controls="tocOffcanvas" aria-expanded="false" aria-label="Show table of contents">
<i class="bi bi-list"></i>
</button>
<nav id="breadcrumb"></nav>
</div>
<article data-uid="Hi.NcParsers.ParsingSyntaxs.Heidenhain">
<h1 id="Hi_NcParsers_ParsingSyntaxs_Heidenhain" data-uid="Hi.NcParsers.ParsingSyntaxs.Heidenhain" class="text-break">Namespace Hi.NcParsers.ParsingSyntaxs.Heidenhain</h1>
<div class="markdown level0 summary"></div>
<div class="markdown level0 conceptual"></div>
<div class="markdown level0 remarks"></div>
<h3 id="classes">
Classes
</h3>
<dl class="jumplist">
<dt><a class="xref" href="Hi.NcParsers.ParsingSyntaxs.Heidenhain.HeidenhainBlkFormSyntax.html">HeidenhainBlkFormSyntax</a></dt>
<dd><p>Syntax for Heidenhain BLK FORM command (workpiece blank definition).</p>
</dd>
</dl>
<dl class="jumplist">
<dt><a class="xref" href="Hi.NcParsers.ParsingSyntaxs.Heidenhain.HeidenhainCSyntax.html">HeidenhainCSyntax</a></dt>
<dd><p>Heidenhain circular-motion statement (<code>C X+5.361 Y+23.064 DR-</code>).
Mirrors <a class="xref" href="Hi.NcParsers.ParsingSyntaxs.Heidenhain.HeidenhainLSyntax.html">HeidenhainLSyntax</a>: endpoint axis words promote
to the Parsing root (shared Logic consumers), a <code>&ldquo;CArc&rdquo;: true</code>
statement marker (deliberately NOT the bare <code>C</code> key — that is a
rotary axis word which <a class="xref" href="Hi.NcParsers.LogicSyntaxs.McAbcSyntax.html">McAbcSyntax</a> owns and
consumes on rotary machines) gates
<a class="xref" href="Hi.NcParsers.LogicSyntaxs.Heidenhain.HeidenhainCircularMotionSyntax.html">HeidenhainCircularMotionSyntax</a>,
the rotation direction lands in <code>Parsing.DR</code> (<code>&quot;-&quot;</code> = CW =
G02, <code>&quot;+&quot;</code> = CCW = G03) and radius-compensation words are
captured like on L statements. The word-boundary head guard rejects
<code>CC</code>/<code>CT</code>/<code>CR</code>/<code>CP</code> statements, and a value
follower rejects a leading rotary-axis word — a DIN/ISO block like
<code>C-90.</code> (modal C-axis positioning, the same mixed-dialect list)
is an axis coordinate for the root tag capture, never a klartext arc
statement head (klartext always separates the C head from its X/Y/DR
words, so a sign/digit/dot follower cannot be an arc statement).
Incremental endpoint words (<code>C IX+20 IY+0 DR-</code>) are captured
like on L statements — plain axis keys plus the block-root
<code>PositioningOverride</code> stamp, see
<a class="xref" href="Hi.NcParsers.ParsingSyntaxs.Heidenhain.HeidenhainIncrementalAxisWordUtil.html">HeidenhainIncrementalAxisWordUtil</a>.</p>
</dd>
</dl>
<dl class="jumplist">
<dt><a class="xref" href="Hi.NcParsers.ParsingSyntaxs.Heidenhain.HeidenhainCallSyntax.html">HeidenhainCallSyntax</a></dt>
<dd><p>Syntax for Heidenhain CALL commands (CALL PGM and CALL LBL).</p>
</dd>
</dl>
<dl class="jumplist">
<dt><a class="xref" href="Hi.NcParsers.ParsingSyntaxs.Heidenhain.HeidenhainCcSyntax.html">HeidenhainCcSyntax</a></dt>
<dd><p>Heidenhain circle-center statement (<code>CC X+12.7 Y+12.7</code>). The
coordinates land in the nested <code>Parsing.CC</code> record — deliberately
<b>not</b> on the Parsing root, where <a class="xref" href="Hi.NcParsers.LogicSyntaxs.ProgramXyzSyntax.html">ProgramXyzSyntax</a>
would mistake the center for a motion endpoint. The Logic-stage
<a class="xref" href="Hi.NcParsers.LogicSyntaxs.Heidenhain.HeidenhainCircleCenterSyntax.html">HeidenhainCircleCenterSyntax</a>
turns the record into the modal circle-center section consumed by the
arc syntax. Must run before <a class="xref" href="Hi.NcParsers.ParsingSyntaxs.Heidenhain.HeidenhainCSyntax.html">HeidenhainCSyntax</a> in the
bundle (the <code>\b</code> guard keeps a <code>C</code> statement from matching
<code>CC</code> and vice versa, but CC-first is the safe order).</p>
<p>
An incremental center (<code>CC IX+0 IY+11</code>) is a distance from the
last programmed <b>tool</b> position, not from the previous center:
the words land in the same nested record with the block-root
<code>PositioningOverride</code> stamp (see
<a class="xref" href="Hi.NcParsers.ParsingSyntaxs.Heidenhain.HeidenhainIncrementalAxisWordUtil.html">HeidenhainIncrementalAxisWordUtil</a>), and the Heidenhain
<a class="xref" href="Hi.NcParsers.LogicSyntaxs.IncrementalResolveSyntax.html">IncrementalResolveSyntax</a> instance walks
the <code>CC</code> record so the center is absolute by the time the
circle-center syntax freezes it.
</p>
</dd>
</dl>
<dl class="jumplist">
<dt><a class="xref" href="Hi.NcParsers.ParsingSyntaxs.Heidenhain.HeidenhainCyclCallSyntax.html">HeidenhainCyclCallSyntax</a></dt>
<dd><p>Captures the klartext cycle-call statement into a
<code>Parsing[&ldquo;CYCL CALL&rdquo;]</code> record:</p>
<ul><li><code>CYCL CALL</code> — <code>{ Bare: true }</code>; any trailing M words
stay in the text for the shared flag captures.</li><li><code>CYCL CALL POS X±n Y±n Z±n …</code> — <code>{ Pos: true }</code> plus
the axis words grabbed <b>into the record</b> (never onto the
<code>Parsing</code> root: the POS coordinates are the call position — the
X/Y feed the ISO cycle section, while the pre-position Z must not be
mistaken for the hole-bottom Z slot). <code>FMAX</code>/<code>F</code>/<code>M140</code>
words stay in the text for their own captures. A klartext
I-prefixed word (<code>CYCL CALL POS IX+20</code> — the general "I before
an axis word" rule; the manual prints no example) lands under the
plain key like an <code>L</code> endpoint and stamps the block-root
<a class="xref" href="Hi.NcParsers.Keywords.PositioningOverride.html">PositioningOverride</a> through
<a class="xref" href="Hi.NcParsers.ParsingSyntaxs.Heidenhain.HeidenhainIncrementalAxisWordUtil.html">HeidenhainIncrementalAxisWordUtil</a>; the cycle syntax
resolves it on the spot, ahead of the shared resolve.</li></ul>
The call is consumed by
<a class="xref" href="Hi.NcParsers.LogicSyntaxs.Heidenhain.HeidenhainCannedCycleSyntax.html">HeidenhainCannedCycleSyntax</a>,
which converts the stored cycle definition into a direct ISO cycle
sub-section on this block.
</dd>
</dl>
<dl class="jumplist">
<dt><a class="xref" href="Hi.NcParsers.ParsingSyntaxs.Heidenhain.HeidenhainCyclDefSyntax.html">HeidenhainCyclDefSyntax</a></dt>
<dd><p>Initialization Syntax of Heidenhain fixed head block for <pre><code class="lang-csharp">CYCL DEF</code></pre>.
</dd>
</dl>
<dl class="jumplist">
<dt><a class="xref" href="Hi.NcParsers.ParsingSyntaxs.Heidenhain.HeidenhainFnAssignmentSyntax.html">HeidenhainFnAssignmentSyntax</a></dt>
<dd><p>Heidenhain FN variable assignment syntax.
Extends <a class="xref" href="Hi.NcParsers.ParsingSyntaxs.TagAssignmentSyntax.html">TagAssignmentSyntax</a> with FN opcode prefix.</p>
</dd>
</dl>
<dl class="jumplist">
<dt><a class="xref" href="Hi.NcParsers.ParsingSyntaxs.Heidenhain.HeidenhainFnFeatureSyntax.html">HeidenhainFnFeatureSyntax</a></dt>
<dd><p>Structured skip for the Heidenhain FN opcodes the simulation does not
implement (<code>FN 14</code> error display, <code>FN 16</code> print, <code>FN 18</code>
SYSREAD, table/pallet opcodes …): the whole statement is consumed and a
single <code>HeidenhainFn&ndash;Unsupported</code> warning names the opcode. Two
opcode families pass through untouched: <code>FN 0-5</code> belong to
<a class="xref" href="Hi.NcParsers.ParsingSyntaxs.Heidenhain.HeidenhainFnAssignmentSyntax.html">HeidenhainFnAssignmentSyntax</a> (which runs earlier), and the
jump family <code>FN 9-12</code> belongs to
<a class="xref" href="Hi.NcParsers.ParsingSyntaxs.Heidenhain.HeidenhainGotoParsingSyntax.html">HeidenhainGotoParsingSyntax</a> (also earlier) — the
pass-through here is the malformed-jump safety net: a jump line the
owner's grammar rejects surfaces as visible residue instead of a
fabricated skip.</p>
<p>
Claiming the statement here is load-bearing, not cosmetic: an FN 18 line
like <code>FN18: SYSREAD Q94= ID50 NR11</code> contains a <code>Q94=</code> token
that the bare Q-assignment capture (later in the Parsing bundle) would
otherwise grab, storing the garbage string <code>ID50</code> into Q94. The
target parameter must instead stay vacant so dependent expressions fail
soft (<code>VariableExpression--Unevaluated</code>) — no fabricated values.
</p>
</dd>
</dl>
<dl class="jumplist">
<dt><a class="xref" href="Hi.NcParsers.ParsingSyntaxs.Heidenhain.HeidenhainGotoParsingSyntax.html">HeidenhainGotoParsingSyntax</a></dt>
<dd><p>Captures the Heidenhain FN 9–12 conditional jump statement whole into
<code>Parsing.HeidenhainGoto</code>. All four opcodes share one phrase shape
(<code>FN n: IF &lt;value&gt; &lt;comparator&gt; &lt;value&gt; GOTO LBL
&lt;label&gt;</code>); both the spaced standard spelling and the
compressed post spelling (<code>FN12:IF+Q94 LT+1GOTOLBL&quot;SLOW_FEED&quot;</code> —
glued opcode head, glued value/target run, quoted name label) are
recognised.</p>
<p>
Pre-normalisation happens here, per the P2 expression-grammar
decision (the Heidenhain dialect deliberately has no comparison
layer): the comparator spelling collapses to the shared comparison
words (<code>EQU</code>→<code>EQ</code>), and the two operands are captured as
separate values — a pure numeric literal is typed numeric at capture
(the P0 <code>GetParsedDouble</code>-string-trap discipline), a Q reference
stays a string for
<a class="xref" href="Hi.NcParsers.EvaluationSyntaxs.VariableEvaluatorSyntax.html">VariableEvaluatorSyntax</a>'s pass-2
substitution. The comparison and the label redirect happen in
<a class="xref" href="Hi.NcParsers.EvaluationSyntaxs.Heidenhain.HeidenhainGotoSyntax.html">HeidenhainGotoSyntax</a>.
</p>
<p>
Placement: whole-statement owner right after
<a class="xref" href="Hi.NcParsers.ParsingSyntaxs.Heidenhain.HeidenhainCallSyntax.html">HeidenhainCallSyntax</a> — before
<a class="xref" href="Hi.NcParsers.ParsingSyntaxs.Heidenhain.HeidenhainLblSyntax.html">HeidenhainLblSyntax</a> (whose definition regex already
excludes the <code>GOTO LBL</code> spellings, but the jump owner claiming
the full line first keeps the exclusion a backstop rather than a
load-bearing gate) and before <a class="xref" href="Hi.NcParsers.ParsingSyntaxs.Heidenhain.HeidenhainFnFeatureSyntax.html">HeidenhainFnFeatureSyntax</a>
(whose FN 9–12 pass-through remains the malformed-jump safety net: a
line this regex rejects surfaces as visible residue, never a
fabricated skip).
</p>
</dd>
</dl>
<dl class="jumplist">
<dt><a class="xref" href="Hi.NcParsers.ParsingSyntaxs.Heidenhain.HeidenhainIncrementalAxisWordUtil.html">HeidenhainIncrementalAxisWordUtil</a></dt>
<dd><p>The klartext <b>I-prefixed incremental axis word</b> — <code>IX+20</code>,
<code>IY-15</code>, <code>IZ+Q1</code>, rotary <code>IC+90</code>: the same axis word
as the absolute <code>X+20</code>, read as a distance from the last
programmed position instead of a coordinate. Any word of a block may
be incremental on its own (<code>L X+60 IY-10</code> mixes both), which is
exactly the per-word shape the shared
<a class="xref" href="Hi.NcParsers.Keywords.PositioningOverride.html">PositioningOverride</a> section models for the
Siemens <code>IC()</code> wrapper. So the grab here writes the value under
the <b>plain</b> axis key of the caller's section (<code>Parsing.X</code>
for an <code>L</code>/<code>C</code> endpoint, <code>Parsing.CC.X</code> for a circle
center, <code>Parsing[&ldquo;CYCL CALL&rdquo;].X</code> for a cycle-call position) and
stamps <code>&ldquo;PositioningOverride&rdquo;: { &ldquo;X&rdquo;: &ldquo;Incremental&rdquo; }</code> on the
block root; the conversion to absolute stays with the existing
consumers — <a class="xref" href="Hi.NcParsers.LogicSyntaxs.IncrementalResolveSyntax.html">IncrementalResolveSyntax</a> for
linear axes (the Heidenhain instance also walks the <code>CC</code> record),
<a class="xref" href="Hi.NcParsers.LogicSyntaxs.McAbcSyntax.html">McAbcSyntax</a> for rotary axes, and
<a class="xref" href="Hi.NcParsers.LogicSyntaxs.Heidenhain.HeidenhainCannedCycleSyntax.html">HeidenhainCannedCycleSyntax</a> on
the spot for the words it consumes ahead of the resolve — and no
second incremental mechanism exists. The one klartext <code>I</code> word
that is NOT a distance from the tool position, the <code>CYCL DEF 7</code>
datum shift, deliberately does not use this helper (see
<a class="xref" href="Hi.NcParsers.ParsingSyntaxs.Heidenhain.CyclDefSyntaxs.HeidenhainDatumShiftSyntax.html">HeidenhainDatumShiftSyntax</a>).</p>
<p>
The plain axis grab (<code>NcSyntaxUtil.GrabTagValue</code>) cannot see the
<code>X</code> inside <code>IX</code>: <a class="xref" href="Hi.NcParsers.SoftNcUtil.html#Hi_NcParsers_SoftNcUtil_RegexFlagPrefix">RegexFlagPrefix</a>
demands a word boundary, a digit or whitespace before the tag, and
<code>I</code> is a word character. That guard is what keeps the plain grab
from half-reading an incremental block (<code>L X+60 IY-10</code> used to
take X and drop the Y — a motion to the wrong place, not a missing
one), so the incremental words are grabbed by their own two-letter
tags (<code>IX</code>, <code>IY</code>, …) instead of relaxing the guard.
The value grammar is the shared one (signed number, <code>Q</code>
variable, bracket expression), and a glued run (<code>LIX+20IY-15</code>)
parses like the absolute glued shape because the digit alternative of
the prefix guard admits the second word.
</p>
</dd>
</dl>
<dl class="jumplist">
<dt><a class="xref" href="Hi.NcParsers.ParsingSyntaxs.Heidenhain.HeidenhainLSyntax.html">HeidenhainLSyntax</a></dt>
<dd><p>Heidenhain linear movement (the leading L) syntax. Strips the leading
<code>L</code> — spaced (<code>L X+10</code>) or glued directly to an axis/F word
(<code>LX+153.933Y+4.196A-77.516</code>, the dominant shape of post-processed
turbine files) — writes the <code>Parsing.L = true</code> statement marker,
and grabs axis-tag values for any of <a class="xref" href="Hi.NcParsers.Syntaxs.NcSyntaxUtil.html#Hi_NcParsers_Syntaxs_NcSyntaxUtil_AxisTagList">AxisTagList</a>
(X, Y, Z, U, V, W, A, B, C) that appear afterwards as
<code>{axis}{signed-value}</code> pairs; values are parsed as floats via
<a class="xref" href="Hi.NcParsers.ParsingSyntaxs.FloatTagValueSyntax.html#Hi_NcParsers_ParsingSyntaxs_FloatTagValueSyntax_ToFloat_System_String_">ToFloat(string)</a>. <code>LN</code>/<code>LP</code>/<code>LBL</code>
lines are excluded by the gate's lookahead: a glued axis letter only
counts when followed by a sign, digit, dot or Q variable, so the B of
<code>LBL</code> (followed by another L) never matches. Glued M words
(<code>LM09</code>) are accepted — stripping the L exposes the M word for
the numbered-flag syntax; the richer <code>LM140</code>/<code>LM128</code>
statements never reach this gate because their dedicated owners run
earlier in the Heidenhain Parsing bundle.</p>
<p>
Axis words land on the <b>root</b> of <a class="xref" href="Hi.NcParsers.Keywords.IParsingDef.html#Hi_NcParsers_Keywords_IParsingDef_Parsing">Parsing</a>
(not nested under <code>L</code>) so the shared Logic consumers —
<a class="xref" href="Hi.NcParsers.LogicSyntaxs.ProgramXyzSyntax.html">ProgramXyzSyntax</a>,
<a class="xref" href="Hi.NcParsers.LogicSyntaxs.McAbcSyntax.html">McAbcSyntax</a>,
<a class="xref" href="Hi.NcParsers.LogicSyntaxs.MachineCoordSelectSyntax.html">MachineCoordSelectSyntax</a>,
<a class="xref" href="Hi.NcParsers.LogicSyntaxs.IncrementalResolveSyntax.html">IncrementalResolveSyntax</a> — read them without
per-brand path configuration. The <code>L</code> marker is consumed by
<a class="xref" href="Hi.NcParsers.LogicSyntaxs.Heidenhain.HeidenhainMotionModeSyntax.html">HeidenhainMotionModeSyntax</a> which
maps the statement (plus a one-shot <code>FMAX</code> flag) onto the shared
G00/G01 motion-mode vocabulary.
</p>
<p>
The radius-compensation words <code>RL</code>/<code>RR</code>/<code>R0</code> are
captured as boolean records on the Parsing root; the Logic-stage
<a class="xref" href="Hi.NcParsers.LogicSyntaxs.Heidenhain.HeidenhainRadiusCompSyntax.html">HeidenhainRadiusCompSyntax</a> maps
them onto the shared G41/G42/G40 vocabulary consumed by the radius
compensation pass.
</p>
<p>
Incremental axis words (<code>L IX+20 IY-15</code>, mixed with absolute
ones at will) land under the same plain axis keys, with a per-axis
<code>"PositioningOverride": { "X": "Incremental" }</code> stamp on the
block root for the shared resolve consumers — see
<a class="xref" href="Hi.NcParsers.ParsingSyntaxs.Heidenhain.HeidenhainIncrementalAxisWordUtil.html">HeidenhainIncrementalAxisWordUtil</a>. The glued gate
admits the prefixed spelling too (<code>LIX+20</code>).
</p>
</dd>
</dl>
<dl class="jumplist">
<dt><a class="xref" href="Hi.NcParsers.ParsingSyntaxs.Heidenhain.HeidenhainLblSyntax.html">HeidenhainLblSyntax</a></dt>
<dd><p>Syntax for Heidenhain LBL command (label definition).
Label can be a number (1-65535) or a text name (e.g., &ldquo;MyLabel&rdquo;).
LBL 0 is reserved for end of subprogram.</p>
<p>
Only a DEFINITION is captured: <code>CALL LBL</code> (any spacing) and the
FN 9–12 jump spellings (<code>GOTO LBL n</code>, glued <code>GOTOLBL</code>) are
excluded — this syntax doubles as the label-scan probe of the P4 call
machinery, where mistaking a jump line (or the call line itself) for
a definition splices the wrong program section.
</p>
</dd>
</dl>
<dl class="jumplist">
<dt><a class="xref" href="Hi.NcParsers.ParsingSyntaxs.Heidenhain.HeidenhainLnSyntax.html">HeidenhainLnSyntax</a></dt>
<dd><p>Heidenhain LN (surface-normal block) syntax — the CAM-generated
straight line carrying the endpoint plus up to two normalized
vectors, in the manual's fixed element order
<code>X,Y,Z → NX,NY,NZ → TX,TY,TZ</code>: the surface-normal vector
<code>NX/NY/NZ</code> (the 3D tool-compensation direction) and the
optional tool vector <code>TX/TY/TZ</code> (the tool-axis orientation,
acted on only under M128 / FUNCTION TCPM). Strips the leading
<code>LN</code> — spaced or glued straight onto an axis or vector word —
writes the shared <a class="xref" href="Hi.NcParsers.ParsingSyntaxs.Heidenhain.HeidenhainLSyntax.html#Hi_NcParsers_ParsingSyntaxs_Heidenhain_HeidenhainLSyntax_StatementKey">StatementKey</a>
statement marker (an LN block is a feed-rate linear move, so the
shared motion-mode mapping serves it unchanged), sweeps the six
vector components into the nested <code>Parsing.LN</code> record, and
grabs endpoint axis words and <code>RL</code>/<code>RR</code>/<code>R0</code> onto
the Parsing root exactly like <a class="xref" href="Hi.NcParsers.ParsingSyntaxs.Heidenhain.HeidenhainLSyntax.html">HeidenhainLSyntax</a>.
The <code>Parsing.LN</code> record — created even when the block carries
no vector words, so the LN identity always reaches the Logic stage
— is consumed by
<a class="xref" href="Hi.NcParsers.LogicSyntaxs.Heidenhain.HeidenhainLnOrientationSyntax.html">HeidenhainLnOrientationSyntax</a>,
which applies the manual's posture rules and writes the
brand-agnostic <code>ToolOrientation</code>/<code>SurfaceNormal</code> sections.</p>
<p>
Vector words are grabbed before the root axis words as ordering
hygiene; correctness does not depend on it —
<a class="xref" href="Hi.NcParsers.SoftNcUtil.html#Hi_NcParsers_SoftNcUtil_RegexFlagPrefix">RegexFlagPrefix</a> rejects a tag preceded by
a letter, so a bare <code>X</code> can never claim the X of <code>NX</code>.
Runs ahead of <a class="xref" href="Hi.NcParsers.ParsingSyntaxs.Heidenhain.HeidenhainLSyntax.html">HeidenhainLSyntax</a> in the bundle; the L
gate's lookahead already excludes <code>LN</code>, so this is ordering
hygiene as well, not a claim race.
</p>
<p>
Incremental endpoint words (<code>LN IX+20 IY-15 …</code>, mixed with
absolute ones at will) land under the same plain axis keys with the
per-axis <code>"PositioningOverride": { "Y": "Incremental" }</code> stamp
on the block root, exactly like <a class="xref" href="Hi.NcParsers.ParsingSyntaxs.Heidenhain.HeidenhainLSyntax.html">HeidenhainLSyntax</a> —
see <a class="xref" href="Hi.NcParsers.ParsingSyntaxs.Heidenhain.HeidenhainIncrementalAxisWordUtil.html">HeidenhainIncrementalAxisWordUtil</a>. The manual
states the <code>I</code> prefix as a general rule for programmed
positions and gives the LN endpoint no exception (its syntax table
says only "coordinates of the straight-line end point"), so the
endpoint follows that rule; the vector words have no incremental
form. The glued gate admits the prefixed spelling too
(<code>LNIX+20</code>).
</p>
</dd>
</dl>
<dl class="jumplist">
<dt><a class="xref" href="Hi.NcParsers.ParsingSyntaxs.Heidenhain.HeidenhainM128Syntax.html">HeidenhainM128Syntax</a></dt>
<dd><p>Captures the klartext <code>M128</code> word (RTCP on) together with its
optional feed-limit argument (<code>M128 F6000.</code>) into
<code>Parsing.M128 { F? }</code>. Must run <b>before</b> the shared F
tag-value syntax — the F belongs to M128 (feed limit for compensating
movements), and letting it reach the Parsing root would pollute the
modal feedrate (HardNc has exactly this defect). Accepted spellings:
the leading/glued L statement (<code>LM128</code>, mirroring the M140
sibling), the fully glued <code>M128F6000</code>, and a Q-parameter feed
limit (<code>M128 FQ8</code>, 1.H corpus) captured as the string token for
the evaluator pass to resolve. <code>M129</code> (RTCP off) carries no
argument and stays on the shared numbered-flag path.</p>
</dd>
</dl>
<dl class="jumplist">
<dt><a class="xref" href="Hi.NcParsers.ParsingSyntaxs.Heidenhain.HeidenhainM140Syntax.html">HeidenhainM140Syntax</a></dt>
<dd><p>Captures the klartext <code>M140 MB</code> tool-axis retract statement into
<code>Parsing.M140 { MB, F? }</code>. <code>MB MAX</code> retracts to the traverse
limit (recorded as the string <code>&ldquo;MAX&rdquo;</code>); <code>MB+n</code> retracts by
<code>n</code> mm along the tool axis. Handles the corpus forms
<code>M140 MB+50 F6000</code>, <code>L M140 MB MAX</code> (M word carried on an L
statement) and the glued <code>LM140 MB MAX</code> (TongTai post). Must run
<b>before</b> <a class="xref" href="Hi.NcParsers.ParsingSyntaxs.Heidenhain.HeidenhainLSyntax.html">HeidenhainLSyntax</a> (it claims the whole
retract statement including a leading <code>L</code>) and before the shared
F tag-value syntax (the F is the retract feed).</p>
</dd>
</dl>
<dl class="jumplist">
<dt><a class="xref" href="Hi.NcParsers.ParsingSyntaxs.Heidenhain.HeidenhainMirrorImageSyntax.html">HeidenhainMirrorImageSyntax</a></dt>
<dd><p>Heidenhain DIN/ISO <code>G28</code> = MIRROR IMAGE (the CYCL DEF 8 twin;
basic course 62192: <code>G28 X</code> flips the X sign about the current
datum, <code>G28 X Y</code> flips both, bare <code>G28</code> resets) — the exact
opposite of the Fanuc reference-point return the shared
<a class="xref" href="Hi.NcParsers.Syntaxs.GenericSyntaxKit.html#Hi_NcParsers_Syntaxs_GenericSyntaxKit_G28Syntax">G28Syntax</a> would read it as. Claims the
whole statement (code plus trailing axis words) ahead of the generic
kit and records each statement under
<code>Parsing.</code><a class="xref" href="Hi.NcParsers.ParsingSyntaxs.Heidenhain.HeidenhainMirrorImageSyntax.html#Hi_NcParsers_ParsingSyntaxs_Heidenhain_HeidenhainMirrorImageSyntax_MirrorImageKey">MirrorImageKey</a> for the Logic-stage
<a class="xref" href="Hi.NcParsers.LogicSyntaxs.Heidenhain.HeidenhainMirrorTransformSyntax.html">HeidenhainMirrorTransformSyntax</a>,
which simulates the mirror as a
<a class="xref" href="Hi.NcParsers.Keywords.ITransformationDef.html#Hi_NcParsers_Keywords_ITransformationDef_ProgramToMcTransform">ProgramToMcTransform</a> entry.</p>
<p>
Axis words are the manual's bare letters; a glued numeric or
Q-variable follower (<code>G28 X0 Y0</code> — the Fanuc idiom a mislabeled
<code>.I</code> file could carry — or <code>G28 XQ1</code>) is claimed too so the
value can never fall through to the root tag captures as a ghost
coordinate, and the statement is stamped <a class="xref" href="Hi.NcParsers.ParsingSyntaxs.Heidenhain.HeidenhainMirrorImageSyntax.html#Hi_NcParsers_ParsingSyntaxs_Heidenhain_HeidenhainMirrorImageSyntax_ValuedKey">ValuedKey</a> so
the Logic stage keeps it recognized-but-not-simulated (mirroring on
the Fanuc-shaped form would wreck a mislabeled reference-return
file). A bare axis letter glued to another word (<code>G28 CC…</code>)
stops the claim run — the leftover surfaces through the residue
sentinels instead of being guessed at.
</p>
</dd>
</dl>
<dl class="jumplist">
<dt><a class="xref" href="Hi.NcParsers.ParsingSyntaxs.Heidenhain.HeidenhainPlaneSyntax.html">HeidenhainPlaneSyntax</a></dt>
<dd><p>Syntax for the Heidenhain PLANE statement family. Fully structured
(simulated by the Logic-stage tilt consumer):</p>
<ul><li><code>PLANE RESET [STAY|MOVE|TURN]</code></li><li><code>PLANE SPATIAL SPA SPB SPC [SEQ±] [COORD ROT|TABLE ROT]
[MOVE [DIST..] [F..]|TURN|STAY]</code></li></ul>
Recognized (captured with the same option set, simulated as
recognized-but-not-simulated by the Logic consumer):
<ul><li><code>PLANE PROJECTED PROPR PROMIN ROT ...</code></li><li><code>PLANE VECTOR BX BY BZ NX NY NZ ...</code> (corpus: 1.H)</li><li><code>PLANE EULER/POINTS/RELATIV/AXIAL ...</code> — the mode word is
captured and the unmodeled argument text is swept verbatim into the
record's <code>Args</code> so no token can leak to the shared tag captures
(e.g. a <code>PLANE AXIAL B+45</code> B word must never become a rotary
axis move).</li></ul>
Must run <b>before</b> the shared F tag-value syntax: the F of
<code>MOVE DIST100 F8000</code> is the repositioning feed and would
otherwise pollute the modal feedrate (house.H corpus form; HardNc has
exactly this defect).
</dd>
</dl>
<dl class="jumplist">
<dt><a class="xref" href="Hi.NcParsers.ParsingSyntaxs.Heidenhain.HeidenhainProgramSyntax.html">HeidenhainProgramSyntax</a></dt>
<dd><p>Syntax for Heidenhain BEGIN PGM and END PGM commands.</p>
</dd>
</dl>
<dl class="jumplist">
<dt><a class="xref" href="Hi.NcParsers.ParsingSyntaxs.Heidenhain.HeidenhainTcpmSyntax.html">HeidenhainTcpmSyntax</a></dt>
<dd><p>Captures the modern-TNC RTCP statement pair into <code>Parsing.TCPM</code>:
<code>FUNCTION TCPM [args]</code> (RTCP on — the M128 successor) and
<code>FUNCTION RESET TCPM</code> (RTCP off). The behavior-tuning argument
words (<code>F TCP / F CONT / AXIS POS / AXIS SPAT / PATHCTRL AXIS /
PATHCTRL VECTOR</code>) are corpus-zero and swept verbatim into the
record's <code>Args</code> — recognized-but-not-simulated (the Logic RTCP
consumer warns); activation/deactivation itself is simulated. Must
run before the shared F tag-value syntax so an argument like
<code>F TCP</code> can never be misread as a feed word.</p>
</dd>
</dl>
<dl class="jumplist">
<dt><a class="xref" href="Hi.NcParsers.ParsingSyntaxs.Heidenhain.HeidenhainTildeTrimSyntax.html">HeidenhainTildeTrimSyntax</a></dt>
<dd><p>Strips the TNC <code>~</code> line-continuation markers from a grouped
sentence's <code>UnparsedText</code>. The raw <a class="xref" href="Hi.NcParsers.Sentence.html#Hi_NcParsers_Sentence_BlockText">BlockText</a>
keeps them (write-back authority); parsing only needs the joined lines.
Both corpus spellings are removed — <code>&quot;… ;STRATEGIE ~&quot;</code> (space
before, line tail) and <code>&quot;DATUM SETTING~&quot;</code> (glued). Placed at the
head of the Parsing bundle, before the comment strippers, so a trailing
<code>~</code> after a <code>;</code> comment never lands in the recorded comment
text.</p>
</dd>
</dl>
<dl class="jumplist">
<dt><a class="xref" href="Hi.NcParsers.ParsingSyntaxs.Heidenhain.HeidenhainToolCallSyntax.html">HeidenhainToolCallSyntax</a></dt>
<dd><p>Syntax for Heidenhain TOOL CALL command.
Handles: TOOL CALL [ToolId|&ldquo;ToolName&rdquo;] [X|Y|Z] [S&hellip;] [DL&hellip;] [DR&hellip;]</p>
</dd>
</dl>
</article>
<div class="contribution d-print-none">
</div>
</div>
<div class="affix">
<nav id="affix"></nav>
</div>
</main>
<div class="container-xxl search-results" id="search-results"></div>
<footer class="border-top text-secondary">
<div class="container-xxl">
<div class="flex-fill">
<span> Copyright © 2025 <a href='https://superhightech.com.tw'>Tech Coordinate</a>. All rights reserved. <a href='https://superhightech.com.tw'>超級高科技股份有限公司</a> © 2025 版權所有 </span>
</div>
</div>
</footer>
</body>
</html>