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-13 19:45:24 +08:00
parent 397a7a8cc4
commit 2db889ad89
58 changed files with 3526 additions and 213 deletions
Download Patch File Download Diff File Expand all files Collapse all files
App/wwwroot/HiAPI-docsite/api/Hi.NcParsers.LogicSyntaxs.McAbcSyntax.html
+36 -10
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. 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. 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 .">
<link rel="icon" href="../img/HiAPI.favicon.ico">
<link rel="stylesheet" href="../public/docfx.min.css">
<link rel="stylesheet" href="../public/main.css">
@@ -168,6 +168,18 @@ resolve (invalid number, missing table) reports an error and holds
the axis at its previous value.
</p>
<p>
Every rotary word the block actually carried is also recorded, as
programmed, in the one-shot block-root <a class="xref" href="Hi.NcParsers.Keywords.RotaryWords.html">RotaryWords</a>
section (<code>{ "C": 40 }</code>) — the resolved angle goes into
<code>MachineCoordinateState</code>, which after the modal carry can no
longer tell "commanded" from "carried". Downstream consumers that need
that distinction (<a class="xref" href="Hi.NcParsers.LogicSyntaxs.CannedCycleResolveSyntax.html">CannedCycleResolveSyntax</a> repeating an
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.
</p>
<p>
Must be placed <b>before</b> <a class="xref" href="Hi.NcParsers.LogicSyntaxs.McXyzSyntax.html">McXyzSyntax</a> so syntaxes
that need the current-block ABC to compute transforms
(e.g. <a class="xref" href="Hi.NcParsers.LogicSyntaxs.G43p4RtcpSyntax.html">G43p4RtcpSyntax</a>) can see it; and <b>before</b>
@@ -270,24 +282,34 @@ no-op (the syntax only fires when rotary axes are declared):
AxisConfig declares B+C rotary; <code>Parsing.B/C</code> are consumed
into a freshly created <code>MachineCoordinateState</code> section
(X/Y/Z are deliberately left out so <a class="xref" href="Hi.NcParsers.LogicSyntaxs.McXyzSyntax.html">McXyzSyntax</a> can
still derive XYZ later — see class summary):
still derive XYZ later — see class summary). The words the block
spoke are recorded as programmed in the one-shot
<a class="xref" href="Hi.NcParsers.Keywords.RotaryWords.html">RotaryWords</a> section:
#BeforeBuild:
<pre><code class="lang-csharp">{ "Parsing": { "B": 45, "C": 90 } }</code></pre>
#AfterBuild:
<pre><code class="lang-csharp">{ "MachineCoordinateState": { "B": 45, "C": 90 } }</code></pre>
<pre><code class="lang-csharp">{
"MachineCoordinateState": { "B": 45, "C": 90 },
"RotaryWords": { "B": 45, "C": 90 }
}</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>):
per-axis backward lookback (<a class="xref" href="Hi.NcParsers.Syntaxs.SyntaxPiece.html">FindPreviousMcAxis(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>
#BeforeBuild:
<pre><code class="lang-csharp">{ "Parsing": { "B": 30 } }</code></pre>
#AfterBuild:
<pre><code class="lang-csharp">{ "MachineCoordinateState": { "B": 30, "C": 0 } }</code></pre>
<pre><code class="lang-csharp">{
"MachineCoordinateState": { "B": 30, "C": 0 },
"RotaryWords": { "B": 30 }
}</code></pre>
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:
entry and fills from lookback as usual. <code>RotaryWords</code> keeps the
programmed delta, not the accumulated angle:
#Previous:
<pre><code class="lang-csharp">{ "MachineCoordinateState": { "B": 10, "C": 40 } }</code></pre>
#BeforeBuild:
@@ -298,14 +320,16 @@ entry and fills from lookback as usual:
#AfterBuild:
<pre><code class="lang-csharp">{
"PositioningOverride": { "C": "Incremental" },
"MachineCoordinateState": { "B": 10, "C": 61.5 }
"MachineCoordinateState": { "B": 10, "C": 61.5 },
"RotaryWords": { "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
<code>SiemensMachineDataTable</code> declaring C rotary and assigned to
indexing table 1 = <code>[0, 90, 180, 270]</code>: position number 3
resolves to 180° and the override entry is rewritten to
<code>Absolute</code> for the tail-pass:
<code>Absolute</code> for the tail-pass (<code>RotaryWords</code> keeps the
position number the program spoke):
#BeforeBuild:
<pre><code class="lang-csharp">{
"PositioningOverride": { "C": "CodedAbsolute" },
@@ -314,7 +338,8 @@ resolves to 180° and the override entry is rewritten to
#AfterBuild:
<pre><code class="lang-csharp">{
"PositioningOverride": { "C": "Absolute" },
"MachineCoordinateState": { "C": 180 }
"MachineCoordinateState": { "C": 180 },
"RotaryWords": { "C": 3 }
}</code></pre>
Coded-position incremental with the same table — from 270° (position
4), advancing 2 positions wraps the 4-position cycle to position 2
@@ -330,7 +355,8 @@ so the swing keeps the programmed direction:
#AfterBuild:
<pre><code class="lang-csharp">{
"PositioningOverride": { "C": "PositiveOnly" },
"MachineCoordinateState": { "C": 90 }
"MachineCoordinateState": { "C": 90 },
"RotaryWords": { "C": 2 }
}</code></pre>