deploy.

App/wwwroot/HiAPI-docsite/technique/nc-dialects/controller-heidenhain.html

@@ -125,11 +125,11 @@ statement it is.</p>
 <tbody>
 <tr>
 <td><code>L</code></td>
-<td>Straight-line motion with its axis words.</td>
+<td>Straight-line motion with its axis words, absolute or <code>I</code>-prefixed incremental. See <a href="#incremental-axis-words-i-prefix">Incremental axis words</a>.</td>
 </tr>
 <tr>
 <td><code>LN</code></td>
-<td>Surface-normal block — a straight line carrying the endpoint plus up to two normalized vectors, in the fixed element order <code>X,Y,Z</code> → <code>NX,NY,NZ</code> → <code>TX,TY,TZ</code>. See <a href="#vector-blocks-ln">Vector blocks</a>.</td>
+<td>Surface-normal block — a straight line carrying the endpoint plus up to two normalized vectors, in the fixed element order <code>X,Y,Z</code> → <code>NX,NY,NZ</code> → <code>TX,TY,TZ</code>. The endpoint words take the <code>I</code> prefix; the vector words have no incremental form. See <a href="#vector-blocks-ln">Vector blocks</a>.</td>
 </tr>
 <tr>
 <td><code>FMAX</code></td>
@@ -137,7 +137,7 @@ statement it is.</p>
 </tr>
 <tr>
 <td><code>CC</code> / <code>C</code></td>
-<td>Circular motion — <code>CC</code> sets the pole, <code>C</code> states the end point. <code>DR-</code> is clockwise and <code>DR+</code> counter-clockwise, the centre always comes from the modal <code>CC</code> rather than from the <code>C</code> block, and an arc that closes on its start point is a full circle. See <a href="#arc-centres-cc">Arc centres</a>.</td>
+<td>Circular motion — <code>CC</code> sets the pole, <code>C</code> states the end point. <code>DR-</code> is clockwise and <code>DR+</code> counter-clockwise, the centre always comes from the modal <code>CC</code> rather than from the <code>C</code> block, and an arc that closes on its start point is a full circle. Both heads accept <code>I</code>-prefixed words — an incremental pole on <code>CC</code>, an incremental end point on <code>C</code>. See <a href="#arc-centres-cc">Arc centres</a>.</td>
 </tr>
 <tr>
 <td><code>RL</code> / <code>RR</code> / <code>R0</code></td>
@@ -149,7 +149,7 @@ statement it is.</p>
 </tr>
 <tr>
 <td><code>M126</code> / <code>M127</code></td>
-<td>Shortest-path rotary traverse on / off. With neither stated, shortest path is the default.</td>
+<td>Shortest-path rotary traverse on / off. With neither stated, shortest path is the default. An <code>I</code>-prefixed rotary word is exempt either way — see <a href="#incremental-axis-words-i-prefix">Incremental axis words</a>.</td>
 </tr>
 <tr>
 <td><code>M140 MB+n</code> / <code>M140 MB MAX</code></td>
@@ -169,6 +169,35 @@ statement it is.</p>
 </tr>
 </tbody>
 </table>
