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-12 18:16:27 +08:00
parent b7f55aa631
commit 397a7a8cc4
96 changed files with 1167 additions and 1259 deletions
Download Patch File Download Diff File Expand all files Collapse all files
App/wwwroot/HiAPI-docsite/api/Hi.NcParsers.ParsingSyntaxs.Heidenhain.HeidenhainFnFeatureSyntax.html
+3 -2
View File
@@ -6,7 +6,7 @@
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="title" content="Class HeidenhainFnFeatureSyntax | HiAPI-C# 2025 ">
<meta name="description" content="Structured skip for the Heidenhain FN opcodes the simulation does not implement (FN 14 error display, FN 16 print, FN 18 SYSREAD, table/pallet opcodes …): the whole statement is consumed and a single HeidenhainFn&amp;ndash;Unsupported warning names the opcode. Two opcode families pass through untouched: FN 0-5 belong to (which runs earlier), and the jump family FN 9-12 belongs to (also earlier) — the pass-through here is the malformed-jump safety net: a jump line the owner&#39;s grammar rejects surfaces as visible residue instead of a fabricated skip. Claiming the statement here is load-bearing, not cosmetic: an FN 18 line like FN18: SYSREAD Q94= ID50 NR11 contains a Q94= token that the bare Q-assignment capture (later in the Parsing bundle) would otherwise grab, storing the garbage string ID50 into Q94. The target parameter must instead stay vacant so dependent expressions fail soft (VariableExpression--Unevaluated) — no fabricated values.">
<meta name="description" content="Structured skip for the Heidenhain FN opcodes the simulation does not implement (FN 14 error display, FN 16 print, FN 18 SYSREAD, table/pallet opcodes …): the whole statement is consumed and a single warning names the opcode — HeidenhainFn&amp;ndash;Unsupported, or HeidenhainFn&amp;ndash;UnsupportedSysread for the FN 18 wording. Two opcode families pass through untouched: FN 0-5 belong to (which runs earlier), and the jump family FN 9-12 belongs to (also earlier) — the pass-through here is the malformed-jump safety net: a jump line the owner&#39;s grammar rejects surfaces as visible residue instead of a fabricated skip. Claiming the statement here is load-bearing, not cosmetic: an FN 18 line like FN18: SYSREAD Q94= ID50 NR11 contains a Q94= token that the bare Q-assignment capture (later in the Parsing bundle) would otherwise grab, storing the garbage string ID50 into Q94. The target parameter must instead stay vacant so dependent expressions fail soft (VariableExpression--Unevaluated) — no fabricated values.">
<link rel="icon" href="../img/HiAPI.favicon.ico">
<link rel="stylesheet" href="../public/docfx.min.css">
<link rel="stylesheet" href="../public/main.css">
@@ -100,7 +100,8 @@ Class HeidenhainFnFeatureSyntax
<div class="markdown summary"><p>Structured skip for the Heidenhain FN opcodes the simulation does not
implement (<code>FN 14</code> error display, <code>FN 16</code> print, <code>FN 18</code>
SYSREAD, table/pallet opcodes …): the whole statement is consumed and a
single <code>HeidenhainFn&ndash;Unsupported</code> warning names the opcode. Two
single warning names the opcode — <code>HeidenhainFn&ndash;Unsupported</code>, or
<code>HeidenhainFn&ndash;UnsupportedSysread</code> for the <code>FN 18</code> wording. Two
opcode families pass through untouched: <code>FN 0-5</code> belong to
<a class="xref" href="Hi.NcParsers.ParsingSyntaxs.Heidenhain.HeidenhainFnAssignmentSyntax.html">HeidenhainFnAssignmentSyntax</a> (which runs earlier), and the
jump family <code>FN 9-12</code> belongs to