This commit is contained in:
2026-09-12 18:16:27 +08:00
parent b7f55aa631
commit 397a7a8cc4
96 changed files with 1167 additions and 1259 deletions
@@ -139,9 +139,10 @@ and their conditions are under
<a href="upgrading-to-3.2/performance-and-footprint.html">Performance and footprint</a>.</p>
<p><strong>The application product moves to the web API.</strong> The web service is the application the product
line is built on, and its source is the same <a href="../technique/api-foundations/packages-and-samples.html#hiapi-sample-code"><code>HiNC-2025-webservice</code></a>
sample we publish — what you read there is what the product runs. A Windows desktop client ships
alongside it on the same packages, and no new feature work targets it. The Blazor front end builds
against the same 3.2 packages but is not published as a product.</p>
sample we publish — what you read there is what the product runs. The WPF desktop client is
retired with this line: it was a demo of the same packages rather than a product surface, it takes
no feature work, and it is no longer documented here. The Blazor front end builds against the same
3.2 packages but is not published as a product.</p>
<div class="IMPORTANT">
<h5>Important</h5>
<p><strong>Adoption status.</strong> This drop is published for review. Verification is still in progress across
@@ -287,7 +288,7 @@ fixed; large geometry now builds its display topology off-thread instead of free
</ul>
<h2 id="hinc-packages-version-31172">HiNc Packages Version 3.1.172</h2>
<ul>
<li>Replace implicit XFactory registration (private <code>static &lt;ClassName&gt;()</code> constructors + <code>_ = X.XName</code> wake-up touches) with explicit <code>public static void Reg(XFactory factory = null)</code> methods across ~270 classes. <a class="xref" href="../api/Hi.Common.XmlUtils.XFactory.html">XFactory</a> becomes an instance class with a process-wide <code>Default</code> singleton; <code>Generators</code> is renamed from <code>Regs</code> and now an instance property; the delegate type is renamed <code>XGeneratorDelegate</code> from <code>GenByXElementDelegate</code>. Composite types chain <code>X.Reg(factory)</code> on dependents in place of the old wake-up touches; multi-name (legacy alias) registrations keep the current XName first and group aliases under a <code>//legacy aliases</code> comment. Entry points (web service, win-desktop, test fixtures) <strong>must call <a class="xref" href="../api/Hi.MachiningProcs.LocalProjectService.html#Hi_MachiningProcs_LocalProjectService_Reg_">Reg</a> once at startup before any project XML is deserialized</strong> — registration no longer happens by accident when the type is first touched. See <a class="xref" href="../technique/api-foundations/xml-io.html">XML IO</a>.</li>
<li>Replace implicit XFactory registration (private <code>static &lt;ClassName&gt;()</code> constructors + <code>_ = X.XName</code> wake-up touches) with explicit <code>public static void Reg(XFactory factory = null)</code> methods across ~270 classes. <a class="xref" href="../api/Hi.Common.XmlUtils.XFactory.html">XFactory</a> becomes an instance class with a process-wide <code>Default</code> singleton; <code>Generators</code> is renamed from <code>Regs</code> and now an instance property; the delegate type is renamed <code>XGeneratorDelegate</code> from <code>GenByXElementDelegate</code>. Composite types chain <code>X.Reg(factory)</code> on dependents in place of the old wake-up touches; multi-name (legacy alias) registrations keep the current XName first and group aliases under a <code>//legacy aliases</code> comment. Entry points (web service, test fixtures) <strong>must call <a class="xref" href="../api/Hi.MachiningProcs.LocalProjectService.html#Hi_MachiningProcs_LocalProjectService_Reg_">Reg</a> once at startup before any project XML is deserialized</strong> — registration no longer happens by accident when the type is first touched. See <a class="xref" href="../technique/api-foundations/xml-io.html">XML IO</a>.</li>
</ul>
<h2 id="hinc-packages-version-31171">HiNc Packages Version 3.1.171</h2>
<ul>
@@ -323,6 +323,24 @@ geometry's true bounds — instead of meshing, and <code>GeomCombination</code>
contributes nothing to a bounds query; generate the mesh yourself if you need its true extent.
<code>MillingCutter</code>'s cutter-height bookkeeping likewise reads the profile's ZR contour and the
upper beam's box instead of meshing both on every cache clear.</li>
<li><strong>The web application's Legacy-Controller page</strong><code>HiNC-2025-webservice</code> removes the page the
Page menu's third group opened, at <code>/controller/&lt;tab&gt;</code>, on 2026-09-11 (the 3.2 line). It edited
<a class="xref" href="../../api/Hi.Numerical.HardNcEnv.html">HardNcEnv</a> — the project's <a class="xref" href="../../api/Hi.MachiningProcs.MachiningProject.html#Hi_MachiningProcs_MachiningProject_NcEnv">NcEnv</a>,
the HardNc controller model that is deprecating now that
<a class="xref" href="../../api/Hi.MachiningProcs.LocalProjectService.html#Hi_MachiningProcs_LocalProjectService_EnableSoftNcRunner">EnableSoftNcRunner</a> defaults to <code>true</code>. Controller
settings are edited on the General Setup page's Controller branch
(<code>/general-setup?tree=equipment/controller</code>), the SoftNc runner's own face — see
<a href="../../manual/setup/controller.html">Controller</a>. Of the settings only that page could edit, three were
HardNcEnv's alone and retire with it: <code>EnableShortestRotary</code> (the runner honours the program's own
M126 / M127 modal codes), <code>MaxRotarySpeedABC</code> (the runner's rotary ceiling is the rotary rate on
the branch's Rapid Feedrates leaf) and <code>HeidenhainMasterAxisChar</code> (a HardNc parser setting with no
SoftNc counterpart). The fourth, <strong>Align P0</strong> — moving the part so that program zero lands on a
work-coordinate row — is <strong>not offered on the runner path</strong>: the Work Coordinates leaf carries only
<strong>P0</strong> and <strong>M0</strong>, which write the row from the machine position; the part is placed by hand
instead — see <a href="../../manual/setup/program-zero-alignment.html">Program Zero Alignment</a>. Old links keep
working: <code>/controller</code> and anything below it redirects to the Controller branch. Nothing on the
C# side moves — <code>MachiningProject.NcEnv</code> still loads and the <code>/api/Controller/*</code> endpoints stay
mounted, so a host that drives HardNcEnv through the API or a script is unaffected.</li>
</ul>
<h2 id="7-signature-and-shape-changes">7. Signature and shape changes</h2>
<ul>
@@ -393,6 +411,15 @@ names: <code>MachineTool/Table-B1.default</code> and <code>MachineTool/CT-350.de
renamed outright — its <code>.mt</code>, its <code>.general-mech</code> and its STL headers travel with it — and the
duplicated nested STL set inside the CT-350 package is deleted. A project, script or <code>.mt</code> that
refers to a shipped machine-tool package by its earlier path must be repointed at the name above.</li>
<li><strong>The shipped mechanism file takes the canonical extension.</strong> <code>MachineTool/Table-B1.default/Table-B1.general-mech</code>
is now <code>Table-B1.GeneralMechanism</code> — the spelling <code>GeneralMechanism.XName</code> gives and every Save As
has written since the type-name extensions arrived — and the package's <code>Table-B1.mt</code> is repointed at
it. <code>.general-mech</code> stays readable everywhere: the loader dispatches on the XML root element and
never reads the extension, so a hand-authored file keeps its name and loads as before. Only something
that refers to the shipped mechanism by its old file name must be repointed. The rename ships from
HiNc-Resource 3.2.21; 3.2.20 still carries <code>.general-mech</code>, and an admin folder already seeded by it
is re-mirrored — old name deleted, new name copied, <code>Table-B1.mt</code> refreshed — on the first start with
the newer package.</li>
</ul>
</article>
@@ -138,6 +138,10 @@ they are the fastest way to find out what a run actually did.</p>
<td>a G41/G42 block whose compensated path runs against the programmed direction (an inner arc or groove smaller than the offset radius); a real control stops there with an interference alarm (Fanuc PS0041) while the simulation continues on the swapped-side path — on a tool-centre CAM path the radius offset row (D row) must hold the wear only, not the tool radius</td>
</tr>
<tr>
<td><code>RadiusComp--PlaneChangeInRegion</code></td>
<td>a G17/G18/G19 that selects a different plane while G41/G42 is still active (a G40 sharing its block with a plane code included); a real control stops there (Fanuc PS0037 CAN NOT CHANGE PLANE IN CRC) because the corner spanning the change is built from one running axis per plane — cancel with G40 before selecting the new plane</td>
</tr>
<tr>
<td><code>Coord-WorkOffset--AdditionalZero</code></td>
<td>a Fanuc-family additional work coordinate system (<code>G54.1 Pn</code>, also written <code>G54 Pn</code>) was selected but no offset has been entered for it; the program runs on the machine origin</td>
</tr>
@@ -147,6 +147,14 @@ controller does with a table-side rotary program.</li>
<li><strong>The radius-compensation arc transient cache landed on the wrong block.</strong> Any non-motion line
between the corner and the arc orphaned the cache, so the arc lost its leading linear bridge and
began at the corner intersection instead of on the offset arc.</li>
<li><strong>Cutter radius compensation on G18 / G19 ran out of the plane.</strong> Both engines built the
perpendicular as <code>Z × axis</code> whatever plane was selected, so under G18 or G19 the whole offset went
one radius along the plane normal (a <code>G41</code> region in the ZX plane was displaced in Y), every arc of
the region reported <code>Arc-EndpointOffRadius</code>, and the <code>RadiusComp--Interference</code> gate could not fire
there. Both engines now take the perpendicular, the in-plane test for blocks without movement and
the interference gate from the selected plane: the offset lies in the plane, left/right is judged
looking down the plane's positive normal (the same convention that orients G02/G03), and the
diagnostics behave as on G17. G17 programs are unaffected.</li>
<li><strong>The G68.2 tool-axis IK fallback probed the mirrored tool axis.</strong> Both normal-only fallbacks in
<a class="xref" href="../../api/Hi.NcParsers.LogicSyntaxs.IsoG68p2TiltSyntax.html">IsoG68p2TiltSyntax</a> read the transposed third column instead of the
third row. On the no-hint path this only skewed a warning gate, but the explicit A/B/C path seeds