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-15 01:12:50 +08:00
parent 2db889ad89
commit 1a75503105
99 changed files with 4168 additions and 726 deletions
Download Patch File Download Diff File Expand all files Collapse all files
App/wwwroot/HiAPI-docsite/api/Hi.NcParsers.LogicSyntaxs.McAbcSyntax.html
+82 -5
View File
@@ -6,7 +6,7 @@
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="title" content="Class McAbcSyntax | HiAPI-C# 2025 ">
<meta name="description" content="Writes rotary axis values (A/B/C) into from and modal lookback. Only active when declares rotary axes. Works for both 3+2-axis (no ) and simultaneous 5-axis configurations. This syntax is intentionally ABC-only. When the block is rotary-only (no ProgramXyz, e.g. G00 A30.) the section is created with ABC but without X/Y/Z. — placed after — copies X/Y/Z from the previous block&#39;s to finish the section. Splitting the XYZ fill out lets this syntax run before (and before ) without accidentally filling X/Y/Z from prev and thereby short-circuiting . Missing rotary axes are filled from previous lookback, unless the current section already has the value (e.g., from ). Values are stored in degrees (matching ). Per-word override: a block-root section (written by for the Siemens AC()/IC() coordinate functions, and by the Heidenhain L / C parsers for the klartext IA+/IB+/IC+ words) marks a rotary word : the parsed value is then added to the previous modal value of that axis (previous MachineCoordinateState lookback, falling back to a value already present in the current section, then 0) instead of being written as an absolute angle. The accumulated raw degrees stay monotonic across iterations: the tail-pass keeps an Incremental-stamped axis literal (a chain dimension is a signed traverse, never re-shortened), so even a +270&#176; step survives as net rotation. An entry (from AC()) matches the default write and needs no special path — and so, deliberately, do the rotary-family entries (DC()) / (ACP()) / (ACN()): this syntax writes the raw absolute target and the shortest/directional swing is resolved by the tail-pass, which owns the wrap math. Brands that never write the section keep the exact legacy behavior. Coded-position overrides (Siemens CAC()/CIC()/CDC()/CACP()/CACN()) carry an indexing position number instead of an angle: the number is resolved through via and the override entry is rewritten to the plain vocabulary ( / / / — a cyclic CIC keeps its programmed direction through the directional values) before the tail-pass runs, so the tail-pass never sees a coded value. A failed resolve (invalid number, missing table) reports an error and holds the axis at its previous value. Every rotary word the block actually carried is also recorded, as programmed, in the one-shot block-root section ({ &quot;C&quot;: 40 }) — the resolved angle goes into MachineCoordinateState, which after the modal carry can no longer tell &quot;commanded&quot; from &quot;carried&quot;. Downstream consumers that need that distinction ( repeating an active canned cycle on a rotary-only block, riding the block&#39;s ABC on the cycle&#39;s pre-positioning item) read the record; the section is never modal-carried. Must be placed before so syntaxes that need the current-block ABC to compute transforms (e.g. ) can see it; and before and .">
<meta name="description" content="Writes rotary axis values (A/B/C) into from and modal lookback. Only active when declares rotary axes. Works for both 3+2-axis (no ) and simultaneous 5-axis configurations. This syntax is intentionally ABC-only. When the block is rotary-only (no ProgramXyz, e.g. G00 A30.) the section is created with ABC but without X/Y/Z. — placed after — copies X/Y/Z from the previous block&#39;s to finish the section. Splitting the XYZ fill out lets this syntax run before (and before ) without accidentally filling X/Y/Z from prev and thereby short-circuiting . Missing rotary axes are filled from previous lookback, unless the current section already has the value (e.g., from ). Values are stored in degrees (matching ). Per-word override: a block-root section (written by for the Siemens AC()/IC() coordinate functions, and by the Heidenhain L / C parsers for the klartext IA+/IB+/IC+ words) marks a rotary word : the parsed value is then added to the previous modal value of that axis (previous MachineCoordinateState lookback, falling back to a value already present in the current section, then 0) instead of being written as an absolute angle. The accumulated raw degrees stay monotonic across iterations: the tail-pass keeps an Incremental-stamped axis literal (a chain dimension is a signed traverse, never re-shortened), so even a +270&#176; step survives as net rotation. An entry (from AC()) matches the default write and needs no special path — and so, deliberately, do the rotary-family entries (DC()) / (ACP()) / (ACN()): this syntax writes the raw absolute target and the shortest/directional swing is resolved by the tail-pass, which owns the wrap math. Brands that never write the section keep the exact legacy behavior. Modal G91: a rotary word with no per-word entry follows the block&#39;s state (written ahead of this syntax by on every brand list) the way the linear words follow it in — under G91 it takes the same anchor + delta path as the override, so G91 … C20. repeated turns the table 20&#176; further each block (Fanuc / Siemens / Heidenhain DIN-ISO all read an incremental rotary word as a signed traverse; the tail-pass keeps it literal for the axes the record lists). A per-word entry of any value beats the modal state for its word (G91 C=AC(90) is absolute). Rotary values another writer put on the block without a word — , the Heidenhain PLANE syntax — are absolute targets and are not touched. HardNc differs here by design of its own: HardNcLine.BuildOrdinaryMcAbc writes the word as an absolute angle under G91 and warns (&quot;G91 is not effect for commands ABC&quot;), so the two engines diverge on G91 rotary words — the parity fixtures assert the SoftNc leg only. Coded-position overrides (Siemens CAC()/CIC()/CDC()/CACP()/CACN()) carry an indexing position number instead of an angle: the number is resolved through via and the override entry is rewritten to the plain vocabulary ( / / / — a cyclic CIC keeps its programmed direction through the directional values) before the tail-pass runs, so the tail-pass never sees a coded value. A failed resolve (invalid number, missing table) reports an error and holds the axis at its previous value. Every rotary word the block actually carried is also recorded, as programmed, in the one-shot block-root section ({ &quot;C&quot;: 40 }) — the resolved angle goes into MachineCoordinateState, which after the modal carry can no longer tell &quot;commanded&quot; from &quot;carried&quot;. Downstream consumers that need that distinction ( repeating an active canned cycle on a rotary-only block, riding the block&#39;s ABC on the cycle&#39;s pre-positioning item) read the record; the section is never modal-carried. Its sibling records, with the programmed delta, the rotary words this syntax accumulated as increments (per-word IC()/IC+ or a bare word under modal G91): the MC value is an absolute angle from then on and the modal still says G91, so without the record an accumulated word would read like a programmed absolute. adds the block&#39;s linear increments to the same record later in the list, and reads it to pass the listed axes through the shortest-path wrap literally. Must be placed before so syntaxes that need the current-block ABC to compute transforms (e.g. ) can see it; and before and .">
<link rel="icon" href="../img/HiAPI.favicon.ico">
<link rel="stylesheet" href="../public/docfx.min.css">
<link rel="stylesheet" href="../public/main.css">
@@ -152,6 +152,28 @@ math. Brands that never write the section keep the exact legacy
behavior.
</p>
<p>
Modal G91: a rotary word with <b>no</b> per-word entry follows the
block's <a class="xref" href="Hi.NcParsers.Keywords.Positioning.html">Positioning</a> state (written ahead of this
syntax by <a class="xref" href="Hi.NcParsers.LogicSyntaxs.PositioningSyntax.html">PositioningSyntax</a> on every brand list) the
way the linear words follow it in
<a class="xref" href="Hi.NcParsers.LogicSyntaxs.IncrementalResolveSyntax.html">IncrementalResolveSyntax</a> — under <code>G91</code> it takes
the same anchor + delta path as the <a class="xref" href="Hi.NcParsers.Keywords.Positioning.html#Hi_NcParsers_Keywords_Positioning_Incremental">Incremental</a>
override, so <code>G91 … C20.</code> repeated turns the table 20° further
each block (Fanuc / Siemens / Heidenhain DIN-ISO all read an
incremental rotary word as a signed traverse; the
<a class="xref" href="Hi.NcParsers.LogicSyntaxs.McAbcCyclicPathSyntax.html">McAbcCyclicPathSyntax</a> tail-pass keeps it literal for
the axes the <a class="xref" href="Hi.NcParsers.Keywords.IncrementalWords.html">IncrementalWords</a> record lists). A per-word entry of any
value beats the modal state for its word (<code>G91 C=AC(90)</code> is
absolute). Rotary values another writer put on the block without a
word — <a class="xref" href="Hi.NcParsers.LogicSyntaxs.G53p1RotaryPositionSyntax.html">G53p1RotaryPositionSyntax</a>, the Heidenhain
<code>PLANE</code> syntax — are absolute targets and are not touched.
HardNc differs here by design of its own: <code>HardNcLine.BuildOrdinaryMcAbc</code>
writes the word as an absolute angle under G91 and warns
(<i>"G91 is not effect for commands ABC"</i>), so the two engines
diverge on G91 rotary words — the parity fixtures assert the
SoftNc leg only.
</p>
<p>
Coded-position overrides (Siemens
<code>CAC()</code>/<code>CIC()</code>/<code>CDC()</code>/<code>CACP()</code>/<code>CACN()</code>)
carry an indexing position <b>number</b> instead of an angle: the
@@ -177,7 +199,17 @@ that distinction (<a class="xref" href="Hi.NcParsers.LogicSyntaxs.CannedCycleRes
active canned cycle on a rotary-only block,
<a class="xref" href="https://learn.microsoft.com/dotnet/api/system.text.json.nodes.jsonobject">WriteCompoundMotion(JsonObject, string, JsonArray, Vec3d)</a> riding the
block's ABC on the cycle's pre-positioning item) read the record; the
section is never modal-carried.
section is never modal-carried. Its sibling
<a class="xref" href="Hi.NcParsers.Keywords.IncrementalWords.html">IncrementalWords</a> records, with the programmed delta,
the rotary words this syntax accumulated as increments (per-word
<code>IC()</code>/<code>IC+</code> or a bare word under modal G91): the MC
value is an absolute angle from then on and the modal
<a class="xref" href="Hi.NcParsers.Keywords.Positioning.html">Positioning</a> still says G91, so without the record an
accumulated word would read like a programmed absolute.
<a class="xref" href="Hi.NcParsers.LogicSyntaxs.IncrementalResolveSyntax.html">IncrementalResolveSyntax</a> adds the block's linear
increments to the same record later in the list, and
<a class="xref" href="Hi.NcParsers.LogicSyntaxs.McAbcCyclicPathSyntax.html">McAbcCyclicPathSyntax</a> reads it to pass the listed axes
through the shortest-path wrap literally.
</p>
<p>
Must be placed <b>before</b> <a class="xref" href="Hi.NcParsers.LogicSyntaxs.McXyzSyntax.html">McXyzSyntax</a> so syntaxes
@@ -294,7 +326,8 @@ spoke are recorded as programmed in the one-shot
}</code></pre>
Only <code>Parsing.B</code> on the current block; <code>#Previous:</code>
carries a full MC including C=0. The missing C is filled from the
per-axis backward lookback (<a class="xref" href="Hi.NcParsers.Syntaxs.SyntaxPiece.html">FindPreviousMcAxis(LazyLinkedListNode&lt;SyntaxPiece&gt;, string)</a>) — and
per-axis backward lookback
(<a class="xref" href="Hi.NcParsers.LogicSyntaxs.RotaryAxisUtil.html#Hi_NcParsers_LogicSyntaxs_RotaryAxisUtil_FindPreviousMcAxisDeg_Hi_Common_Collections_LazyLinkedListNode_Hi_NcParsers_Syntaxs_SyntaxPiece__System_String_">FindPreviousMcAxisDeg(LazyLinkedListNode&lt;SyntaxPiece&gt;, string)</a>) — and
stays out of <code>RotaryWords</code>, which lists commanded words only:
#Previous:
<pre><code class="lang-csharp">{ "MachineCoordinateState": { "B": 0, "C": 0 } }</code></pre>
@@ -309,7 +342,8 @@ Per-word incremental override (the Siemens <code>C=IC(...)</code> shape
after the unwrap + evaluation stages) — the parsed 21.5 is added onto
the previous modal C instead of overwriting it; B has no override
entry and fills from lookback as usual. <code>RotaryWords</code> keeps the
programmed delta, not the accumulated angle:
programmed delta, not the accumulated angle, and the accumulated
word is listed in <code>IncrementalWords</code>:
#Previous:
<pre><code class="lang-csharp">{ "MachineCoordinateState": { "B": 10, "C": 40 } }</code></pre>
#BeforeBuild:
@@ -321,7 +355,8 @@ programmed delta, not the accumulated angle:
<pre><code class="lang-csharp">{
"PositioningOverride": { "C": "Incremental" },
"MachineCoordinateState": { "B": 10, "C": 61.5 },
"RotaryWords": { "C": 21.5 }
"RotaryWords": { "C": 21.5 },
"IncrementalWords": { "C": 21.5 }
}</code></pre>
Coded-position absolute (the Siemens <code>C=CAC(3)</code> shape after the
unwrap + evaluation stages). The case injects a
@@ -358,6 +393,48 @@ so the swing keeps the programmed direction:
"MachineCoordinateState": { "C": 90 },
"RotaryWords": { "C": 2 }
}</code></pre>
Modal G91 with no per-word entry (the Fanuc <code>G91 … C20.</code>
canned-cycle repeat block): the rotary word is a signed traverse
like the linear words, so it accumulates onto the previous modal C
exactly as the Incremental override above (20 + 20 = 40); B has no
word and fills from lookback. <code>RotaryWords</code> keeps the programmed
delta and <code>IncrementalWords</code> lists the word — the modal section
still says G91, and this record is what tells the accumulated 40
apart from a programmed <code>C40.</code>:
#Previous:
<pre><code class="lang-csharp">{ "MachineCoordinateState": { "B": 10, "C": 20 } }</code></pre>
#BeforeBuild:
<pre><code class="lang-csharp">{
"Positioning": { "Term": "G91", "Mode": "Incremental" },
"Parsing": { "C": 20 }
}</code></pre>
#AfterBuild:
<pre><code class="lang-csharp">{
"Positioning": { "Term": "G91", "Mode": "Incremental" },
"MachineCoordinateState": { "B": 10, "C": 40 },
"RotaryWords": { "C": 20 },
"IncrementalWords": { "C": 20 }
}</code></pre>
Modal G91 with a per-word <code>Absolute</code> entry (the Siemens
<code>G91 … C=AC(90)</code> shape): the entry beats the modal state for
its word, so C is written as the absolute 90 — the same rule
<a class="xref" href="Hi.NcParsers.LogicSyntaxs.IncrementalResolveSyntax.html">IncrementalResolveSyntax</a> applies to <code>X=AC(25)</code>
under G91:
#Previous:
<pre><code class="lang-csharp">{ "MachineCoordinateState": { "B": 10, "C": 20 } }</code></pre>
#BeforeBuild:
<pre><code class="lang-csharp">{
"Positioning": { "Term": "G91", "Mode": "Incremental" },
"PositioningOverride": { "C": "Absolute" },
"Parsing": { "C": 90 }
}</code></pre>
#AfterBuild:
<pre><code class="lang-csharp">{
"Positioning": { "Term": "G91", "Mode": "Incremental" },
"PositioningOverride": { "C": "Absolute" },
"MachineCoordinateState": { "B": 10, "C": 90 },
"RotaryWords": { "C": 90 }
}</code></pre>