+<h3 id="incremental-axis-words-i-prefix">Incremental axis words (<code>I</code> prefix)</h3>
+<p>An axis word may carry the <code>I</code> prefix — <code>IX+20</code>, <code>IY-15</code>, rotary <code>IC+90</code> — and is then a relative
+value rather than a coordinate. Five statement heads read the prefix: <code>L</code>, <code>C</code>, <code>CC</code>, <code>LN</code> and
+<code>CYCL CALL POS</code>. On the first four it is a distance from the last programmed position; <code>CYCL CALL POS</code> spells it the same way but measures from the coordinates of the previous <code>CYCL CALL POS</code>, and
+is described under <a href="#cycles-and-calls">Cycles and calls</a>. <code>L</code>, <code>C</code> and <code>LN</code> take the full axis set,
+rotary letters included; <code>CC</code> and <code>CYCL CALL POS</code> take <code>X</code> / <code>Y</code> / <code>Z</code> only, because neither
+positions a rotary axis.</p>
+<p>The prefix is per word, not a mode — klartext has no modal <code>G90</code> / <code>G91</code> counterpart, and only the
+<code>I</code>-marked words of a block are read as distances. Absolute and incremental words therefore mix
+freely inside one block.</p>
+<blockquote>
+<p>Parsed:</p>
+<ul>
+<li><code>L IX+20 IY-15</code> — both axes relative</li>
+<li><code>L X+60 IY-10</code> — to X 60, and by −10 in Y</li>
+<li><code>LIX+20IY-15</code> — glued, exactly as the separator-free absolute form parses</li>
+<li><code>L IX5</code> — the sign is optional</li>
+<li><code>L IZ+Q2</code> and <code>L IY-Q2</code> — the value grammar behind the prefix is the shared one, so a <code>Q</code>
+parameter or a bracket expression reaches it like any other value</li>
+</ul>
+</blockquote>
+<p>A rotary <code>I</code> word is a chain dimension — a signed traverse — and keeps the value it accumulates
+instead of being folded into the ±180° shortest-path window: <code>IC+270</code> 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
+<code>M127</code> remains the modal switch.</p>
+<p>One further <code>I</code> spelling on this control is <strong>not</strong> this mechanism at all: the <code>CYCL DEF 7</code>
+datum-shift words shift the active datum rather than positioning an axis, and are described under
+<a href="#datums">Datums</a>.</p>
 <h3 id="arc-centres-cc">Arc centres (<code>CC</code>)</h3>
 <p>A <code>C</code> block never states its own centre. Each in-plane component is resolved from the modal <code>CC</code>
 section: the <code>CC</code> block's own axis word first, then the same axis of the previous <code>CC</code>, and last the
@@ -176,6 +205,13 @@ arc's own start point. A <code>CC</code> stating no coordinates is the one spell
 once — it takes the last programmed position, read at the <code>CC</code> 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:
 <code>CC</code> on the centre, a move out to the arc start, then the <code>C</code> block.</p>
+<p>An incremental centre is not that spelling. <code>CC IX+0 IY+11</code> <strong>states</strong> a centre — a distance from
+the last programmed <strong>tool</strong> position, never from the previous centre — and it is absolute by the
+time the arc consumes it. Nor is a <code>CC</code> whose coordinates cannot be read: it leaves residue and
+reports <code>UnparsedText--Remaining</code>, and because it states no centre every axis falls through the
+modal chain — to the same axis of the previous <code>CC</code> where there is one, and only otherwise to the
+arc's own start point as below. Either way the position of the unreadable <code>CC</code> block is never
+read as the centre.</p>
 <p>A centre that lands on the arc's own start point leaves the block with no radius and so no arc
 geometry: it reports <code>Arc-CircleCenter--OnStartPoint</code> 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
@@ -237,6 +273,8 @@ number or a quoted tool name is accepted.</p>
 <li><code>DL</code> is a length delta — the effective tool height is the tool-table height <strong>plus</strong> <code>DL</code>.</li>
 <li><code>DR</code> is read and recorded but <strong>not applied</strong>: radius compensation uses the tool-table radius as-is,
 and the block reports <code>ToolChange--DeltaUnsupported</code>.</li>
+<li>A <code>DL</code>/<code>DR</code> that is not a literal value — an unevaluated variable, for example — is ignored and
+reports <code>ToolChange--DeltaNotLiteral</code>.</li>
 <li>A tool axis other than <code>Z</code> reports <code>ToolChange--AxisUnsupported</code>.</li>
 <li>A <code>TOOL CALL</code> whose tool number could not be captured — an unevaluated variable, for example —
 reports <code>ToolChange--MissingToolId</code>.</li>
@@ -255,6 +293,12 @@ CYCL DEF 7.2 Y22.223
 CYCL DEF 7.3 Z32.97
 </code></pre>
 </blockquote>
