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 18:06:21 +08:00
parent 161af68fe3
commit 45b9f9ed5d
79 changed files with 1167 additions and 1532 deletions
Download Patch File Download Diff File Expand all files Collapse all files
App/wwwroot/HiAPI-docsite/api/Hi.NcParsers.LogicSyntaxs.MachineCoordSelectSyntax.html
+51 -4
View File
@@ -6,7 +6,7 @@
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="title" content="Class MachineCoordSelectSyntax | HiAPI-C# 2025 ">
<meta name="description" content="Handles machine coordinate selection — non-modal, one-shot. The axis values (X/Y/Z) in the block are interpreted as machine coordinates, bypassing all work offsets, local coordinates, tool height compensation, and coordinate rotations. If G91 (incremental) is active, the code is ignored per ISO standard. A per-word incremental stamp on the block (block-root entry — Siemens SUPA Y=IC(-10), klartext L IY-10 M91) is a distance in the machine frame: the word is added to the previous machine position of that axis. Defaults to ISO G53. Brands with additional one-shot machine-coordinate codes widen — the Siemens preset adds G153 and SUPA (both suppress every active frame for one block; in this pipeline all of those reduce to &quot;bypass the composed &quot;, which the ProgramXyz back-derivation below already models). The matched code is stamped verbatim into for bidirectional source recovery. Rotary words on the same block (e.g. SUPA G0 B0) are left to — same behavior as ISO G53, where rotary axes flow through the normal rotary path. Must be placed before and in the syntax chain. When a supported code is active, this syntax consumes X/Y/Z from and writes directly, preventing from processing them as program coordinates — and, ahead of the resolve, reading a per-word incremental word raw instead of re-based into the program frame.">
<meta name="description" content="Handles machine coordinate selection — non-modal, one-shot. The axis values (X/Y/Z) in the block are interpreted as machine coordinates, bypassing all work offsets, local coordinates, tool height compensation, and coordinate rotations. If G91 (incremental) is active, the code is ignored per ISO standard. A per-word incremental stamp on the block (block-root entry — Siemens SUPA Y=IC(-10), klartext L IY-10 M91) is a distance in the machine frame: the word is added to the previous machine position of that axis. Defaults to ISO G53. Brands with additional one-shot machine-coordinate codes widen — the Siemens preset adds G153 and SUPA (both suppress every active frame for one block; in this pipeline all of those reduce to &quot;bypass the composed &quot;, which the ProgramXyz back-derivation below already models). The matched code is stamped verbatim into for bidirectional source recovery. Rotary words on the same block (e.g. SUPA G0 B0, G53 A0 C0) are consumed by ahead of this syntax — machine and program rotary coincide while no rotary offsets are modeled — and the block is still a machine-coordinate positioning: the linear axes hold their machine position when no X/Y/Z word is given, and the motion is always . A machine-coordinate block never takes the RTCP tool-center-point linkage: on a real controller G53 applies no compensation, so a rotary swing commanded through it turns the axis in place instead of dragging X/Y/Z to pin the tool tip (the tip&#39;s post-swing program coordinate is what the back-derivation reports). Must be placed before and in the syntax chain. When a supported code is active, this syntax consumes X/Y/Z from and writes directly, preventing from processing them as program coordinates — and, ahead of the resolve, reading a per-word incremental word raw instead of re-based into the program frame.">
<link rel="icon" href="../img/HiAPI.favicon.ico">
<link rel="stylesheet" href="../public/docfx.min.css">
<link rel="stylesheet" href="../public/main.css">
@@ -116,9 +116,18 @@ active frame for one block; in this pipeline all of those reduce to
which the ProgramXyz back-derivation below already models). The
matched code is stamped verbatim into
<a class="xref" href="Hi.NcParsers.Keywords.IMotionEventDef.html#Hi_NcParsers_Keywords_IMotionEventDef_Term">Term</a> for bidirectional source recovery.
Rotary words on the same block (e.g. <code>SUPA G0 B0</code>) are left to
<a class="xref" href="Hi.NcParsers.LogicSyntaxs.McAbcSyntax.html">McAbcSyntax</a> — same behavior as ISO G53, where rotary
axes flow through the normal rotary path.
Rotary words on the same block (e.g. <code>SUPA G0 B0</code>,
<code>G53 A0 C0</code>) are consumed by <a class="xref" href="Hi.NcParsers.LogicSyntaxs.McAbcSyntax.html">McAbcSyntax</a> ahead of
this syntax — machine and program rotary coincide while no rotary
offsets are modeled — and the block is still a machine-coordinate
positioning: the linear axes <b>hold their machine position</b>
when no X/Y/Z word is given, and the motion is always
<a class="xref" href="Hi.NcParsers.Keywords.Generic.MotionForm.html#Hi_NcParsers_Keywords_Generic_MotionForm_McLinear">McLinear</a>. A machine-coordinate block never
takes the RTCP tool-center-point linkage: on a real controller G53
applies no compensation, so a rotary swing commanded through it
turns the axis in place instead of dragging X/Y/Z to pin the tool
tip (the tip's post-swing program coordinate is what the
back-derivation reports).
</p>
<p>
Must be placed <b>before</b> <a class="xref" href="Hi.NcParsers.LogicSyntaxs.IncrementalResolveSyntax.html">IncrementalResolveSyntax</a>
@@ -301,6 +310,44 @@ section stays on the block (one-shot, nobody consumes it):
"ProgramXyz": { "X": 100, "Y": 40, "Z": -200 },
"MotionEvent": { "Form": "McLinear", "IsRapid": true, "Term": "G53" }
}</code></pre>
<p>Rotary-only machine-coordinate block under RTCP (<code>G0 G53 A0.</code>
while <code>G43.4</code> is active) — <code>McAbcSyntax</code> has already
consumed the rotary word into <code>MachineCoordinateState</code>, and
<code>G43p4RtcpSyntax</code> has tagged the chain <code>Dynamic</code> because
the tool orientation changes across the block. The linear axes hold
the previous machine position (G53 applies no compensation, so the
swing turns the axis in place instead of pinning the tool tip) and
the motion is stamped <code>McLinear</code>; <code>ProgramXyz</code> is the tip's
program coordinate after the swing — the 10 mm tool-height entry is
inverted, MC Z 0 → program Z −10:
#Previous:</p>
<pre><code class="lang-csharp">{ "MachineCoordinateState": { "X": -1, "Y": -1, "Z": 0, "A": 90 } }</code></pre>
<p>#BeforeBuild:</p>
<pre><code class="lang-csharp">{
"Parsing": { "Flags": ["G53", "G00"] },
"MachineCoordinateState": { "A": 0 },
"ProgramToMcTransform": [
{
"Source": "ToolHeightCompensation",
"Kind": "Dynamic",
"Mat4d": [1,0,0,0, 0,1,0,0, 0,0,1,0, 0,0,10,1]
}
]
}</code></pre>
<p>#AfterBuild:</p>
<pre><code class="lang-csharp">{
"MachineCoordinateState": { "A": 0, "X": -1, "Y": -1, "Z": 0 },
"ProgramToMcTransform": [
{
"Source": "ToolHeightCompensation",
"Kind": "Dynamic",
"Mat4d": [1,0,0,0, 0,1,0,0, 0,0,1,0, 0,0,10,1]
}
],
"ProgramXyz": { "X": -1, "Y": -1, "Z": -10 },
"MotionState": { "Term": "G00" },
"MotionEvent": { "Form": "McLinear", "IsRapid": true, "Term": "G53" }
}</code></pre>