HiNC-Deploy/HiNC-2025-win-desktop-Deploy
Archived
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

deploy.

Browse Source
This commit is contained in:
iamboss
2026-09-09 17:35:23 +08:00
parent 2a98ae7556
commit 161af68fe3
1271 changed files with 58251 additions and 98639 deletions
Download Patch File Download Diff File Expand all files Collapse all files
App/wwwroot/HiAPI-docsite/api/Hi.NcParsers.ParsingSyntaxs.Heidenhain.html
+116 -2
View File
@@ -116,7 +116,11 @@ 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).</p>
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">
@@ -135,6 +139,16 @@ 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">
@@ -147,7 +161,13 @@ 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.</li></ul>
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
@@ -220,6 +240,46 @@ load-bearing gate) and before <a class="xref" href="Hi.NcParsers.ParsingSyntaxs.
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">
@@ -258,6 +318,14 @@ captured as boolean records on the Parsing root; the Logic-stage
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">
@@ -272,6 +340,52 @@ 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">