+<p>A <code>CYCL DEF 7</code> axis word may itself carry the <code>I</code> prefix — <code>CYCL DEF 7.2 IY+5</code> shifts the datum by a
+further 5 in Y on top of the shift last valid. Unlike the <code>L</code> / <code>C</code> / <code>CC</code> / <code>LN</code> 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 <code>X</code> / <code>Y</code> /
+<code>Z</code> are applied; a non-zero rotary word there, <code>IC+90</code> as much as <code>C+90</code>, is consumed and reported as
+<code>Datum-Shift--Rotary</code>.</p>
 <h2 id="q-parameters-and-fn">Q parameters and FN</h2>
 <p><code>Q</code>, <code>QR</code>, <code>QL</code> and <code>QS</code> parameters are read wherever a value is expected, so <code>FQ1</code> reaches the
 feedrate, <code>L X+Q2</code> reaches the program position and <code>TOOL CALL SQ3</code> reaches the spindle speed. <code>Q0</code>–<code>Q99</code>
@@ -344,6 +388,13 @@ and a <code>Q211</code> bottom dwell to dwell drilling.</li>
 <code>HeidenhainCycl--Unsupported</code>.</li>
 <li><strong><code>CYCL CALL</code></strong> and <strong><code>CYCL CALL POS</code></strong> fire the cycle once; <code>M99</code> fires once and <code>M89</code> arms modal
 firing.</li>
+<li>A <strong><code>CYCL CALL POS</code></strong> position word takes the <code>I</code> prefix, and its reference is the control's own:
+the coordinates last programmed by a <strong>previous <code>CYCL CALL POS</code></strong>, 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 <code>1A0-0108</code>); the simulation reports <code>HeidenhainCyclCall--IncrementalNoReference</code> 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 <code>HeidenhainCyclCall--IncrementalAfterMove</code>.</li>
 <li><strong><code>CALL LBL n</code></strong> inlines the label body up to <code>LBL 0</code>; <strong><code>CALL LBL n REP m</code></strong> repeats that section
 <code>m</code> times.</li>
 <li><strong><code>CALL PGM</code></strong> resolves the called program by file name.</li>
@@ -384,12 +435,22 @@ never a parenthesized one, because a TNC reads parentheses as code:</p>
 <pre><code>120 L X+35 Y-11.7 R0 F500 ;src(LineNo: 140, StepIndex: 256)
 </code></pre>
 <p>Re-interpolation itself is not refused for being klartext. A <code>C … DR±</code> arc splits like any other
-when the modal <code>CC</code> chain supplies both in-plane centre coordinates: no centre words are rebuilt,
-and each fragment carries the block's own words with its own endpoint and feed, around the one <code>CC</code>
-line they all share unchanged. The arc that is optimized whole instead is the one whose modal chain
-left an in-plane coordinate unstated — no <code>CC</code> ever gave it, so the arc's own start point supplies
-it, and every fragment would re-derive that centre from its own start. Such pieces are optimized as
-whole lines under <code>NcOpt--SplitionStartPointCenterUnsupported</code>, raised once per run.</p>
+when the modal <code>CC</code> chain supplies both in-plane centre coordinates <strong>and</strong> the <code>C</code> 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 <code>CC</code> line they all share unchanged. An incremental
+<code>CC</code> does not disqualify the arc it feeds — the per-word mark sits on the <code>CC</code> block alone and never
+carries forward, and the centre reaches the arc already resolved.</p>
+<p>Two shapes are optimized as whole lines instead. Each reports its own id, once per run.</p>
+<ul>
+<li>The arc whose modal chain left an in-plane coordinate unstated — no <code>CC</code> ever gave it, so the arc's
+own start point supplies it, and every fragment would re-derive that centre from its own start:
+<code>NcOpt--SplitionStartPointCenterUnsupported</code>.</li>
+<li>The piece that carries an incremental word of its own — a klartext <code>I</code>-prefixed word, as in the
+legal and fully simulated <code>C IX+20 IY+0 DR-</code>, or a <code>G91</code> block in the DIN/ISO dialect. The fragment
+rewrite emits absolute coordinates, so every fragment would re-apply the distance from its own
+start: <code>NcOpt--SplitionIncrementalUnsupported</code>. The test reads the piece's own block only — the
+state of the modal <code>CC</code> chain neither triggers this one nor exempts a piece from it.</li>
+</ul>
 <h2 id="not-supported">Not supported</h2>
 <p><code>TOOL DEF</code>, <code>FK</code> free-contour programming, <code>SL</code> cycles, <code>PATTERN DEF</code>, and <code>TCH PROBE</code>. These are left
 unconsumed, and the block that carried them reports <code>Parsing--Unconsumed</code> naming the words.</p>