This commit is contained in:
2026-09-09 17:35:23 +08:00
parent 2a98ae7556
commit 161af68fe3
1271 changed files with 58251 additions and 98639 deletions
@@ -6,7 +6,7 @@
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="title" content="Class IncrementalResolveSyntax | HiAPI-C# 2025 ">
<meta name="description" content="Resolves G91 incremental axis values to absolute in-place within and its sub-sections. Reads written by . Per-word override: a block-root section (written by for the Siemens per-word coordinate functions) beats the modal term for the listed axes on this block only: an entry converts that word even under G90, an entry skips it even under G91 — as does, deliberately, every other non-Incremental value (the rotary-family / / entries are absolute targets; their swing resolution lives in , not here). A coded-position entry ( / — Siemens CAC()/CIC() on a linear indexing axis) carries an indexing position number instead of a coordinate: the number is resolved through via , the word is rewritten to the resolved absolute coordinate, and the entry to ; a failed resolve reports an error and holds the last program position. Axes without an entry follow the modal term unchanged, so brands that never write the section (Fanuc/Heidenhain/...) keep the exact legacy behavior. specifies which JSON paths contain axis values that need incremental-to-absolute conversion. Default: [[&quot;Parsing&quot;], [&quot;Parsing&quot;, &quot;G28&quot;]]. All matching paths are converted. Canned cycle paths (Parsing.G81, G82, G83, …) are intentionally excluded — their Z/R incremental semantics differ from normal axes (R is relative to init level, Z is relative to R-point). Resolution is handled by inside each cycle syntax class, which runs before this syntax. Uses to determine which tags are motion axes. Traces backward nodes for last known to resolve incremental values. After this syntax, all axis values in the working paths are absolute — can consume them without incremental logic.">
<meta name="description" content="Resolves G91 incremental axis values to absolute in-place within and its sub-sections. Reads written by . Per-word override: a block-root section (written by for the Siemens per-word coordinate functions, and by the Heidenhain L / C / CC / CYCL CALL POS parsers for the klartext I-prefixed words — see ; the CYCL CALL POS words never reach this syntax, resolves them on the spot ahead of it) beats the modal term for the listed axes on this block only: an entry converts that word even under G90, an entry skips it even under G91 — as does, deliberately, every other non-Incremental value (the rotary-family / / entries are absolute targets; their swing resolution lives in , not here). A coded-position entry ( / — Siemens CAC()/CIC() on a linear indexing axis) carries an indexing position number instead of a coordinate: the number is resolved through via , the word is rewritten to the resolved absolute coordinate, and the entry to ; a failed resolve reports an error and holds the last program position. Axes without an entry follow the modal term unchanged, so brands that never write the section (Fanuc/...) keep the exact legacy behavior. specifies which JSON paths contain axis values that need incremental-to-absolute conversion. Default: [[&quot;Parsing&quot;], [&quot;Parsing&quot;, &quot;G28&quot;]]; the Heidenhain bundle instead walks [&quot;Parsing&quot;, &quot;CC&quot;] for the klartext circle-center record (). All matching paths are converted against the same last program position — a nested record&#39;s words are distances from where the tool stands, exactly like the root&#39;s. Canned cycle paths (Parsing.G81, G82, G83, …) are intentionally excluded — their Z/R incremental semantics differ from normal axes (R is relative to init level, Z is relative to R-point). Resolution is handled by inside each cycle syntax class, which runs before this syntax. Uses to determine which tags are motion axes. Traces backward nodes for last known to resolve incremental values. After this syntax, all axis values in the working paths are absolute — can consume them without incremental logic.">
<link rel="icon" href="../img/HiAPI.favicon.ico">
<link rel="stylesheet" href="../public/docfx.min.css">
<link rel="stylesheet" href="../public/main.css">
@@ -105,7 +105,13 @@ by <a class="xref" href="Hi.NcParsers.LogicSyntaxs.PositioningSyntax.html">Posit
Per-word override: a block-root
<a class="xref" href="Hi.NcParsers.Keywords.PositioningOverride.html">PositioningOverride</a> section (written by
<a class="xref" href="Hi.NcParsers.EvaluationSyntaxs.Siemens.SiemensAcIcSyntax.html">SiemensAcIcSyntax</a> for the
Siemens per-word coordinate functions) beats the modal
Siemens per-word coordinate functions, and by the Heidenhain L / C /
CC / CYCL CALL POS parsers for the klartext I-prefixed words — see
<a class="xref" href="Hi.NcParsers.ParsingSyntaxs.Heidenhain.HeidenhainIncrementalAxisWordUtil.html">HeidenhainIncrementalAxisWordUtil</a>;
the CYCL CALL POS words never reach this syntax,
<a class="xref" href="Hi.NcParsers.LogicSyntaxs.Heidenhain.HeidenhainCannedCycleSyntax.html">HeidenhainCannedCycleSyntax</a> resolves them on
the spot ahead of it)
beats the modal
term for the listed axes on this block only: an
<a class="xref" href="Hi.NcParsers.Keywords.Positioning.html#Hi_NcParsers_Keywords_Positioning_Incremental">Incremental</a> entry converts that word even
under G90, an <a class="xref" href="Hi.NcParsers.Keywords.Positioning.html#Hi_NcParsers_Keywords_Positioning_Absolute">Absolute</a> entry skips it even
@@ -125,13 +131,18 @@ is rewritten to the resolved absolute coordinate, and the entry to
<a class="xref" href="Hi.NcParsers.Keywords.Positioning.html#Hi_NcParsers_Keywords_Positioning_Absolute">Absolute</a>; a failed resolve reports an error
and holds the last program position. Axes without an entry follow the
modal term unchanged, so brands that never write the section
(Fanuc/Heidenhain/...) keep the exact legacy behavior.
(Fanuc/...) keep the exact legacy behavior.
</p>
<p>
<a class="xref" href="Hi.NcParsers.LogicSyntaxs.IncrementalResolveSyntax.html#Hi_NcParsers_LogicSyntaxs_IncrementalResolveSyntax_WorkingPathList">WorkingPathList</a> specifies which JSON paths
contain axis values that need incremental-to-absolute conversion.
Default: <code>[["Parsing"], ["Parsing", "G28"]]</code>.
All matching paths are converted.
Default: <code>[["Parsing"], ["Parsing", "G28"]]</code>; the Heidenhain
bundle instead walks <code>["Parsing", "CC"]</code> for the klartext
circle-center record
(<a class="xref" href="Hi.NcParsers.Syntaxs.HeidenhainSyntaxUtil.html#Hi_NcParsers_Syntaxs_HeidenhainSyntaxUtil_CcAwareIncrementalResolveSyntax">CcAwareIncrementalResolveSyntax</a>).
All matching paths are converted against the same last program
position — a nested record's words are distances from where the
tool stands, exactly like the root's.
</p>
<p>
Canned cycle paths (Parsing.G81, G82, G83, …) are intentionally
@@ -331,6 +342,26 @@ and the entry is rewritten to <code>Absolute</code>:
"PositioningOverride": { "X": "Absolute" },
"Parsing": { "X": -100 }
}</code></pre>
<p>The Heidenhain instance
(<a class="xref" href="Hi.NcParsers.Syntaxs.HeidenhainSyntaxUtil.html#Hi_NcParsers_Syntaxs_HeidenhainSyntaxUtil_CcAwareIncrementalResolveSyntax">CcAwareIncrementalResolveSyntax</a>)
on a klartext <code>CC IX+0 IY+11</code> block after the CC parser: the
nested record resolves against the last programmed position (the
tool stands at (10, 20)), so the center lands at (10, 31); the Parsing
root carries no axis word on a CC block and is untouched:
#Previous:</p>
<pre><code class="lang-csharp">{ "MachineCoordinateState": { "X": 10, "Y": 20, "Z": 0 } }</code></pre>
<p>#BeforeBuild:</p>
<pre><code class="lang-csharp">{
"Positioning": { "Term": "G90", "Mode": "Absolute" },
"PositioningOverride": { "X": "Incremental", "Y": "Incremental" },
"Parsing": { "CC": { "X": 0, "Y": 11 } }
}</code></pre>
<p>#AfterBuild:</p>
<pre><code class="lang-csharp">{
"Positioning": { "Term": "G90", "Mode": "Absolute" },
"PositioningOverride": { "X": "Incremental", "Y": "Incremental" },
"Parsing": { "CC": { "X": 10, "Y": 31 } }
}</code></pre>