deploy.
This commit is contained in:
@@ -112,9 +112,6 @@ hold across it, and the traps that survive a careful reading of any single file.
|
||||
where a shipped surface depends on it, but the engine's own structure is covered by the generated
|
||||
<a href="../../api/Hi.Machining.html">API Reference</a>, which stays correct in a way a hand-written index could
|
||||
not.</p>
|
||||
<p>Neither is the outgoing Windows desktop client. It takes no new feature work, so a hand-written
|
||||
index of its tree drifts with every flagship change and is read by nobody; the same reasoning
|
||||
retired the page-by-page map of its files.</p>
|
||||
<h2 id="see-also">See Also</h2>
|
||||
<ul>
|
||||
<li><a class="xref" href="../index.html">HiNC App Anatomy</a> — the section index, and the surface-keyed way in</li>
|
||||
|
||||
@@ -259,9 +259,15 @@ copy-paste for indexed objects. Documented in
|
||||
<a class="xref" href="../widget/mat4d-control.html">Mat4dControl Component</a>.</li>
|
||||
</ul>
|
||||
<h2 id="controller-and-demo">Controller and Demo</h2>
|
||||
<p><code>Controller/</code> is the single-file surface behind the legacy controller page. It has a successor in
|
||||
<code>Mech/SoftNcRunnerController.cs</code>, whose own doc comment says so, but <strong>both are live</strong> — the legacy
|
||||
page has not been removed. Documented in <a class="xref" href="../legacy-controller.html">Legacy Controller</a>.</p>
|
||||
<p><code>Controller/</code> is the single-file surface over the legacy HardNcEnv model, <code>MachiningProject.NcEnv</code>.
|
||||
The Legacy Controller page that drove it was removed on 2026-09-11, but the controller is still
|
||||
mounted: its routes edit the legacy tables, a different store from the runner tables that
|
||||
<code>Mech/SoftNcRunnerController.cs</code> — its successor, as that file's own doc comment says — edits. The
|
||||
successor covers the brand, the axis limits and rapid feedrates, the tooling time, the work
|
||||
coordinates, the datum tables and the tool offsets, but not every route — among them the work-coordinate Align
|
||||
P0 pair, the shortest-rotary toggle, the per-axis max rotary speed and the Heidenhain master-axis
|
||||
character have no soft-runner endpoint. Only <code>GET cnc-brand</code> still has a client — the Execution
|
||||
tool bar's Heidenhain Coordinate gate. Documented in <a class="xref" href="../legacy-controller-settings.html">Legacy Controller Model (HardNcEnv)</a>.</p>
|
||||
<p><code>Demo/</code> is customer-facing sample code — a custom colour guide and a per-step optimization sweep —
|
||||
compiled into the assembly with no call site in the running application. Read it as an example of
|
||||
how to extend the engine, not as part of the shipped behaviour.</p>
|
||||
|
||||
@@ -95,8 +95,8 @@ out where they occur.</p>
|
||||
<h2 id="the-one-thing-to-know-first">The One Thing to Know First</h2>
|
||||
<p><code>components/</code> is grouped <strong>both ways at the same level</strong>, and that is deliberate rather than untidy:</p>
|
||||
<ul>
|
||||
<li><strong>Page-scoped</strong> — <code>components/controller/</code>, <code>components/execution/</code> and half of <code>components/mech/</code>
|
||||
are chrome for exactly one route.</li>
|
||||
<li><strong>Page-scoped</strong> — <code>components/execution/</code> and half of <code>components/mech/</code> are chrome for exactly
|
||||
one route.</li>
|
||||
<li><strong>Domain-scoped</strong> — <code>components/geom/</code>, <code>components/topo/</code>, <code>components/toolhouse/</code>,
|
||||
<code>components/spindle/</code>, <code>components/workpiece/</code> and <code>components/mission/</code> are pulled in from
|
||||
wherever the domain surfaces, most often the Control Tree.</li>
|
||||
@@ -200,7 +200,7 @@ place” behaviour the tree pages describe. Documented in
|
||||
<a class="xref" href="../platform/session-state.html">Session State</a> for the keep-mounted flag that decides whether a
|
||||
collapse unmounts its content.</li>
|
||||
<li><code>wwwroot-src/src/components/mission/</code>, <code>.../toolhouse/</code>, <code>.../spindle/</code>, <code>.../preference/</code>,
|
||||
<code>.../mech/</code>, <code>.../workpiece/</code> and <code>.../controller/</code> — the domain and page folders named above. The
|
||||
<code>.../mech/</code> and <code>.../workpiece/</code> — the domain and page folders named above. The
|
||||
<code>*Div.vue</code> suffix inside the Tool House folder is a convention carried over from the legacy Blazor
|
||||
components: a Div is an embeddable content fragment with no panel chrome.</li>
|
||||
</ul>
|
||||
|
||||
@@ -153,9 +153,11 @@ can put its own content on a canvas without touching the transport.</p>
|
||||
Execution displayee to it</li>
|
||||
</ul>
|
||||
<p>Six further controllers bind content the same way — the STL preview, the Tool House, the General
|
||||
Setup equipment, the machine tool, the Mech Builder general mechanism and the Controller page —
|
||||
each with its own route and its own displayee, all reaching the engine through the same connection
|
||||
ID.</p>
|
||||
Setup equipment, the machine tool, the Mech Builder general mechanism and the legacy HardNcEnv
|
||||
controller — each with its own route, all reaching the engine through the same connection ID. The
|
||||
first five bind a displayee of their own; the last binds the shared Execution displayee, and it has
|
||||
had no caller since the Legacy Controller page was removed on 2026-09-11 — the route is still
|
||||
mounted, but no canvas in the SPA initializes against it.</p>
|
||||
<h2 id="key-points">Key Points</h2>
|
||||
<ul>
|
||||
<li>Every canvas data-stream operation is indexed by the connection ID.</li>
|
||||
@@ -186,8 +188,9 @@ Execution displayee to the engine named by the connection ID.</li>
|
||||
(<code>api/mech/machine-tool/display</code>).</li>
|
||||
<li><code>Mech/MechBuilder/GeneralMechanismDisplayController.cs</code> — the Mech Builder canvas binding
|
||||
(<code>api/general-mechanism/display</code>).</li>
|
||||
<li><code>Controller/ControllerController.cs</code> — the Controller page's canvas binding
|
||||
(<code>initialize-display/{connectionId}</code>).</li>
|
||||
<li><code>Controller/ControllerController.cs</code> — the legacy controller surface's canvas binding
|
||||
(<code>initialize-display/{connectionId}</code>), which assigns the shared Execution displayee; still mounted,
|
||||
with no SPA caller since the Legacy Controller page was removed.</li>
|
||||
</ul>
|
||||
<h3 id="web-page-application-source-code-path">Web Page Application Source Code Path</h3>
|
||||
<ul>
|
||||
|
||||
@@ -181,8 +181,8 @@ rendering flags and the anchor labels.</li>
|
||||
control-tree node names and the mission command kinds.</li>
|
||||
<li><code>wwwroot-src/src/i18n/zh-Hant/mission.ts</code> — the PreSetting command fields, including Machining
|
||||
Resolution and the meshed-geometry file picker.</li>
|
||||
<li><code>wwwroot-src/src/i18n/zh-Hant/controller.ts</code> and <code>wwwroot-src/src/i18n/zh-Hant/softNc.ts</code> — the
|
||||
Datum Preset tab, its table, and the runner's datum-preset row.</li>
|
||||
<li><code>wwwroot-src/src/i18n/zh-Hant/softNc.ts</code> — the runner's Datum Preset and Datum Shift rows and the
|
||||
datum table behind them.</li>
|
||||
<li><code>wwwroot-src/src/i18n/zh-Hant/execution.ts</code> — the Execution rendering flags, where Meshed
|
||||
Geometry and Fixture appear together.</li>
|
||||
<li><code>wwwroot-src/src/i18n/index.ts</code> — <code>createI18n()</code>, <code>applyLocale()</code> and <code>SUPPORTED_LOCALES</code>, the
|
||||
|
||||
+1
-1
@@ -103,7 +103,7 @@
|
||||
<li><strong>Coordinate</strong> — Program Zero, ISO Coordinate, Heidenhain Coordinate</li>
|
||||
<li><strong>Display Aids</strong> — Dimension Bar, Color Scale Bar</li>
|
||||
</ul>
|
||||
<p>The ClStrip flag is not offered here; the <code>Tool Path</code> button owns it. Heidenhain Coordinate appears only when <a class="xref" href="../../api/Hi.MachiningProcs.MachiningProject.html">MachiningProject</a>.<a class="xref" href="../../api/Hi.MachiningProcs.MachiningProject.html#Hi_MachiningProcs_MachiningProject_NcEnv">NcEnv</a>.<a class="xref" href="../../api/Hi.Numerical.HardNcEnv.html#Hi_Numerical_HardNcEnv_CncBrand">CncBrand</a> is <a class="xref" href="../../api/Hi.Numerical.CncBrand.html#Hi_Numerical_CncBrand_Heidenhain">Heidenhain</a>. The menu is a shared component because other screens use it too — see the <a class="xref" href="../legacy-controller.html">Legacy Controller Page</a>.</p>
|
||||
<p>The ClStrip flag is not offered here; the <code>Tool Path</code> button owns it. Heidenhain Coordinate appears only when <a class="xref" href="../../api/Hi.MachiningProcs.MachiningProject.html">MachiningProject</a>.<a class="xref" href="../../api/Hi.MachiningProcs.MachiningProject.html#Hi_MachiningProcs_MachiningProject_NcEnv">NcEnv</a>.<a class="xref" href="../../api/Hi.Numerical.HardNcEnv.html#Hi_Numerical_HardNcEnv_CncBrand">CncBrand</a> is <a class="xref" href="../../api/Hi.Numerical.CncBrand.html#Hi_Numerical_CncBrand_Heidenhain">Heidenhain</a> — the tool bar reads that value through <code>GET /api/Controller/cnc-brand</code>, and the Execution displayee applies the same test before it draws the Heidenhain coordinate, so the row is offered exactly when the scene can show it. Mind which brand that is: the legacy HardNcEnv model's, loaded with the project, not the runner brand chosen on the General Setup page's Controller branch — switching the runner to Heidenhain does not reveal the row. Since the Legacy Controller page was removed on 2026-09-11 no screen writes the value: it comes from the project's <code>NcEnv</code> element, or from the still-mounted REST face — the <code>PUT</code> half of the same route, or a whole-model swap through <code>POST /api/Controller/update</code>. The menu is a shared component because other canvases use it too — see the <a class="xref" href="../widget/renderingcanvas-tool-bar.html">RenderingCanvas Tool Bar</a>.</p>
|
||||
</li>
|
||||
<li><p><code>Meshed Geom ▾</code> — the workpiece's rendering cache and geometry-diff settings: the <a class="xref" href="graphic-cache-menu.html">Graphic-Cache SubMenu</a> and Diff Visual Radius, with a <code>Diff</code> badge when a difference is present.</p>
|
||||
</li>
|
||||
|
||||
@@ -237,9 +237,9 @@ but with one panel mounted at a time, the change that matters in practice is a p
|
||||
<h2 id="the-table-primitive">The Table Primitive</h2>
|
||||
<p>Where a leaf renders a table it is Quasar's markup table — dense, flat, bordered — with a
|
||||
hand-written header and body and a repeat over the rows. No panel in the branch uses the data-table
|
||||
component, and the four data tables left in the application are the legacy controller tabs this
|
||||
branch supersedes. The practical difference is that these tables have no built-in sort, no pagination
|
||||
and no column menu: what the header says is what the column is.</p>
|
||||
component, and since the legacy controller tabs were removed nothing else in the application does
|
||||
either. The practical difference is that these tables have no built-in sort, no pagination and no
|
||||
column menu: what the header says is what the column is.</p>
|
||||
<p>Key columns are rendered as plain text and cannot be edited: the tool and edge numbers of a <code>$TC_DP</code>
|
||||
row, a tool name, an <code>R</code> number, a <code>#</code> variable number, a datum row index, a native parameter id, and
|
||||
the axis names of every per-axis table, which follow the machining chain rather than the panel. The
|
||||
|
||||
@@ -90,8 +90,9 @@
|
||||
<p>The Controller branch is the SoftNcRunner-native settings face: the controller the project actually
|
||||
parses NC with, edited one tree node at a time. It lives on the General Setup page at
|
||||
<code>/general-setup</code> under the Control-Tree id <code>equipment/controller</code>, and grows two plane stems beneath
|
||||
it — <code>equipment/controller/machine</code> and <code>equipment/controller/program-data</code>. The superseded
|
||||
HardNcEnv surface still ships as a route of its own at <code>/controller</code>, and edits a different model.</p>
|
||||
it — <code>equipment/controller/machine</code> and <code>equipment/controller/program-data</code>. A bookmark to the
|
||||
retired <code>/controller</code> address, where the Legacy Controller page used to edit the deprecating HardNcEnv
|
||||
model instead of the runner, redirects to this branch root.</p>
|
||||
<div class="IMPORTANT">
|
||||
<h5>Important</h5>
|
||||
<p>Anatomy makes no claim that these ids are stable across versions. See
|
||||
@@ -230,12 +231,6 @@ switch. No panel refreshes it, so an edit that empties a table changes neither t
|
||||
branch until one of those happens.</p>
|
||||
<p>Both structural writes are refused while an NC program is playing: installing a runner and switching
|
||||
brand each answer a conflict rather than swapping the parser under a running session.</p>
|
||||
<h2 id="the-superseded-route">The Superseded Route</h2>
|
||||
<p>The legacy controller page still ships at <code>/controller/:tab?</code> and is reached from the app menu bar's
|
||||
<strong>Page → Legacy-Controller</strong> entry. It edits <a class="xref" href="../../../api/Hi.Numerical.HardNcEnv.html">HardNcEnv</a> through its own REST
|
||||
surface, which is a different model from the runner this branch edits — the two are not two views of
|
||||
one object, and an edit on one is invisible to the other. Its anatomy is
|
||||
<a class="xref" href="../../legacy-controller.html">Legacy Controller Page</a>.</p>
|
||||
<h2 id="layout">Layout</h2>
|
||||
<ul>
|
||||
<li><strong>General Setup</strong> Control Tree — the left dock of <code>/general-setup</code>
|
||||
@@ -319,9 +314,8 @@ browser and its extension filter, the expected type it sends with a paste, and t
|
||||
panel listens to.</li>
|
||||
<li><code>wwwroot-src/src/pages/GeneralSetupPage.vue</code> — the route that creates the <code>equipment</code>-scoped tree
|
||||
host this branch is built in.</li>
|
||||
<li><code>wwwroot-src/src/router/routes.ts</code> — the <code>/general-setup</code> route and the still-shipping
|
||||
<code>/controller/:tab?</code> route beside it.</li>
|
||||
<li><code>wwwroot-src/src/components/AppMenuBar.vue</code> — the Page menu entry that reaches the legacy route.</li>
|
||||
<li><code>wwwroot-src/src/router/routes.ts</code> — the <code>/general-setup</code> route, and the redirect stub that sends a
|
||||
bookmarked <code>/controller</code> address to this branch root.</li>
|
||||
<li><code>wwwroot-src/src/i18n/en/softNc.ts</code> — every label, group intro, hint and empty string this branch
|
||||
renders.</li>
|
||||
<li><code>wwwroot-src/src/i18n/en/tree.ts</code> — the <strong>Controller</strong> root label.</li>
|
||||
@@ -378,10 +372,8 @@ settings, one page per editor</li>
|
||||
ownership rules that keep them on the project</li>
|
||||
<li><a class="xref" href="../index.html">General Setup Page</a> — the page that hosts this branch, and the equipment items beside it</li>
|
||||
<li><a class="xref" href="../../platform/control-tree.html">Control Tree</a> — the engine that builds, rebuilds and selects this branch</li>
|
||||
<li><a class="xref" href="../../legacy-controller.html">Legacy Controller Page</a> — the superseded HardNcEnv route this branch replaces, still shipped
|
||||
at <code>/controller</code></li>
|
||||
<li><a class="xref" href="../../legacy-controller-settings.html">Legacy Controller Settings</a> — the model that route edits, what this branch shares with
|
||||
it, and the three settings it holds alone</li>
|
||||
<li><a class="xref" href="../../legacy-controller-settings.html">Legacy Controller Model (HardNcEnv)</a> — the deprecating HardNcEnv model the project still carries
|
||||
beside this runner, what this branch shares with it, and the three settings that retire with it</li>
|
||||
</ul>
|
||||
|
||||
</article>
|
||||
|
||||
-3
@@ -308,9 +308,6 @@ row as seeded. The legacy work-coordinate table is replayed first, through the s
|
||||
aliases onto preset rows 1 through 6, so where the two overlap the explicit datum copy is what
|
||||
stands.</li>
|
||||
</ul>
|
||||
<p>The superseded <code>/controller</code> route also carries datum preset and datum shift surfaces, over the
|
||||
separate environment model rather than over the runner — an edit made there does not reach the table
|
||||
on this page. That route's own anatomy is <a class="xref" href="../../../legacy-controller.html">Legacy Controller Page</a>.</p>
|
||||
<h2 id="layout">Layout</h2>
|
||||
<ul>
|
||||
<li><strong>General Setup</strong> Control Tree — the left dock of <code>/general-setup</code>
|
||||
|
||||
@@ -110,8 +110,9 @@ application.</p>
|
||||
<li><a href="controller/index.html">Controller</a> — The SoftNcRunner-native controller branch: its two planes, the brand matrix behind which nodes appear at all, and the contract every leaf edits by</li>
|
||||
<li><a href="hidden-controllers.html">Hidden Controller Branches</a> — The two runner-suit nodes a fresh installation never builds, the device-local checkboxes that reveal them, and the second kind of invisibility a link cannot undo</li>
|
||||
</ul>
|
||||
<p>The superseded <a class="xref" href="../legacy-controller.html">Legacy Controller</a> screen at its own route is a separate
|
||||
surface, editing a different model from the branch above.</p>
|
||||
<p>A bookmark to the retired <code>/controller</code> address — the Legacy Controller page, which edited the
|
||||
deprecating HardNcEnv model rather than the runner — now redirects here and lands on the Controller
|
||||
branch.</p>
|
||||
<h2 id="see-also">See Also</h2>
|
||||
<ul>
|
||||
<li><a class="xref" href="../execution/index.html">Execution Page</a> — the other Control-Tree page, and the one this was split out of</li>
|
||||
@@ -120,8 +121,7 @@ surface, editing a different model from the branch above.</p>
|
||||
<li><a class="xref" href="../platform/control-tree.html">Control Tree</a> — the engine behind this page's tree: how a branch is built, rebuilt and selected</li>
|
||||
<li><a href="controller/index.html">Controller Branch</a> — the branch this page hosts whose node set changes with the controller brand</li>
|
||||
<li><a href="hidden-controllers.html">Hidden Controller Branches</a> — the two equipment nodes this page withholds until a preference or a link asks for them</li>
|
||||
<li><a class="xref" href="../legacy-controller.html">Legacy Controller</a> — the superseded controller screen at its own route: its seven tabs, how an edit commits, and its viewer</li>
|
||||
<li><a class="xref" href="../legacy-controller-settings.html">Legacy Controller Settings</a> — the model that screen edits, and the three settings the equipment tree has no editor for</li>
|
||||
<li><a class="xref" href="../legacy-controller-settings.html">Legacy Controller Model (HardNcEnv)</a> — the deprecating HardNcEnv model the project still carries beside the runner, what it shares with the Controller branch, and the three settings that retire with it rather than gaining an editor in the equipment tree</li>
|
||||
</ul>
|
||||
|
||||
</article>
|
||||
|
||||
@@ -131,10 +131,6 @@ regroup adds a migration hop. The ids themselves have moved repeatedly.</p>
|
||||
<td><a href="tool-house/index.html">Tool House Page</a></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>/controller/:tab?</code></td>
|
||||
<td><a href="legacy-controller.html">Legacy Controller</a></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>/util/file-explorer</code>, <code>/util/mech-builder</code></td>
|
||||
<td><a href="util/index.html">Utility Pages</a></td>
|
||||
</tr>
|
||||
@@ -174,23 +170,16 @@ regroup adds a migration hop. The ids themselves have moved repeatedly.</p>
|
||||
<li><a href="execution/index.html">Execution Page</a> — The run cockpit: its tool bars, the step column, the charts, and the Mission branch it hosts</li>
|
||||
<li><a href="general-setup/index.html">General Setup Page</a> — The equipment Control Tree: the machine, the spindle envelope, the scene, the fixture, the workpiece and the controller branch</li>
|
||||
<li><a href="tool-house/index.html">Tool House Page</a> — The tool library and the per-tool editor tabs, cutter and holder</li>
|
||||
<li><a href="legacy-controller.html">Legacy Controller</a> — The superseded HardNcEnv controller surface and its REST implementation</li>
|
||||
<li><a href="legacy-controller-settings.html">Legacy Controller Settings</a> — The HardNcEnv model that surface edits: the three settings it owns alone, what it shares with the Controller branch, and the engine files behind both</li>
|
||||
<li><a href="legacy-controller-settings.html">Legacy Controller Model (HardNcEnv)</a> — The deprecating HardNc controller model the project still carries beside the runner: what the live pipeline still reads from it, the three settings that retire with it and the Align P0 action the runner path does not offer, what the Controller branch edits a runner-side copy of, and the engine files behind both</li>
|
||||
<li><a href="util/index.html">Utility Pages</a> — The two <code>/util/</code> routes: the File Explorer and the Mechanism Builder</li>
|
||||
<li><a href="by-source/index.html">By Source Directory</a> — The same knowledge keyed on the source tree instead of the screen: one directory index per half of the flagship</li>
|
||||
</ul>
|
||||
<h2 id="the-two-codebases">The Two Codebases</h2>
|
||||
<p>A page's <em>Source Code Path</em> section lists the files that implement it in the flagship web service.
|
||||
The desktop client's counterparts are not listed at all: it takes no new feature work, and a
|
||||
hand-maintained map of its files went stale faster than anyone read it. The two codebases are not
|
||||
peers.</p>
|
||||
<h2 id="the-codebase">The Codebase</h2>
|
||||
<p>A page's <em>Source Code Path</em> section lists the files that implement it in the flagship web service,
|
||||
which is the only application codebase Anatomy documents.</p>
|
||||
<p><strong>HiNC-2025-webservice</strong> is the flagship — a Quasar SPA (Vue 3 + TypeScript + Pinia) served by
|
||||
ASP.NET Core, and the only target for new feature work. Repository:
|
||||
<a href="https://superhightech-gitea.webredirect.org/HiAPI/HiNC-2025-webservice.git">HiNC-2025-webservice.git</a></p>
|
||||
<p><strong>HiNC-2025-win-desktop</strong> is the outgoing WPF client, kept here only so a reader familiar with the
|
||||
desktop UI can find the equivalent web-service component. Do not start new work against it.
|
||||
Repository:
|
||||
<a href="https://superhightech-gitea.webredirect.org/HiNC-Deploy/HiNC-2025-win-desktop.git">HiNC-2025-win-desktop.git</a></p>
|
||||
<div class="TIP">
|
||||
<h5>Tip</h5>
|
||||
<p>The host process, its configuration and the address it listens on are documented in
|
||||
@@ -204,8 +193,7 @@ Control Tree, its <code>?tree=</code> id. Make no claim that the id is stable.</
|
||||
<li><strong>Key Model</strong> — the backing HiAPI types, as <code><xref:></code> so the API reference is one click away.</li>
|
||||
<li><strong>Source Code Path</strong> — the implementing files <strong>in the web service</strong>. Backtick every path, with
|
||||
its extension: <code>tools/check-source-paths.ps1</code> resolves a full path against the source tree and a
|
||||
bare file name by its base name, and refuses an entry carrying no backticks at all. Do not add
|
||||
desktop-client files.</li>
|
||||
bare file name by its base name, and refuses an entry carrying no backticks at all.</li>
|
||||
<li><strong><code>## See Also</code></strong> — mandatory, and audited for reciprocity. An entry is not landed until the
|
||||
target links back.
|
||||
Anatomy is <strong>authoritative</strong> on component and source facts: when Manual and Anatomy disagree,
|
||||
|
||||
@@ -2,9 +2,9 @@
|
||||
<html>
|
||||
<head>
|
||||
<meta charset="utf-8">
|
||||
<title>Legacy Controller Settings | HiAPI-C# 2025 </title>
|
||||
<title>Legacy Controller Model (HardNcEnv) | HiAPI-C# 2025 </title>
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
<meta name="title" content="Legacy Controller Settings | HiAPI-C# 2025 ">
|
||||
<meta name="title" content="Legacy Controller Model (HardNcEnv) | HiAPI-C# 2025 ">
|
||||
|
||||
|
||||
<link rel="icon" href="../img/HiAPI.favicon.ico">
|
||||
@@ -85,15 +85,23 @@
|
||||
</div>
|
||||
|
||||
<article data-uid="Anatomy-LegacyControllerSettings">
|
||||
<h1 id="legacy-controller-settings">Legacy Controller Settings</h1>
|
||||
<h1 id="legacy-controller-model-hardncenv">Legacy Controller Model (HardNcEnv)</h1>
|
||||
|
||||
<p><a class="xref" href="../api/Hi.Numerical.HardNcEnv.html">HardNcEnv</a> is the model the Legacy Controller page at <code>/controller/:tab?</code> edits,
|
||||
and this page is what that model holds: how it stands to the runner the rest of the application
|
||||
configures, the three settings this screen owns alone, the ones it shares with the Controller Branch
|
||||
on General Setup, and the one marker class both faces draw a work coordinate with. The screen itself
|
||||
— its seven tabs, how an edit commits, its object-management chain, its viewer and its layout — is
|
||||
<a class="xref" href="legacy-controller.html">Legacy Controller Page</a>.</p>
|
||||
<h2 id="the-model-it-edits-and-the-one-it-does-not">The Model It Edits, and the One It Does Not</h2>
|
||||
<p><a class="xref" href="../api/Hi.Numerical.HardNcEnv.html">HardNcEnv</a> is the HardNc controller model: the one the project still carries as
|
||||
<code>MachiningProject.NcEnv</code> and serializes as its <code>NcEnv</code> element, and the one the deprecating HardNc
|
||||
pipeline plays. It is a model with no screen. The Legacy-Controller page at <code>/controller/:tab?</code> that
|
||||
edited it was removed on 2026-09-11 — <code>/controller/…</code> now redirects to
|
||||
<code>/general-setup?tree=equipment/controller</code>, following the route file's convention for retired
|
||||
pages — and controller settings are edited on the General Setup page's
|
||||
<a class="xref" href="general-setup/controller/index.html">Controller Branch</a>, the settings face of the SoftNc runner, which is the
|
||||
live pipeline. What survives of the legacy face is its REST implementation,
|
||||
<code>Controller/ControllerController.cs</code>, still mounted under <code>/api/Controller/*</code>, and its typed client
|
||||
<code>wwwroot-src/src/api/controller.ts</code>, kept as those endpoints' only client; one wrapper in it,
|
||||
<code>getCncBrand</code>, is still called from a live component. This page is what the model holds: how it
|
||||
stands to the runner, what the live pipeline still reads from it, the settings that retire with it,
|
||||
the ones the branch edits a runner-side copy of, and the one marker class both stores draw a work
|
||||
coordinate with.</p>
|
||||
<h2 id="the-model-and-the-runner-beside-it">The Model, and the Runner Beside It</h2>
|
||||
<p>The project carries both models side by side and serializes both. <a class="xref" href="../api/Hi.Numerical.HardNcEnv.html">HardNcEnv</a> is
|
||||
loaded from the project's own <code>NcEnv</code> element unconditionally; <a class="xref" href="../api/Hi.NcParsers.NcRunnerSuit.html">NcRunnerSuit</a> — the
|
||||
runner plus the project's per-case dependency list — is read from its own nested element. The legacy
|
||||
@@ -101,121 +109,149 @@ element is a <em>fallback source</em> for the suit rather than a shared store: a
|
||||
no runner element derives one from the legacy element at load time, and from then on the two drift
|
||||
apart, because every later edit lands on one of them alone.</p>
|
||||
<p>The legacy model is still read at play time. The legacy NC runner is constructed over a delegate
|
||||
onto the project's <code>NcEnv</code>, so installing a replacement through the screen's ⋮ menu propagates
|
||||
onto the project's <code>NcEnv</code>, so a replacement installed through the <code>update</code> endpoint — the removed
|
||||
page's object-management chain was its caller, and nothing in the SPA calls it now — propagates
|
||||
without rewiring, and a project-level switch selects which of the two pipelines plays. That switch
|
||||
defaults to the SoftNc pipeline and no screen in the web application changes it; it is a scripting
|
||||
property, <a class="xref" href="../api/Hi.MachiningProcs.SessionShell.html#Hi_MachiningProcs_SessionShell_EnableSoftNcRunner_">EnableSoftNcRunner</a><small>(API)</small>. The legacy
|
||||
NC optimisation route is the other live reader: it is taken whenever the switch is off or the
|
||||
session holds no played SoftNc layers, and it is handed <code>MachiningProject.NcEnv</code> directly.</p>
|
||||
<h2 id="what-only-this-screen-edits">What Only This Screen Edits</h2>
|
||||
<p>Three settings on this screen have no editor anywhere else in the web application — neither on the
|
||||
branch, nor on any other page.</p>
|
||||
<h3 id="align-p0-and-its-undo-history">Align P0, and its undo history</h3>
|
||||
<p>The Coordinate Table tab — that is the tab button's label; <strong>ISO Coordinate Table</strong> is the heading
|
||||
over the panel it opens — carries a third row action beside <strong>P0</strong> and <strong>M0</strong>: <strong>Align P0</strong>, titled
|
||||
<em>"Move workpiece+fixture so ProgramZero coincides with this ISO entry (mutates
|
||||
Fixture.GeomToTableTransformer)"</em>. It does not write the coordinate — it writes the <strong>fixture's
|
||||
geometry-to-table transformer</strong>, moving the workpiece and fixture so that program zero lands on the
|
||||
offset the row holds. The write goes to the authored setup equipment and reports the edit, so the
|
||||
runtime face follows at the next rebuild. The branch's Work Coordinates leaf carries P0 and M0 and
|
||||
no alignment.</p>
|
||||
<p>The endpoint keeps no undo slot. It answers with the assigned translation plus the transformer as it
|
||||
stood <strong>before</strong> and <strong>after</strong> the write, both serialized as XML, and the tab holds the history
|
||||
itself: <strong>Undo Align</strong> and <strong>Redo Align</strong> buttons over two component-local stacks, the undo stack
|
||||
capped at 32 entries and the oldest dropped past it. A third button sits beside them, <strong>Show on
|
||||
Display</strong>, which belongs to the viewer rather than to the history: it is a bound toggle over the
|
||||
<code>IsoCoordinate</code> rendering flag, carrying a <code>visibility</code> / <code>visibility_off</code> icon and writing through
|
||||
the same flag endpoint the Scene dropdown writes. The two datum tabs carry the same button over
|
||||
<code>HeidenhainCoordinate</code>. Each step posts a stashed snapshot back to a stateless revert endpoint,
|
||||
which parses it and assigns the result as the fixture's transformer. Both stacks are cleared
|
||||
whenever the tab's has-a-project prop changes, and the snapshot the component believes is current is
|
||||
only what it last saw — a transformer changed from another surface is overwritten wholesale by the
|
||||
next undo or redo rather than merged.</p>
|
||||
<p>The engine exposes the same operation as a script call,
|
||||
<a class="xref" href="../api/Hi.MachiningProcs.SessionShell.html#Hi_MachiningProcs_SessionShell_AlignWorkpieceProgramZeroToIso_">AlignWorkpieceProgramZeroToIso</a><small>(API)</small>; the
|
||||
history is the screen's own.</p>
|
||||
<h2 id="what-the-live-pipeline-still-reads-from-it">What the Live Pipeline Still Reads From It</h2>
|
||||
<p>Selecting the SoftNc pipeline does not silence the legacy model. Four reads still land on it with
|
||||
the switch on, so a value that only the legacy endpoints or the project XML can change still shows
|
||||
up on a runner play.</p>
|
||||
<ul>
|
||||
<li><strong>Stroke limits, as a fallback.</strong> The per-step stroke check reads the runner's
|
||||
<a class="xref" href="../api/Hi.NcParsers.Dependencys.IStrokeLimitConfig.html">IStrokeLimitConfig</a> when the switch is on and one is present, and
|
||||
falls back to the legacy stroke boxes otherwise — a CSV or NX-CL suit carries no stroke config, so
|
||||
a play on those falls through to the boxes. The pre-play audit that warns of an unlimited linear
|
||||
axis reads both sources end by end, the runner's first and the legacy box behind it, and stays
|
||||
silent for an axis either source guards.</li>
|
||||
<li><strong>The home position, as a fallback.</strong> The chain is re-homed from the runner's home config; the
|
||||
legacy <code>HomeMc</code> fills in only when no linear axis was ever configured there.</li>
|
||||
<li><strong>The Execution canvas's coordinate markers.</strong> The <code>IsoCoordinate</code> and <code>HeidenhainCoordinate</code>
|
||||
rendering flags on the Execution page draw from the legacy tables — see
|
||||
<a href="#two-faces-of-a-work-coordinate">Two Faces of a Work Coordinate</a>.</li>
|
||||
<li><strong>The Execution tool bar's brand.</strong> The Scene dropdown offers its Heidenhain-coordinate entry only
|
||||
while the brand is Heidenhain, and the brand it asks for is the legacy model's, through
|
||||
<code>getCncBrand</code> — the one wrapper in <code>wwwroot-src/src/api/controller.ts</code> a live component still
|
||||
calls.</li>
|
||||
</ul>
|
||||
<p>The kinematics solver the service builds is mirrored onto <code>NcEnv.XyzabcSolver</code> as well, but that
|
||||
slot is wiring the service maintains rather than a setting, and it is never serialized.</p>
|
||||
<h2 id="settings-that-retire-with-the-model">Settings That Retire With the Model</h2>
|
||||
<p>Four controls had no editor anywhere in the web application but the removed screen. None of them
|
||||
gained one on the branch: three are legacy-only settings and retire with the model, and the fourth is an
|
||||
action the runner path does not offer. Every one keeps its endpoint under <code>/api/Controller/*</code>, so
|
||||
the value can still be read and written over REST or in the project XML — there is just no UI for
|
||||
it.</p>
|
||||
<h3 id="align-p0--not-offered-on-the-runner-path">Align P0 — not offered on the runner path</h3>
|
||||
<p>The removed Coordinate Table tab carried a third row action beside <strong>P0</strong> and <strong>M0</strong>: <strong>Align P0</strong>,
|
||||
which moves the <em>part</em> so that program zero lands on the offset the row holds — the reproducing
|
||||
direction, <em>program zero onto the work offset</em> in the manual's terms. It did not write the
|
||||
coordinate; it wrote the <strong>fixture's geometry-to-table transformer</strong>, so the workpiece and fixture
|
||||
moved together and the runtime face followed at the next rebuild. The branch's Work Coordinates
|
||||
leaf carries P0 and M0 only, which write the row <em>from</em> the machine position — the opposite
|
||||
direction — and no alignment. The operation is not offered on the runner path.</p>
|
||||
<p>The tab's undo history — <strong>Undo Align</strong> and <strong>Redo Align</strong> over two component-local stacks, the
|
||||
undo stack capped at 32 entries — was the component's own and went with it; the endpoint never kept
|
||||
an undo slot. It still answers with the assigned translation plus the transformer as it stood
|
||||
<strong>before</strong> and <strong>after</strong> the write, both serialized as XML, and the stateless revert endpoint still
|
||||
parses such a snapshot and assigns it as the fixture's transformer; nothing in the SPA posts to
|
||||
either now. The engine exposes the same operation as a script call,
|
||||
<a class="xref" href="../api/Hi.MachiningProcs.SessionShell.html#Hi_MachiningProcs_SessionShell_AlignWorkpieceProgramZeroToIso_">AlignWorkpieceProgramZeroToIso</a><small>(API)</small>, which
|
||||
looks the row up in the legacy model's ISO coordinate table — an API for a script, not a
|
||||
replacement for the removed control.</p>
|
||||
<h3 id="enable-shortest-rotary-path">Enable Shortest Rotary Path</h3>
|
||||
<p>The <strong>Config</strong> tab's single toggle writes <a class="xref" href="../api/Hi.Numerical.HardNcEnv.html#Hi_Numerical_HardNcEnv_EnableShortestRotary">EnableShortestRotary</a>, which
|
||||
constructs <code>true</code>. Its banner reads <em>"<strong>Shortest Rotary Path:</strong> optimises rotary axis motion to use
|
||||
the shortest angular distance between positions."</em> On the legacy pipeline the flag gates one step:
|
||||
each rotary axis of a block is cycled into the ±180° window around the previous block's value. The
|
||||
toggle is narrower than it reads, because that same cycle is applied unconditionally on
|
||||
<p><a class="xref" href="../api/Hi.Numerical.HardNcEnv.html#Hi_Numerical_HardNcEnv_EnableShortestRotary">EnableShortestRotary</a> constructs <code>true</code>, and its only editor was the
|
||||
removed Config tab's single toggle. On the legacy pipeline the flag gates one step: each rotary
|
||||
axis of a block is cycled into the ±180° window around the previous block's value. The flag is
|
||||
narrower than its name, because that same cycle is applied unconditionally on
|
||||
<a class="xref" href="../api/Hi.Numerical.CncBrand.html#Hi_Numerical_CncBrand_Heidenhain">Heidenhain</a> — the brand branch runs it before the flag is consulted, so
|
||||
clearing the box changes nothing there.</p>
|
||||
clearing it changes nothing there.</p>
|
||||
<p>The runner's dependency layer declares no counterpart: no brand parameter table, no generic config
|
||||
and no branch leaf carries a shortest-rotary switch. The nearest thing the runner pipeline has is the
|
||||
Heidenhain <code>M126</code> / <code>M127</code> pair, which is read from the program text rather than from any setting.</p>
|
||||
and no branch leaf carries a shortest-rotary switch. What the runner pipeline has instead is the
|
||||
Heidenhain <code>M126</code> / <code>M127</code> pair, modal codes read from the program text rather than from any
|
||||
setting.</p>
|
||||
<h3 id="max-rotary-speed-per-axis">Max rotary speed per axis</h3>
|
||||
<p><a class="xref" href="../api/Hi.Numerical.HardNcEnv.html#Hi_Numerical_HardNcEnv_MaxRotarySpeedABC_radds">MaxRotarySpeedABC_radds</a> is the per-axis rotary speed ceiling the
|
||||
HardNc pipeline clamps feed and cycle time against; its editor was the removed Machine tab's
|
||||
<strong>Max Speed (rpm)</strong> column. On the runner pipeline the ceiling is not a setting of its own: the
|
||||
polar feed clamp reads it from the per-axis rapid-feedrate bucket,
|
||||
<a class="xref" href="../api/Hi.NcParsers.Dependencys.IRapidFeedrateConfig.html">IRapidFeedrateConfig</a>, and the legacy import funnels this field into
|
||||
that bucket at rpm × 360 deg/min, so the branch's Rapid Feedrates leaf edits the runner-side
|
||||
number. The legacy field itself retires with the model.</p>
|
||||
<h3 id="heidenhain-master-axis-character">Heidenhain master-axis character</h3>
|
||||
<p>The <strong>Brand</strong> tab grows a second card while the brand is Heidenhain, holding one select over <code>A</code>,
|
||||
<code>B</code>, <code>C</code> labelled <strong>Master-axis character</strong>. It writes
|
||||
<a class="xref" href="../api/Hi.Numerical.HardNcEnv.html#Hi_Numerical_HardNcEnv_HeidenhainMasterAxisChar">HeidenhainMasterAxisChar</a>, a character face over the integer axis
|
||||
direction the <code>PLANE … SEQ</code> solution family is resolved against. Reads are normalised: anything that
|
||||
is not <code>B</code> or <code>C</code> after trimming and upper-casing becomes <code>A</code>. On the runner pipeline the master
|
||||
<p><a class="xref" href="../api/Hi.Numerical.HardNcEnv.html#Hi_Numerical_HardNcEnv_HeidenhainMasterAxisChar">HeidenhainMasterAxisChar</a> is a character face over the integer axis
|
||||
direction the <code>PLANE … SEQ</code> solution family is resolved against; its editor was a second card the
|
||||
removed Brand tab grew while the brand was Heidenhain, one select over <code>A</code>, <code>B</code>, <code>C</code>. The setter
|
||||
takes only <code>A</code>, <code>B</code> or <code>C</code> and throws on anything else; the <code>PUT</code> endpoint upper-cases the first
|
||||
character it is sent and answers 400 to anything but those three. On the runner pipeline the master
|
||||
rotary is <strong>derived rather than configured</strong> — it is the first declared rotary axis — so the branch
|
||||
has nothing to expose and no leaf for it.</p>
|
||||
<h2 id="what-it-shares-with-the-branch">What It Shares With the Branch</h2>
|
||||
<p>Naming what is <em>not</em> exclusive matters as much. The CNC brand, the stroke limits, the rapid feed,
|
||||
<h2 id="what-the-branch-edits-a-runner-side-copy-of">What the Branch Edits a Runner-Side Copy Of</h2>
|
||||
<p>Naming what is <em>not</em> legacy-only matters as much. The CNC brand, the stroke limits, the rapid feed,
|
||||
the tool-change time, the tool offset table with its tool-house dependence, the work coordinates
|
||||
with their P0 and M0 actions, and the Heidenhain datum preset and datum shift tables all have
|
||||
editors on the branch — see
|
||||
<a class="xref" href="general-setup/controller/brand-matrix.html">Brand Matrix</a> for which of those leaves each brand grows. The
|
||||
<strong>Max Speed (rpm)</strong> column has a counterpart too: on the runner pipeline the rotary speed ceiling is
|
||||
read from the rapid-feedrate config, and the legacy import funnels this field into it at rpm × 360
|
||||
deg/min, so the branch's Rapid Feedrates leaf edits the runner-side number.</p>
|
||||
<p>One control on this screen writes a value the branch also writes. <strong>Set ideal offset dependent on
|
||||
tool house</strong> is a project-level configuration flag rather than a member of either NC model, and both
|
||||
the Offset Table tab and the branch's Tool Offsets leaf read and write that one flag. The two
|
||||
<em>tables</em> stay separate: this tab's <strong>Refresh from Tool House</strong> recomputes
|
||||
<a class="xref" href="../api/Hi.Numerical.HardNcEnv.html#Hi_Numerical_HardNcEnv_MillingToolOffsetTable">MillingToolOffsetTable</a> from <a class="xref" href="../api/Hi.Machining.MachiningToolHouse.html">MachiningToolHouse</a>,
|
||||
while the branch's refresh recomputes the runner's own tool-offset table.</p>
|
||||
editors on the branch — see <a class="xref" href="general-setup/controller/brand-matrix.html">Brand Matrix</a> for which of those
|
||||
leaves each brand grows. The branch edits the <em>runner's</em> copy of each; the legacy copy in
|
||||
<a class="xref" href="../api/Hi.Numerical.HardNcEnv.html">HardNcEnv</a> is reachable only through its endpoint and the project XML, and the
|
||||
two are not kept in step.</p>
|
||||
<p>One flag sits outside both models. <strong>Set ideal offset dependent on tool house</strong> is a project-level
|
||||
configuration flag, and the branch's Tool Offsets leaf and the legacy <code>ideal-offset-dependent</code>
|
||||
endpoint read and write that one flag. The two <em>tables</em> stay separate: the legacy
|
||||
<code>set-ideal-offset-from-toolhouse</code> endpoint — the removed Offset Table tab's <strong>Refresh from Tool
|
||||
House</strong> — recomputes <a class="xref" href="../api/Hi.Numerical.HardNcEnv.html#Hi_Numerical_HardNcEnv_MillingToolOffsetTable">MillingToolOffsetTable</a> from
|
||||
<a class="xref" href="../api/Hi.Machining.MachiningToolHouse.html">MachiningToolHouse</a>, while the branch's refresh recomputes the runner's own
|
||||
tool-offset table.</p>
|
||||
<h2 id="two-faces-of-a-work-coordinate">Two Faces of a Work Coordinate</h2>
|
||||
<p>The work-coordinate marker is one displayee class serving two providers. The screen's viewer draws
|
||||
<p>The work-coordinate marker is one displayee class serving two providers. The Execution canvas draws
|
||||
it from <a class="xref" href="../api/Hi.Numerical.HardNcEnv.html#Hi_Numerical_HardNcEnv_IsoCoordinateTable">IsoCoordinateTable</a> — a
|
||||
<a class="xref" href="../api/Hi.NcParsers.Dependencys.Generic.IsoCoordinateTable.html">IsoCoordinateTable</a> instance owned by the legacy model, which
|
||||
constructs with <code>G54</code> … <code>G59</code> and <code>G59.1</code> … <code>G59.9</code> all at zero. The General Setup canvas builds the
|
||||
same displayee over the active runner's effective
|
||||
<a class="xref" href="../api/Hi.NcParsers.Dependencys.IIsoCoordinateConfig.html">IIsoCoordinateConfig</a> instead, which on most brands is the brand
|
||||
parameter table. Same marker, same code, two stores.</p>
|
||||
<p>Selecting a row on the ISO Coordinate Table tab writes the marker's id onto the shared Execution
|
||||
displayee, so it decides which offset the marker draws at. It decides that whether or not the marker
|
||||
is drawn: all three coordinate flags are off in the shipped rendering-flag set — as are the machine
|
||||
tool and the cutter, leaving the workpiece, the fixture, the dimension bar and the cutter-location
|
||||
strip as the four that arrive on — so on an untouched project the selection column moves something
|
||||
invisible until <strong>Show on Display</strong> is pressed. The datum tabs also carry a single-selection column,
|
||||
but nothing is sent when it changes — there the selection is a highlight and nothing more.</p>
|
||||
constructs with <code>G54</code> … <code>G59</code> and <code>G59.1</code> … <code>G59.9</code> all at zero — and draws its Heidenhain datum
|
||||
marker from the legacy datum tables the same way. The General Setup canvas builds the same
|
||||
displayee over the active runner's effective <a class="xref" href="../api/Hi.NcParsers.Dependencys.IIsoCoordinateConfig.html">IIsoCoordinateConfig</a>
|
||||
instead, which on most brands is the brand parameter table. Same marker, same code, two stores.</p>
|
||||
<p>Which row the Execution marker draws is the displayee's own id, constructed as <code>G54</code>. Its only
|
||||
writer is the legacy <code>iso-coordinate-selection</code> endpoint, which the removed tab's row selection
|
||||
posted to and nothing in the SPA posts to now, so the Execution marker stays on <code>G54</code>. Whether it
|
||||
is drawn is the <code>IsoCoordinate</code> rendering flag, toggled from the Execution page's Scene dropdown;
|
||||
all three coordinate flags are off in the shipped rendering-flag set — as are the machine tool and
|
||||
the cutter, leaving the workpiece, the fixture, the dimension bar and the cutter-location strip as
|
||||
the four that arrive on. The General Setup marker's row is a user-config value of its own, with an
|
||||
endpoint on the equipment-setup display controller.</p>
|
||||
<h2 id="source-code-path">Source Code Path</h2>
|
||||
<p>See <a class="xref" href="index.html">HiNC App Anatomy</a> for git repository links.</p>
|
||||
<h3 id="web-application">Web Application</h3>
|
||||
<p>HiNC-2025-webservice (Quasar CLI SPA):</p>
|
||||
<ul>
|
||||
<li><code>wwwroot-src/src/components/controller/CoordinateTableTab.vue</code> — <strong>Align P0</strong> with its two
|
||||
client-side history stacks and their cap, and the <strong>Show on Display</strong> toggle bound to the
|
||||
<code>IsoCoordinate</code> rendering flag.</li>
|
||||
<li><code>wwwroot-src/src/components/controller/DatumPresetTab.vue</code> and
|
||||
<code>wwwroot-src/src/components/controller/DatumShiftTab.vue</code> — the same <strong>Show on Display</strong> button
|
||||
over <code>HeidenhainCoordinate</code>, and the row selection that is a highlight and nothing more.</li>
|
||||
<li><code>wwwroot-src/src/components/controller/OffsetTableTab.vue</code> — <strong>Refresh from Tool House</strong>, and the
|
||||
two-step toggle over the project-level tool-house dependence flag the branch also writes.</li>
|
||||
<li><code>wwwroot-src/src/components/controller/ConfigTab.vue</code> — the shortest-rotary toggle and its banner.</li>
|
||||
<li><code>wwwroot-src/src/components/controller/BrandTab.vue</code> — the Heidenhain master-axis card: its read
|
||||
normalisation and its write.</li>
|
||||
<li><code>wwwroot-src/src/api/renderingFlags.ts</code> — the flag indices those toggles write, and which of the
|
||||
shipped set default on.</li>
|
||||
<li><code>wwwroot-src/src/api/controller.ts</code> — the typed wrappers over the align and revert endpoints, and
|
||||
the brand constants these settings are read against.</li>
|
||||
<li><code>Controller/ControllerController.cs</code> — the align endpoint that snapshots the transformer either
|
||||
side of the write, and the stateless revert this screen's history posts back to.</li>
|
||||
<li><code>Controller/ControllerController.cs</code> — the model's REST face, still mounted: every legacy table
|
||||
and setting, the align endpoint that snapshots the transformer either side of the write, the
|
||||
stateless revert, the <code>update</code> rebind, and the marker-row selection.</li>
|
||||
<li><code>wwwroot-src/src/api/controller.ts</code> — the typed wrappers over all of it, kept as those endpoints'
|
||||
only client; <code>getCncBrand</code> and the brand constants are what a live component still imports.</li>
|
||||
<li><code>wwwroot-src/src/components/execution/ExecutionExtendedToolBar.vue</code> — that component: the Scene
|
||||
dropdown that toggles the coordinate flags, and asks the legacy model for its brand.</li>
|
||||
<li><code>wwwroot-src/src/api/renderingFlags.ts</code> — the flag indices the Scene dropdown writes.</li>
|
||||
<li><code>Disp/ExecutionDisplayee.cs</code> — the Execution canvas's displayee: the shipped flag set, and the
|
||||
work-coordinate and datum markers it builds over the legacy tables.</li>
|
||||
<li><code>Disp/IsoCoordinateEntryDisplayee.cs</code> — the one marker class both canvases draw with.</li>
|
||||
<li><code>Disp/EquipmentSetupDisplayee.cs</code> — the General Setup canvas's marker, over the runner's
|
||||
providers.</li>
|
||||
<li><code>wwwroot-src/src/router/routes.ts</code> — the <code>/controller/…</code> redirect stub onto the Controller branch.</li>
|
||||
</ul>
|
||||
<h3 id="hiapi-engine">HiAPI Engine</h3>
|
||||
<ul>
|
||||
<li><code>HiUniNc/Numerical/HardNcEnv.cs</code> — the model this screen edits: the coordinate, datum and offset
|
||||
tables, the stroke boxes that construct infinite, the rapid rate and tooling time, the
|
||||
shortest-rotary flag with its Heidenhain exclusion, and the master-axis character over its integer
|
||||
direction.</li>
|
||||
<li><code>HiUniNc/Numerical/HardNcEnv.cs</code> — the model: the coordinate, datum and offset tables, the stroke
|
||||
boxes that construct infinite, the rapid rate and tooling time, the per-axis rotary speed
|
||||
ceiling, the shortest-rotary flag with its Heidenhain exclusion, and the master-axis character
|
||||
over its integer direction.</li>
|
||||
<li><code>HiUniNc/Numerical/HardNcLine.cs</code> — the legacy consumers of two of those settings: the
|
||||
shortest-rotary path application and the <code>SEQ</code> solve that reads the master-axis direction.</li>
|
||||
<li><code>HiUniNc/Numerical/NcProc.cs</code> — the legacy consumer of the rotary speed ceiling: feed and cycle
|
||||
time re-limited per rotary axis.</li>
|
||||
<li><code>HiUniNc/Numerical/MillingToolOffsetTable.cs</code> — the offset table and the tool-house recompute the
|
||||
Refresh button calls.</li>
|
||||
legacy refresh endpoint calls.</li>
|
||||
<li><code>HiMech/NcParsers/Dependencys/Generic/IsoCoordinateTable.cs</code> — the coordinate table type and the
|
||||
fifteen G-code keys it constructs with, shared by name with the runner's brand-agnostic table.</li>
|
||||
<li><code>HiMech/Machining/MachiningEquipmentUtils/MachiningEquipmentUtil.cs</code> — the alignment itself: the
|
||||
@@ -229,17 +265,16 @@ on the runner pipeline: the first declared rotary axis, with no configured alter
|
||||
<li><code>HiNc/MachiningProcs/MachiningProject.cs</code> — where both models hang off the project, and the load
|
||||
path that derives a runner from the legacy element only when no runner element is present.</li>
|
||||
<li><code>HiNc/MachiningProcs/LocalProjectService.cs</code> — the legacy runner built over a delegate onto the
|
||||
project's model, and the switch that selects which pipeline is active.</li>
|
||||
project's model, the switch that selects which pipeline is active, and the stroke-limit and
|
||||
home-position fallbacks onto the legacy model.</li>
|
||||
<li><code>HiNc/Numerical/FilePlayers/HardNcRunner.cs</code> — the legacy runner itself.</li>
|
||||
<li><code>HiNc/MachiningProcs/SessionShell.cs</code> — the scripting face of the pipeline switch and of the
|
||||
alignment, and the optimisation route that passes the legacy model directly.</li>
|
||||
</ul>
|
||||
<h2 id="see-also">See Also</h2>
|
||||
<ul>
|
||||
<li><a class="xref" href="legacy-controller.html">Legacy Controller Page</a> — the screen these settings are edited on: its seven tabs, its commit
|
||||
and rollback rules, its object-management chain and its viewer</li>
|
||||
<li><a class="xref" href="general-setup/controller/index.html">Controller Branch</a> — the SoftNcRunner-native controller branch that carries the editors for
|
||||
everything named above as shared</li>
|
||||
<li><a class="xref" href="general-setup/controller/index.html">Controller Branch</a> — the SoftNcRunner-native controller branch: the live settings face,
|
||||
and the editor for everything named above as having a runner-side copy</li>
|
||||
<li><a class="xref" href="general-setup/index.html">General Setup Page</a> — the page that hosts that branch, and the rest of the equipment tree
|
||||
beside it</li>
|
||||
</ul>
|
||||
|
||||
@@ -1,472 +0,0 @@
|
||||
<!DOCTYPE html>
|
||||
<html>
|
||||
<head>
|
||||
<meta charset="utf-8">
|
||||
<title>Legacy Controller Page | HiAPI-C# 2025 </title>
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
<meta name="title" content="Legacy Controller Page | HiAPI-C# 2025 ">
|
||||
|
||||
|
||||
<link rel="icon" href="../img/HiAPI.favicon.ico">
|
||||
<link rel="stylesheet" href="../public/docfx.min.css">
|
||||
<link rel="stylesheet" href="../public/main.css">
|
||||
<meta name="docfx:navrel" content="../toc.html">
|
||||
<meta name="docfx:tocrel" content="toc.html">
|
||||
|
||||
<meta name="docfx:rel" content="../">
|
||||
|
||||
|
||||
|
||||
<meta name="loc:inThisArticle" content="In this article">
|
||||
<meta name="loc:searchResultsCount" content="{count} results for "{query}"">
|
||||
<meta name="loc:searchNoResults" content="No results for "{query}"">
|
||||
<meta name="loc:tocFilter" content="Filter by title">
|
||||
<meta name="loc:nextArticle" content="Next">
|
||||
<meta name="loc:prevArticle" content="Previous">
|
||||
<meta name="loc:themeLight" content="Light">
|
||||
<meta name="loc:themeDark" content="Dark">
|
||||
<meta name="loc:themeAuto" content="Auto">
|
||||
<meta name="loc:changeTheme" content="Change theme">
|
||||
<meta name="loc:copy" content="Copy">
|
||||
<meta name="loc:downloadPdf" content="Download PDF">
|
||||
|
||||
<script type="module" src="./../public/docfx.min.js"></script>
|
||||
|
||||
<script>
|
||||
const theme = localStorage.getItem('theme') || 'auto'
|
||||
document.documentElement.setAttribute('data-bs-theme', theme === 'auto' ? (window.matchMedia('(prefers-color-scheme: dark)').matches ? 'dark' : 'light') : theme)
|
||||
</script>
|
||||
|
||||
</head>
|
||||
|
||||
<body class="tex2jax_ignore" data-layout="" data-yaml-mime="">
|
||||
<header class="bg-body border-bottom">
|
||||
<nav id="autocollapse" class="navbar navbar-expand-md" role="navigation">
|
||||
<div class="container-xxl flex-nowrap">
|
||||
<a class="navbar-brand" href="../index.html">
|
||||
<img id="logo" class="svg" src="../img/HiAPI.logo.png" alt="">
|
||||
|
||||
</a>
|
||||
<button class="btn btn-lg d-md-none border-0" type="button" data-bs-toggle="collapse" data-bs-target="#navpanel" aria-controls="navpanel" aria-expanded="false" aria-label="Toggle navigation">
|
||||
<i class="bi bi-three-dots"></i>
|
||||
</button>
|
||||
<div class="collapse navbar-collapse" id="navpanel">
|
||||
<div id="navbar">
|
||||
<form class="search" role="search" id="search">
|
||||
<i class="bi bi-search"></i>
|
||||
<input class="form-control" id="search-query" type="search" disabled placeholder="Search" autocomplete="off" aria-label="Search">
|
||||
</form>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
</nav>
|
||||
</header>
|
||||
|
||||
<main class="container-xxl">
|
||||
<div class="toc-offcanvas">
|
||||
<div class="offcanvas-md offcanvas-start" tabindex="-1" id="tocOffcanvas" aria-labelledby="tocOffcanvasLabel">
|
||||
<div class="offcanvas-header">
|
||||
<h5 class="offcanvas-title" id="tocOffcanvasLabel">Table of Contents</h5>
|
||||
<button type="button" class="btn-close" data-bs-dismiss="offcanvas" data-bs-target="#tocOffcanvas" aria-label="Close"></button>
|
||||
</div>
|
||||
<div class="offcanvas-body">
|
||||
<nav class="toc" id="toc"></nav>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div class="content">
|
||||
<div class="actionbar">
|
||||
<button class="btn btn-lg border-0 d-md-none" type="button" data-bs-toggle="offcanvas" data-bs-target="#tocOffcanvas" aria-controls="tocOffcanvas" aria-expanded="false" aria-label="Show table of contents">
|
||||
<i class="bi bi-list"></i>
|
||||
</button>
|
||||
|
||||
<nav id="breadcrumb"></nav>
|
||||
</div>
|
||||
|
||||
<article data-uid="Anatomy-ControllerPage">
|
||||
<h1 id="legacy-controller-page">Legacy Controller Page</h1>
|
||||
|
||||
<p>The Legacy Controller page is the superseded controller face: the screen that edits
|
||||
<a class="xref" href="../api/Hi.Numerical.HardNcEnv.html">HardNcEnv</a>, kept reachable while it still carries settings nothing else in the
|
||||
application edits. It ships at the route <code>/controller/:tab?</code>, is reached from the app menu bar's
|
||||
<strong>Page → Legacy-Controller</strong> entry, and owns no Control-Tree id of its own. Controller settings for
|
||||
a project are edited on the General Setup page at <code>/general-setup</code> under the Control-Tree id
|
||||
<code>equipment/controller</code> — <a class="xref" href="general-setup/controller/index.html">Controller Branch</a> — and the two surfaces edit
|
||||
different models, so an edit on one is invisible to the other.</p>
|
||||
<div class="IMPORTANT">
|
||||
<h5>Important</h5>
|
||||
<p>The <code>equipment/controller</code> id named above belongs to the Controller Branch rather than to this
|
||||
page, and Anatomy makes no claim that it is stable across versions. The migration hop that keeps
|
||||
an older value resolving is described in <a class="xref" href="platform/tree-ids-and-routes.html">Tree Ids and Routes</a>.</p>
|
||||
</div>
|
||||
<p>The model this screen edits — what <a class="xref" href="../api/Hi.Numerical.HardNcEnv.html">HardNcEnv</a> holds, the three settings it
|
||||
owns alone, what it shares with the branch, and the engine files behind all of it — is
|
||||
<a class="xref" href="legacy-controller-settings.html">Legacy Controller Settings</a>.</p>
|
||||
<h2 id="the-tabs">The Tabs</h2>
|
||||
<p>The left pane is a tab strip over seven panels, addressable as the route's optional segment:
|
||||
<code>coordinate-table</code>, <code>datum-preset</code>, <code>datum-shift</code>, <code>offset-table</code>, <code>machine</code>, <code>brand</code>, <code>config</code>. A
|
||||
bare <code>/controller</code> canonicalises to <code>coordinate-table</code>. Two tab <strong>buttons</strong> are conditional — Datum
|
||||
Preset and Datum Shift render only while the brand reads Heidenhain — but their panels are always
|
||||
present in the template, so both segments stay valid URL targets under any brand. Switching the brand
|
||||
away from Heidenhain while one of those two is active moves the selection back to Coordinate Table.</p>
|
||||
<table>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Tab</th>
|
||||
<th>Edits</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>Coordinate Table</td>
|
||||
<td><a class="xref" href="../api/Hi.Numerical.HardNcEnv.html#Hi_Numerical_HardNcEnv_IsoCoordinateTable">IsoCoordinateTable</a>, plus the P0 / M0 / Align P0 row actions</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Datum Preset</td>
|
||||
<td><a class="xref" href="../api/Hi.Numerical.HardNcEnv.html#Hi_Numerical_HardNcEnv_HeidenhainDatumPresetTable">HeidenhainDatumPresetTable</a>, keyed <code>Q339</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Datum Shift</td>
|
||||
<td><a class="xref" href="../api/Hi.Numerical.HardNcEnv.html#Hi_Numerical_HardNcEnv_HeidenhainDatumShiftTable">HeidenhainDatumShiftTable</a>, keyed <code>D</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Offset Table</td>
|
||||
<td><a class="xref" href="../api/Hi.Numerical.MillingToolOffsetTable.html">MillingToolOffsetTable</a> with row-level add, delete and key rename</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Machine</td>
|
||||
<td><a class="xref" href="../api/Hi.Numerical.HardNcEnv.html#Hi_Numerical_HardNcEnv_RapidFeedrate_mmdmin">RapidFeedrate_mmdmin</a>, <a class="xref" href="../api/Hi.Numerical.HardNcEnv.html#Hi_Numerical_HardNcEnv_ToolingTime">ToolingTime</a>, <a class="xref" href="../api/Hi.Numerical.HardNcEnv.html#Hi_Numerical_HardNcEnv_StrokeLimitXyz_mm">StrokeLimitXyz_mm</a>, <a class="xref" href="../api/Hi.Numerical.HardNcEnv.html#Hi_Numerical_HardNcEnv_StrokeLimitAbc_rad">StrokeLimitAbc_rad</a>, <a class="xref" href="../api/Hi.Numerical.HardNcEnv.html#Hi_Numerical_HardNcEnv_MaxRotarySpeedABC_radds">MaxRotarySpeedABC_radds</a></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Brand</td>
|
||||
<td><a class="xref" href="../api/Hi.Numerical.HardNcEnv.html#Hi_Numerical_HardNcEnv_CncBrand">CncBrand</a>, and the master-axis character on Heidenhain</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Config</td>
|
||||
<td><a class="xref" href="../api/Hi.Numerical.HardNcEnv.html#Hi_Numerical_HardNcEnv_EnableShortestRotary">EnableShortestRotary</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<p>The brand select offers all five declared brands — <a class="xref" href="../api/Hi.Numerical.CncBrand.html#Hi_Numerical_CncBrand_Fanuc">Fanuc</a>,
|
||||
<a class="xref" href="../api/Hi.Numerical.CncBrand.html#Hi_Numerical_CncBrand_Heidenhain">Heidenhain</a>, <a class="xref" href="../api/Hi.Numerical.CncBrand.html#Hi_Numerical_CncBrand_Mazak">Mazak</a>,
|
||||
<a class="xref" href="../api/Hi.Numerical.CncBrand.html#Hi_Numerical_CncBrand_Siemens">Siemens</a> and <a class="xref" href="../api/Hi.Numerical.CncBrand.html#Hi_Numerical_CncBrand_Syntec">Syntec</a> — labelled with the
|
||||
brand names verbatim rather than through the locale bundle, and warns above the select that
|
||||
<em>"Brand-specific settings may be lost when the brand changes."</em></p>
|
||||
<p><strong>The Machine tab's axis rows are fixed, not chain-driven.</strong> It renders exactly <code>X</code>, <code>Y</code>, <code>Z</code> under
|
||||
<strong>Linear Axis Stroke (mm)</strong> and exactly <code>A</code>, <code>B</code>, <code>C</code> under <strong>Rotary Axis Stroke (deg) & Max Speed
|
||||
(rpm)</strong>, because both row sets are literal in the template. Every write there sends the whole vector
|
||||
— all six linear bounds, all six rotary bounds converted to radians, or all three speeds converted to
|
||||
rad/s — rather than the one cell that changed. The branch's per-axis leaves take the opposite shape:
|
||||
one row per machine-chain axis, one axis per write, described in
|
||||
<a class="xref" href="general-setup/controller/machine/per-axis-tables.html">Per-Axis Tables</a>.</p>
|
||||
<p>Both stroke limits construct as an infinite box, and the service serializes named floating-point
|
||||
literals, so those bounds reach the browser as the tokens <code>Infinity</code> and <code>-Infinity</code> rather than as
|
||||
numbers. The shared numeric field prints what it is handed and parses both words back, so an
|
||||
unconfigured Machine tab opens showing those words rather than a blank and takes them typed in; the
|
||||
rotary rows carry them through unconverted, because the degree conversion guards on a finite value.</p>
|
||||
<p><strong>A stroke write does not survive its own re-read.</strong> The read and the write agree on the wire order:
|
||||
the read emits the six bounds interleaved per axis, <code>[minX, maxX, minY, maxY, minZ, maxZ]</code>, and the
|
||||
tab posts the same six back. The write then hands that vector to the box constructor, which reads its
|
||||
arguments <em>grouped</em> — the whole minimum corner first, the whole maximum corner second. The vector is
|
||||
de-interleaved on the way in, so only the first and the last number land where they were sent and the
|
||||
four between them move to other rows; from the infinite default above, that is enough to leave the
|
||||
middle axis reading a <code>Max</code> below its <code>Min</code> after any single edit. The rotary stroke endpoints share
|
||||
the constructor and the behaviour; the three <strong>Max Speed</strong> values travel as a plain triple and are
|
||||
unaffected. The regrouped box is not inert — with the stroke check on and no runner-side stroke
|
||||
config resolving, the legacy play path validates every step against
|
||||
<a class="xref" href="../api/Hi.Numerical.HardNcEnv.html#Hi_Numerical_HardNcEnv_StrokeLimitXyz_mm">StrokeLimitXyz_mm</a> and <a class="xref" href="../api/Hi.Numerical.HardNcEnv.html#Hi_Numerical_HardNcEnv_StrokeLimitAbc_rad">StrokeLimitAbc_rad</a>
|
||||
as stored. The branch's per-axis leaves, writing one axis at a time, carry none of it.</p>
|
||||
<h2 id="how-an-edit-commits">How an Edit Commits</h2>
|
||||
<p>The tabs reuse the same numeric field the rest of the application uses, so the timing is that
|
||||
widget's: commit on blur or on Enter, never per keystroke, with the bounds and parse behaviour set
|
||||
out in <a class="xref" href="widget/numeric-input.html">Numeric Input</a>. Clearing a cell parses to null and every legacy
|
||||
handler returns on null, so an emptied cell is not an edit — the one exception is the Offset Table's
|
||||
tool-number cell, which forbids an empty value and shows a parse error in place instead. Selects,
|
||||
toggles and row buttons commit on the click.</p>
|
||||
<p>The optimistic write is the same capture-assign-await-restore shape the branch's panels use, and
|
||||
<a class="xref" href="general-setup/controller/editing-contract.html">Editing Contract</a> is where that shape, its row-scoped
|
||||
payloads and its rollback semantics are set out once. Four differences are this screen's own:</p>
|
||||
<ul>
|
||||
<li><strong>Three fields commit without a rollback.</strong> The Machine tab's <strong>Rapid Feedrate</strong> and <strong>Tooling
|
||||
Time</strong> handlers assign the new value and await the write without capturing the old one, so a
|
||||
refused write raises the toast and leaves the field showing the number the server rejected. The
|
||||
Brand tab's <strong>Master-axis character</strong> select is the third and the least recoverable: its handler
|
||||
captures nothing and restores nothing, and its two-way binding has already put the pick into the
|
||||
tab's own state before the handler runs, so a refused write leaves the rejected character on screen
|
||||
looking accepted. Every other value handler — the stroke and speed vectors, the coordinate and
|
||||
datum cells, the offset row and its key rename, the brand select itself, the shortest-rotary toggle
|
||||
(two-way bound as well, but reconstructing its old value from the new one) — restores the old value
|
||||
on failure. Row actions are outside the shape entirely: <strong>P0</strong>, <strong>M0</strong>, the datum reset, an add and
|
||||
a delete all write first and touch the local rows only once the request resolves.</li>
|
||||
<li><strong>The REST surface answers with status codes, not a success envelope.</strong> A missing table, an
|
||||
unknown index or an unexpected paste type is answered as <em>not found</em>, <em>bad request</em> or <em>conflict</em>.
|
||||
Most of those answers are bare English sentences; four carry a code — no project loaded, no NcEnv
|
||||
found, no NcEnv configuration and no fixture — which the client re-renders from the locale bundle
|
||||
under any language but English. The branch's surface instead answers a missing dependency inside a
|
||||
200 envelope; nothing here does.</li>
|
||||
<li><strong>A refused load is silent on six of the seven tabs.</strong> Every write wrapper in this page's API
|
||||
module goes through the plain-JSON helper, which throws on any non-2xx and returns the parsed body
|
||||
otherwise, so a refused write always reaches a toast. Eight read wrappers deliberately bypass it
|
||||
and answer a benign default on any non-2xx: an empty list for the coordinate table, both datum
|
||||
tables and the offset table, <em>unknown</em> for the brand, <code>A</code> for the master-axis character, and <em>off</em>
|
||||
for the tool-house dependence and shortest-rotary flags. A refused load therefore renders as an
|
||||
empty or default tab, indistinguishable from one whose table really is empty, with no toast and no
|
||||
console line. Only the Machine tab's five reads throw, so it is the one tab on which a refused load
|
||||
shows.</li>
|
||||
<li><strong>The tool-house dependence toggle writes before it flips.</strong> Turning it on awaits the flag write,
|
||||
then flips the local toggle, then refreshes the offsets from the tool house and re-reads the table.
|
||||
A failure in the refresh therefore leaves the flag committed on both sides rather than reverted.</li>
|
||||
</ul>
|
||||
<p>Every tab composes its failure toast the same way: negative, 3.5 seconds, the tab's own localized
|
||||
context followed by the thrown error's own text, with a console line naming the component. That text
|
||||
is built by the shared helper as <code>HTTP <status>: <server message></code>, so the status code reaches the
|
||||
user in the toast — where the branch's envelope failures surface the server's sentence alone.</p>
|
||||
<p>Each tab fetches once on mount and again when its has-a-project prop turns true; the tab panels are
|
||||
kept alive, so moving between tabs does not refetch. That prop is the indexed key rather than the
|
||||
project store's own flag: Initialize answers <em>not found</em> where the project carries no <code>NcEnv</code>, so a
|
||||
project can be open while every tab still reads as having none. Nothing pushes changes at a mounted
|
||||
tab, and no tab re-reads after a cell edit — the Offset Table's two tool-house actions are the one
|
||||
exception, because the server recomputes the table under them.</p>
|
||||
<p>The four tables that render as data tables — the coordinate table, the two datum tables and the
|
||||
offset table — are the only places in the application that use that component. None of them declares
|
||||
a sortable column, and all four run unpaginated with every row shown.</p>
|
||||
<h2 id="object-management-and-the-install-chain">Object Management and the Install Chain</h2>
|
||||
<p>The left pane's head line carries the shared object-management ⋮ menu, the title <strong>Controller</strong>, and
|
||||
a badge reading <em>ready</em> while a key is indexed and <em>no project</em> otherwise. The menu's entries are
|
||||
Load, Save As, Copy, Paste and XML Mode; Load Resource is absent because the page passes no resource
|
||||
directory. Load and Save As browse the server file system through the shared file-explorer dialog
|
||||
filtered to <code>*.NcEnv / *.xml</code>, rooted at the project directory once a project is open; Save As
|
||||
proposes the name <code>NcEnv.xml</code>; Paste is checked against the expected type
|
||||
<code>Hi.Numerical.HardNcEnv, HiUniNc</code>.</p>
|
||||
<p>Load, Paste and an XML apply swap only the indexed object, so the page then installs it: it posts the
|
||||
indexed key to the install endpoint <strong>before</strong> re-running Initialize, because Initialize re-indexes
|
||||
from the project and would otherwise resurrect the object that was replaced. A failed install stops
|
||||
the chain with a toast. A successful one re-reads the brand, which is what re-gates the two Heidenhain
|
||||
tabs, refreshes the rendering flags, and raises an informational toast naming the installed type. The
|
||||
XML dialog's Apply raises the load event as well as its own, and the page listens only to the load
|
||||
event, so the chain runs once rather than twice.</p>
|
||||
<p>Initialize mints a fresh index key on every call, and the page registers each one for cleanup and
|
||||
drops the key it replaced, so repeated installs do not accumulate entries.</p>
|
||||
<h2 id="the-viewer">The Viewer</h2>
|
||||
<p>The right pane is a rendering canvas with its own toolbar: the shared view toolbar, a <strong>Scene ▾</strong>
|
||||
dropdown, and a badge reading <em>rendering</em> or <em>disconnected</em>. The canvas binds the <strong>shared Execution
|
||||
displayee</strong> rather than a viewer of its own, so what is toggled here is what the Execution page
|
||||
shows.</p>
|
||||
<p>The Scene dropdown groups its checkboxes as <strong>Solid</strong> — Machine, Tool, Workpiece, Fixture —
|
||||
<strong>Coordinate</strong> — Program Zero, ISO Coordinate, Heidenhain Coordinate — and <strong>Display Aids</strong> —
|
||||
Dimension Bar, Color Scale Bar. The Heidenhain Coordinate row is listed only while the brand reads
|
||||
Heidenhain. Three tabs carry a <strong>Show on Display</strong> button of their own that flips the same shared
|
||||
flags: the coordinate tab flips ISO Coordinate, and the two datum tabs both flip Heidenhain
|
||||
Coordinate.</p>
|
||||
<p>The Heidenhain marker is gated twice over, and the second gate is never satisfied. The displayee is
|
||||
added to the scene only while its flag is set <em>and</em> the model's brand is Heidenhain; it then returns
|
||||
without drawing until an active datum number or datum-shift argument has been assigned to it, and no
|
||||
code path in the web service assigns either. So the marker stays absent whatever the flag reads.
|
||||
Where it does draw, it resolves its offset through the legacy datum tables — the ones this page's two
|
||||
datum tabs edit — and not through the runner's.</p>
|
||||
<h2 id="layout">Layout</h2>
|
||||
<ul>
|
||||
<li><strong>Legacy Controller</strong> Page — <code>/controller/:tab?</code>, a two-pane splitter, left pane 55 % and draggable
|
||||
between 25 % and 75 %
|
||||
<ul>
|
||||
<li>Management Pane
|
||||
<ul>
|
||||
<li>Head Line
|
||||
<ul>
|
||||
<li><a class="xref" href="widget/object-management-menu-button.html">Object Management Menu Button</a> (<code>⋮</code>) — Load, Save
|
||||
As, Copy, Paste, XML Mode</li>
|
||||
<li><strong>Controller</strong> Title</li>
|
||||
<li>Status Badge — <em>ready</em> / <em>no project</em></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li>Tab Strip — <strong>Coordinate Table</strong>, <strong>Datum Preset</strong>, <strong>Datum Shift</strong>, <strong>Offset Table</strong>,
|
||||
<strong>Machine</strong>, <strong>Brand</strong>, <strong>Config</strong>; the two datum buttons rendered only under Heidenhain</li>
|
||||
<li>Tab Panels — kept alive; one shown at a time
|
||||
<ul>
|
||||
<li><strong>ISO Coordinate Table</strong> Panel
|
||||
<ul>
|
||||
<li>Toolbar — <strong>Undo Align</strong>, <strong>Redo Align</strong>, <strong>Show on Display</strong></li>
|
||||
<li>Table — columns <strong>Index</strong>, <strong>X</strong>, <strong>Y</strong>, <strong>Z</strong>, <strong>Actions</strong>, with a single-selection column
|
||||
<ul>
|
||||
<li>Row Actions — <strong>P0</strong>, <strong>M0</strong>, <strong>Align P0</strong></li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li><strong>Datum Preset Table</strong> Panel — <strong>Show on Display</strong>; columns <strong>Q339</strong>, <strong>X</strong>, <strong>Y</strong>, <strong>Z</strong>,
|
||||
<strong>Actions</strong>, the action being a reset-to-zero button</li>
|
||||
<li><strong>Datum Shift Table</strong> Panel — the same shape, keyed <strong>D</strong></li>
|
||||
<li><strong>Tool Offset Table</strong> Panel
|
||||
<ul>
|
||||
<li>Toolbar — <strong>Set ideal offset dependent on tool house</strong> toggle, and <strong>Refresh from Tool
|
||||
House</strong> while it is on</li>
|
||||
<li>Table — columns <strong>Tool #</strong>, <strong>Ideal Radius</strong>, <strong>Radial Wear</strong>, <strong>Ideal Height</strong>, <strong>Axial
|
||||
Wear</strong>, and a delete button; the tool number is editable and the delete button present only
|
||||
while the dependence is off</li>
|
||||
<li><strong>Add</strong> Button — below the table, shown only while the dependence is off</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li><strong>Machine Configuration</strong> Panel
|
||||
<ul>
|
||||
<li><strong>General</strong> Card — <strong>Rapid Feedrate (mm/min)</strong> and <strong>Tooling Time (sec)</strong> numeric fields</li>
|
||||
<li><strong>Linear Axis Stroke (mm)</strong> Card — <strong>Axis</strong> / <strong>Min</strong> / <strong>Max</strong> over fixed rows X, Y, Z</li>
|
||||
<li><strong>Rotary Axis Stroke (deg) & Max Speed (rpm)</strong> Card — <strong>Axis</strong> / <strong>Min (deg)</strong> /
|
||||
<strong>Max (deg)</strong> / <strong>Max Speed (rpm)</strong> over fixed rows A, B, C</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li><strong>CNC Brand</strong> Panel
|
||||
<ul>
|
||||
<li><strong>Selection</strong> Card — the brand select over the five brands, above the brand-change warning
|
||||
banner</li>
|
||||
<li><strong>Heidenhain Settings</strong> Card — <strong>Master-axis character</strong> select over A / B / C; shown only
|
||||
under Heidenhain</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li><strong>Configuration</strong> Panel
|
||||
<ul>
|
||||
<li><strong>Options</strong> Card — <strong>Enable Shortest Rotary Path</strong> toggle above its explanatory banner</li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li>Viewer Pane
|
||||
<ul>
|
||||
<li>Viewer Toolbar
|
||||
<ul>
|
||||
<li><a class="xref" href="widget/renderingcanvas-tool-bar.html">RenderingCanvas Tool Bar</a></li>
|
||||
<li><strong>Scene ▾</strong> Dropdown — <strong>Solid</strong>, <strong>Coordinate</strong> and <strong>Display Aids</strong> groups</li>
|
||||
<li>Connection Badge — <em>rendering</em> / <em>disconnected</em></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li>Rendering Canvas — bound to the shared Execution displayee</li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
<h2 id="source-code-path">Source Code Path</h2>
|
||||
<p>See <a class="xref" href="index.html">HiNC App Anatomy</a> for git repository links.</p>
|
||||
<h3 id="web-application">Web Application</h3>
|
||||
<p>HiNC-2025-webservice (Quasar CLI SPA):</p>
|
||||
<ul>
|
||||
<li><code>wwwroot-src/src/pages/ControllerPage.vue</code> — the page shell: the splitter, the seven tab panels and
|
||||
the Heidenhain gate over two of the buttons, the install-then-initialize chain, the rendering-flag
|
||||
snapshot the per-tab toggles read, and the tab reset on leaving Heidenhain.</li>
|
||||
<li><code>wwwroot-src/src/components/controller/CoordinateTableTab.vue</code> — the coordinate table: the per-cell
|
||||
whole-row write, the row selection that names the marker, the P0 / M0 actions, and Align P0 with
|
||||
its two client-side history stacks and their cap.</li>
|
||||
<li><code>wwwroot-src/src/components/controller/DatumPresetTab.vue</code> and
|
||||
<code>wwwroot-src/src/components/controller/DatumShiftTab.vue</code> — the two Heidenhain tables: the <code>Q339</code>
|
||||
and <code>D</code> key columns, the reset-to-zero action, and the selection that is a highlight only.</li>
|
||||
<li><code>wwwroot-src/src/components/controller/OffsetTableTab.vue</code> — the offset editor: row add, delete and
|
||||
key rename with its duplicate guard, and the two-step tool-house dependence toggle.</li>
|
||||
<li><code>wwwroot-src/src/components/controller/MachineTab.vue</code> — the fixed X/Y/Z and A/B/C row sets, the
|
||||
whole-vector writes, the degree and rpm conversions with their infinity guards, and the two
|
||||
handlers that commit without capturing a rollback value.</li>
|
||||
<li><code>wwwroot-src/src/components/controller/BrandTab.vue</code> — the five-brand select with its captured
|
||||
rollback, the change warning, and the Heidenhain master-axis card: its read normalisation, its
|
||||
two-way binding and its write with no rollback.</li>
|
||||
<li><code>wwwroot-src/src/components/controller/ConfigTab.vue</code> — the shortest-rotary toggle, its banner and
|
||||
its reconstructed rollback.</li>
|
||||
<li><code>wwwroot-src/src/components/controller/ControllerExtendedToolBar.vue</code> — the <strong>Scene</strong> dropdown: the
|
||||
three flag groups and the brand test that hides the Heidenhain row.</li>
|
||||
<li><code>wwwroot-src/src/api/controller.ts</code> — the typed wrappers over every endpoint above, the brand
|
||||
constants and their literal labels, the align / revert payloads, the documented stroke-vector order,
|
||||
and the eight read wrappers that answer a default instead of raising.</li>
|
||||
<li><code>wwwroot-src/src/api/http.ts</code> — the plain-JSON helper every write goes through, its coded-error
|
||||
keys, and the success-envelope helper this module does not use.</li>
|
||||
<li><code>wwwroot-src/src/api/renderingFlags.ts</code> — the flag indices the Scene dropdown and the per-tab
|
||||
toggles write.</li>
|
||||
<li><code>wwwroot-src/src/components/widgets/NumericInput.vue</code> — the numeric cell: commit on blur or Enter,
|
||||
the empty-to-null parse the handlers reject, the generic text path that prints the infinity tokens,
|
||||
and the parse branch that takes them back.</li>
|
||||
<li><code>wwwroot-src/src/components/widgets/ObjectManagementMenuButton.vue</code> — the ⋮ menu, its server file
|
||||
browser and extension filter, the paste type check, and the load event an XML apply also raises.</li>
|
||||
<li><code>wwwroot-src/src/components/RenderingCanvas.vue</code> and
|
||||
<code>wwwroot-src/src/components/RenderingCanvasToolBar.vue</code> — the viewer pane's canvas and its shared
|
||||
view toolbar.</li>
|
||||
<li><code>wwwroot-src/src/composables/useRouteTabs.ts</code> — the tab-to-URL sync, the seven valid segments and
|
||||
the default the bare route canonicalises to.</li>
|
||||
<li><code>wwwroot-src/src/composables/useCleanupHub.ts</code> — the registration that drops each superseded index
|
||||
key.</li>
|
||||
<li><code>wwwroot-src/src/router/routes.ts</code> — the <code>/controller/:tab?</code> route beside <code>/general-setup</code>.</li>
|
||||
<li><code>wwwroot-src/src/components/AppMenuBar.vue</code> — the <strong>Page</strong> dropdown carrying the
|
||||
<strong>Legacy-Controller</strong> entry.</li>
|
||||
<li><code>wwwroot-src/src/stores/project.ts</code> — the project flag the page watches in order to re-run
|
||||
Initialize; the indexed key that call returns is what the seven tabs and the status badge read.</li>
|
||||
<li><code>wwwroot-src/src/layouts/MainLayout.vue</code> — the keep-alive that holds the page across navigation and
|
||||
rebuilds it on a project epoch change.</li>
|
||||
<li><code>wwwroot-src/src/i18n/en/controller.ts</code> — every title, tab label, column header, banner and error
|
||||
context quoted above.</li>
|
||||
<li><code>wwwroot-src/src/i18n/en/menu.ts</code> — the <strong>Page</strong> and <strong>Legacy-Controller</strong> menu strings.</li>
|
||||
<li><code>wwwroot-src/src/i18n/en/common.ts</code> — the shared column, action and status strings the tabs reuse.</li>
|
||||
<li><code>Controller/ControllerController.cs</code> — the page's whole REST surface: the index-and-install pair,
|
||||
the per-property readers and writers, the interleaved stroke reads beside the grouped stroke
|
||||
writes, the four coded error payloads, the row-level offset CRUD, the align endpoint that snapshots
|
||||
the transformer either side of the write, the stateless revert, and the display binding that
|
||||
attaches the shared Execution displayee.</li>
|
||||
<li><code>Common/ApiError.cs</code> — the four coded payloads named above.</li>
|
||||
<li><code>Program.cs</code> — the named-floating-point-literal serializer the infinite bounds travel under.</li>
|
||||
<li><code>Widget/ObjectManagementController.cs</code> — the server half of the ⋮ menu, including the paste that
|
||||
rejects an object the expected-type string does not admit.</li>
|
||||
<li><code>Disp/ExecutionDisplayee.cs</code> — the displayee this page's canvas binds: the two coordinate flags,
|
||||
the extra brand test on the Heidenhain one, and the legacy tables both markers are built over.</li>
|
||||
<li><code>Disp/IsoCoordinateEntryDisplayee.cs</code> — the one marker class serving both faces, over whichever
|
||||
coordinate provider it is handed.</li>
|
||||
<li><code>Disp/HeidenhainCoordinateEntryDisplayee.cs</code> — the Heidenhain marker: the brand guard, the datum
|
||||
number and shift argument it draws nothing without, and the legacy tables it resolves through.</li>
|
||||
<li><code>Common/ProjectDisplayeeService.cs</code> — where that single shared displayee is created.</li>
|
||||
</ul>
|
||||
<h3 id="hiapi-engine">HiAPI Engine</h3>
|
||||
<ul>
|
||||
<li><code>HiUniNc/Numerical/HardNcEnv.cs</code> — the model behind the tab table above: the coordinate, datum and
|
||||
offset tables, the two stroke boxes that construct infinite, and the rapid rate and tooling time
|
||||
the Machine tab writes.</li>
|
||||
<li><code>HiGeom/Geom/Box3d.cs</code> — the box the two stroke limits are, its infinite construction, and the
|
||||
six-argument constructor whose grouped argument order the interleaved stroke writes are handed to.</li>
|
||||
<li><code>HiUniNc/Numerical/MillingToolOffsetTable.cs</code> — the offset table the Offset Table tab edits: a
|
||||
dictionary keyed on the offset id, which is the key a row rename moves an entry to.</li>
|
||||
<li><code>HiNc/MachiningProcs/LocalProjectService.cs</code> — the per-step stroke check that falls back to the
|
||||
legacy boxes when no runner-side stroke config resolves, which is what makes a regrouped box
|
||||
observable.</li>
|
||||
</ul>
|
||||
<h2 id="see-also">See Also</h2>
|
||||
<ul>
|
||||
<li><a class="xref" href="legacy-controller-settings.html">Legacy Controller Settings</a> — the model this screen edits, the three settings it
|
||||
owns alone, and the engine files behind them</li>
|
||||
<li><a class="xref" href="general-setup/controller/index.html">Controller Branch</a> — the SoftNcRunner-native controller branch that supersedes this screen,
|
||||
and where controller settings for a project are edited</li>
|
||||
<li><a class="xref" href="general-setup/index.html">General Setup Page</a> — the page that hosts the branch above, and the rest of the equipment
|
||||
tree beside it</li>
|
||||
<li><a href="../manual/utilities/legacy-controller.html">Legacy Controller (manual)</a> — the end-user task: the settings this screen still
|
||||
owns alone, and which face to edit for everything else</li>
|
||||
</ul>
|
||||
|
||||
</article>
|
||||
|
||||
<div class="contribution d-print-none">
|
||||
</div>
|
||||
|
||||
<div class="next-article d-print-none border-top" id="nextArticle"></div>
|
||||
|
||||
</div>
|
||||
|
||||
<div class="affix">
|
||||
<nav id="affix"></nav>
|
||||
</div>
|
||||
</main>
|
||||
|
||||
<div class="container-xxl search-results" id="search-results"></div>
|
||||
|
||||
<footer class="border-top text-secondary">
|
||||
<div class="container-xxl">
|
||||
<div class="flex-fill">
|
||||
<span> Copyright © 2025 <a href='https://superhightech.com.tw'>Tech Coordinate</a>. All rights reserved. <a href='https://superhightech.com.tw'>超級高科技股份有限公司</a> © 2025 版權所有 </span>
|
||||
</div>
|
||||
</div>
|
||||
</footer>
|
||||
</body>
|
||||
</html>
|
||||
@@ -98,7 +98,7 @@ translations are held to under <a class="xref" href="../conventions/translation-
|
||||
<h2 id="the-three-bundles">The Three Bundles</h2>
|
||||
<p>Each locale is a folder under the i18n directory holding one file per namespace plus an index file
|
||||
that re-exports them as a single object. The three folders carry identical file lists — the same
|
||||
twenty-three namespaces, from <code>apiErrors</code> and <code>auth</code> through <code>tree</code> and <code>widgets</code> — because a
|
||||
twenty-two namespaces, from <code>apiErrors</code> and <code>auth</code> through <code>tree</code> and <code>widgets</code> — because a
|
||||
namespace's keys are added to all three locales in the same change. Keys are named
|
||||
<code>namespace.area.element</code> in lowerCamelCase and are split by the UI region they serve rather than by
|
||||
the source file that reads them.</p>
|
||||
@@ -332,7 +332,7 @@ and the re-title registration.</li>
|
||||
<li><code>wwwroot-src/src/i18n/schema.ts</code> — the English bundle as <code>MessageSchema</code>.</li>
|
||||
<li><code>wwwroot-src/src/i18n/schema.d.ts</code> — the ambient augmentation that registers that shape as
|
||||
vue-i18n's global message schema.</li>
|
||||
<li><code>wwwroot-src/src/i18n/en/index.ts</code> — the English bundle: the twenty-three namespaces assembled into
|
||||
<li><code>wwwroot-src/src/i18n/en/index.ts</code> — the English bundle: the twenty-two namespaces assembled into
|
||||
one object.</li>
|
||||
<li><code>wwwroot-src/src/i18n/zh-Hant/index.ts</code> and <code>wwwroot-src/src/i18n/zh-Hans/index.ts</code> — the same
|
||||
assembly, each annotated with <code>MessageSchema</code>.</li>
|
||||
|
||||
@@ -212,7 +212,7 @@ not per browser: two browsers pointed at the same service read and write the sam
|
||||
machining project is server-side in the same way — one project is loaded at a time and every connected
|
||||
browser sees it, which is why the status-hub broadcast is what keeps a second tab honest.</p>
|
||||
<p>The URL carries the rest: the route, the <code>?tree=</code> selection on the two Control-Tree pages, the browsed
|
||||
path on the File Explorer route, and the tab segments on the Tool House and Controller routes. Those
|
||||
path on the File Explorer route, and the tab segments on the Tool House route. Those
|
||||
come back on a reload from the address bar, and when a Control-Tree page is opened with no <code>?tree=</code> the
|
||||
host lands on the stored last selection for that page, falling back to the page's root when the stored
|
||||
id is not in the current project's tree.</p>
|
||||
@@ -286,13 +286,13 @@ focus starts a fresh burst immediately.</p>
|
||||
Because pages are cached, navigating away does not close one, and whether the backend engine stops
|
||||
drawing for it depends on the host. The Execution, General Setup and Tool House pages hand their
|
||||
activation flag to the canvas's <code>active</code> prop, which pauses the engine while the page sits off-screen;
|
||||
the Controller, Machine Tool and Mech Builder canvases and the File Explorer's STL preview bind no
|
||||
the Machine Tool and Mech Builder canvases and the File Explorer's STL preview bind no
|
||||
such prop, and the Execution page's CWE canvas pins it true, so all of those keep rendering until
|
||||
something unmounts them. Collapsing a panel does close one, unless that panel keeps its content
|
||||
mounted: the Execution page's 3D canvas panel does, so it survives a collapse, while the CWE panel
|
||||
beside it does not and its canvas connection goes with it.</li>
|
||||
<li>The cleanup hub is opened once per Control-Tree host and once each on the Controller and Tool House
|
||||
pages. Its composable also holds the set of IndexService keys that owner registered; on unmount it
|
||||
<li>The cleanup hub is opened once per Control-Tree host and once on the Tool House page. Its composable
|
||||
also holds the set of IndexService keys that owner registered; on unmount it
|
||||
posts a removal for every one of them and then stops the connection, so a teardown releases the
|
||||
server-side objects the page had indexed even if the hub never connected.</li>
|
||||
</ul>
|
||||
@@ -364,9 +364,8 @@ guard on the <code>?tree=</code> sync, the landing selection, and the cleanup re
|
||||
and the panel that keeps the 3D canvas mounted through a collapse.</li>
|
||||
<li><code>wwwroot-src/src/pages/GeneralSetupPage.vue</code> — the same lifecycle for the equipment host.</li>
|
||||
<li><code>wwwroot-src/src/pages/ToolHousePage.vue</code> — the page that reloads its singleton explicitly on mount.</li>
|
||||
<li><code>wwwroot-src/src/pages/ControllerPage.vue</code>, <code>wwwroot-src/src/pages/MachineToolPage.vue</code>,
|
||||
<code>wwwroot-src/src/pages/MechBuilderPage.vue</code> and <code>wwwroot-src/src/components/StlPreviewPane.vue</code> —
|
||||
the canvases mounted with no <code>active</code> binding.</li>
|
||||
<li><code>wwwroot-src/src/pages/MachineToolPage.vue</code>, <code>wwwroot-src/src/pages/MechBuilderPage.vue</code> and
|
||||
<code>wwwroot-src/src/components/StlPreviewPane.vue</code> — the canvases mounted with no <code>active</code> binding.</li>
|
||||
<li><code>wwwroot-src/src/components/execution/StepVolumePanel.vue</code> — the CWE canvas that pins <code>active</code> true
|
||||
and is stopped only by its own unmount.</li>
|
||||
<li><code>wwwroot-src/src/pages/FileExplorerPage.vue</code> — the route-leave guard that settles the editor buffer.</li>
|
||||
|
||||
@@ -133,11 +133,6 @@ is one of its children, so each renders inside the Main Panel's frame and menu b
|
||||
<td>The machining chain on a canvas of its own, beside a left column that shows either a read-only identity panel or the chain's XML source — two states of one column, chosen with a GUI/XML toggle. A load button installs a chain file into the project. Carries no Page-menu entry and is reached by URL.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>/controller/:tab?</code></td>
|
||||
<td><code>controller</code></td>
|
||||
<td>The superseded HardNcEnv controller surface. The optional segment mirrors the active tab.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>/tool-house/:toolId(\d+)?/:tab?/:subtab?</code></td>
|
||||
<td><code>tool-house</code></td>
|
||||
<td>The tool library and the per-tool editor. The three optional segments carry the selected tool and the two nested tab levels.</td>
|
||||
@@ -170,9 +165,9 @@ is one of its children, so each renders inside the Main Panel's frame and menu b
|
||||
</tbody>
|
||||
</table>
|
||||
<p>The menu bar's Page dropdown holds every one of these that is menu-reachable, in setup order: Tool
|
||||
House, General Setup and Execution, then File Explorer and Mechanism Builder below a separator,
|
||||
then the legacy Controller below a second one. The Log Viewer has a button of its own rather than a
|
||||
menu entry, and <code>/machine-tool</code> has neither — it is reached by URL.</p>
|
||||
House, General Setup and Execution, then File Explorer and Mechanism Builder below a separator. The
|
||||
Log Viewer has a button of its own rather than a menu entry, and <code>/machine-tool</code> has neither — it is
|
||||
reached by URL.</p>
|
||||
<p>The Tool House route's tool segment is constrained to digits, but all three of its segments are
|
||||
optional, so a non-numeric segment in the tool position is not rejected: the router skips the tool
|
||||
parameter and reads that segment as the tab, which is what makes <code>/tool-house/cutter</code> a working tab
|
||||
@@ -193,6 +188,10 @@ moved into a Control Tree still lands on the editor.</p>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td><code>/controller/:rest(.*)*</code></td>
|
||||
<td><code>/general-setup?tree=equipment/controller</code> — any trailing path is discarded, the retired Controller page's <code>/<tab></code> segment included, so every form lands on the branch root.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>/spindle-capability/:tab?</code></td>
|
||||
<td><code>/general-setup?tree=equipment/spindle</code>, with <code>/<tab></code> appended when the segment is one of <code>thermal</code>, <code>gear-shift</code>, <code>dry-run</code>, <code>power</code>, <code>torque</code>. An unrecognised segment is dropped and the branch root is selected.</td>
|
||||
</tr>
|
||||
@@ -321,8 +320,9 @@ expansion set still unfolds the branches it names;</li>
|
||||
<li>as the first step of <code>routeForTreeId</code>, so the id-to-page resolver never sees an unmigrated id.</li>
|
||||
</ul>
|
||||
<p>Note what the first rule implies: a bare <code>?tree=controller</code> selects the <code>equipment/controller</code>
|
||||
branch — the current controller editor on the General Setup page — and has nothing to do with the
|
||||
<code>/controller</code> route, which is the separate legacy HardNcEnv surface.</p>
|
||||
branch — the controller editor on the General Setup page — and the redirect-only <code>/controller</code> path
|
||||
above lands on the same branch, so a bookmark from the retired Controller page's era resolves in
|
||||
either form.</p>
|
||||
<h2 id="landing-an-id-on-its-page">Landing an Id on Its Page</h2>
|
||||
<p><code>TREE_PAGE_ROOTS</code> lists the first segments that name a page: <code>execution</code>, <code>equipment</code> and
|
||||
<code>toolhouse</code>. <code>spindle</code> is absent on purpose — migration folds it into <code>equipment/…</code> before any root
|
||||
@@ -356,18 +356,18 @@ it, whereas the tool step is tested on its own, so a second segment that is not
|
||||
can carry is discarded either way — an id pointing at a single flute contour under
|
||||
<code>…/cutter/contours/fluting/…</code> lands on the nearest tab the URL can express. The same three name
|
||||
lists are imported by the page itself, so the tab set and the translation cannot drift apart.</p>
|
||||
<p>Once on the page, the tab segments are kept in step with the tabs by <code>useRouteTabs</code>, the composable
|
||||
the Controller route uses as well. It gives each tab level one route param, a valid-name set and a
|
||||
<p>Once on the page, the tab segments are kept in step with the tabs by <code>useRouteTabs</code>, a composable
|
||||
whose only consumer this page is. It gives each tab level one route param, a valid-name set and a
|
||||
default; a nested level may declare which parent values make it apply, and while its parent is
|
||||
something else the level is <strong>dormant</strong> — its segment is dropped from the URL while its reference
|
||||
quietly remembers the last value, so returning to that parent tab returns to the sub-tab it had.
|
||||
The Tool House sub-tab level applies under <code>cutter</code> and <code>holder</code> only, and both its valid set and
|
||||
its default depend on which of the two is showing. A segment the level does not recognise resolves
|
||||
to that default rather than failing. Canonicalisation runs on the first mount and on every
|
||||
keep-alive re-entry, which is why a bare <code>/controller</code> becomes <code>/controller/coordinate-table</code> and a
|
||||
bare <code>/tool-house</code> acquires its tab segments. The tool segment is not one of the composable's
|
||||
levels: the page fills it in itself, adopting the URL's tool when the project holds it and the first
|
||||
tool in the list otherwise, then replacing the URL with what it adopted. That resolver reacts to the
|
||||
keep-alive re-entry, which is why a bare <code>/tool-house</code> acquires its tab segments. The tool segment
|
||||
is not one of the composable's levels: the page fills it in itself, adopting the URL's tool when the
|
||||
project holds it and the first tool in the list otherwise, then replacing the URL with what it
|
||||
adopted. That resolver reacts to the
|
||||
<code>toolId</code> param and to the tool list rather than to page activation, so it also re-points the URL
|
||||
when the list changes underneath it.</p>
|
||||
<p>The Tool House page never reads or writes <code>?tree=</code>. A <code>toolhouse/…</code> id reaches it only by way of
|
||||
@@ -452,8 +452,8 @@ and the retitle hook registered with the i18n module.</li>
|
||||
<code>rawTreePathOfRoute</code>, <code>treePathOfRoute</code>, the two selection/URL watchers and the unguarded
|
||||
controller-checkbox watcher beside them, <code>landingSelection</code>, <code>applyRouteSelection</code> and
|
||||
<code>syncUrlBack</code>, plus the build-time reveal of a URL-named CSV or CL controller node.</li>
|
||||
<li><code>wwwroot-src/src/composables/useRouteTabs.ts</code> — the tab-to-param sync used by the Tool House and
|
||||
Controller routes, including dormant levels and the keep-alive re-entry canonicalisation.</li>
|
||||
<li><code>wwwroot-src/src/composables/useRouteTabs.ts</code> — the tab-to-param sync the Tool House route uses,
|
||||
including dormant levels and the keep-alive re-entry canonicalisation.</li>
|
||||
<li><code>wwwroot-src/src/pages/ToolHousePage.vue</code> — consumes the shared tab lists, resolves the tool from
|
||||
its path param, and navigates by route name when the tool changes.</li>
|
||||
<li><code>wwwroot-src/src/pages/FileExplorerPage.vue</code> — mirrors the browsed location into the route's
|
||||
|
||||
@@ -125,10 +125,8 @@ Open <a class="xref" href="../execution/index.html">Execution Page</a></li>
|
||||
<li>File Explorer MenuItem (below a separator). See <a href="../util/index.html">Util Pages</a>.</li>
|
||||
<li>Mechanism Builder MenuItem
|
||||
Open <a class="xref" href="../util/mech-builder.html">Mechanism Builder Page</a></li>
|
||||
<li>Legacy-Controller MenuItem (below a separator)
|
||||
Open <a class="xref" href="../legacy-controller.html">Legacy Controller Page</a></li>
|
||||
</ul>
|
||||
<p>The dropdown is not every route the application has. The Machine Tool page stays reachable by URL for its chain-only canvas preview, the Log Viewer is reached by the <code>Show Log</code> button, and the Fixture, Workpiece, Spindle Capability, Mission and Background / Coolant paths resolve as redirects into the two tree pages.</p>
|
||||
<p>The dropdown is not every route the application has. The Machine Tool page stays reachable by URL for its chain-only canvas preview, the Log Viewer is reached by the <code>Show Log</code> button, and the Fixture, Workpiece, Spindle Capability, Mission, Background / Coolant and legacy Controller paths resolve as redirects into the two tree pages.</p>
|
||||
</li>
|
||||
<li><p><a class="xref" href="preference-menu.html">Preference Menu Dropdown</a></p>
|
||||
</li>
|
||||
@@ -205,7 +203,7 @@ watching for project changes itself.</li>
|
||||
<ul>
|
||||
<li>The <a class="xref" href="../execution/index.html">Execution Page</a> is the landing route — <code>/</code> redirects to <code>/execution</code></li>
|
||||
<li>The page URL and panel state are synchronized (bi-directional navigation)</li>
|
||||
<li>There is no Environment dropdown. Machine Tool, Fixture, Workpiece, Controller, Background / Coolant and Spindle Capability are branches of the General Setup page's Control Tree, and Tool House and Execution are pages of their own; the remaining paths resolve as redirects into those pages. The menu bar is therefore <code>Project ▾ | Page ▾ | Preference ▾</code>, and the Controller page is reached from <code>Page ▾</code> as <code>Legacy-Controller</code>.</li>
|
||||
<li>There is no Environment dropdown. Machine Tool, Fixture, Workpiece, Controller, Background / Coolant and Spindle Capability are branches of the General Setup page's Control Tree, and Tool House and Execution are pages of their own; the remaining paths resolve as redirects into those pages. The menu bar is therefore <code>Project ▾ | Page ▾ | Preference ▾</code>.</li>
|
||||
</ul>
|
||||
<h2 id="source-code-path">Source Code Path</h2>
|
||||
<p>See <a class="xref" href="../index.html">HiNC App Anatomy</a> for git repository links.</p>
|
||||
|
||||
@@ -43,10 +43,7 @@
|
||||
<a href="util/index.html" name="util/toc.html" title="Utility Pages">Utility Pages</a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="legacy-controller.html" name="" title="Legacy Controller (HardNcEnv)">Legacy Controller (HardNcEnv)</a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="legacy-controller-settings.html" name="" title="Legacy Controller Settings">Legacy Controller Settings</a>
|
||||
<a href="legacy-controller-settings.html" name="" title="Legacy Controller Model (HardNcEnv)">Legacy Controller Model (HardNcEnv)</a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="by-source/index.html" name="by-source/toc.html" title="By Source Directory">By Source Directory</a>
|
||||
|
||||
@@ -1,2 +1,2 @@
|
||||
|
||||
{"items":[{"name":"Overview","href":"index.html","topicHref":"index.html"},{"name":"Conventions","href":"conventions/index.html","tocHref":"conventions/toc.html","topicHref":"conventions/index.html","homepage":"conventions/index.html"},{"name":"Platform","href":"platform/index.html","tocHref":"platform/toc.html","topicHref":"platform/index.html","homepage":"platform/index.html"},{"name":"App Shell","href":"shell/index.html","tocHref":"shell/toc.html","topicHref":"shell/index.html","homepage":"shell/index.html"},{"name":"Widgets","href":"widget/index.html","tocHref":"widget/toc.html","topicHref":"widget/index.html","homepage":"widget/index.html"},{"name":"Geometry Panels","href":"geom/index.html","tocHref":"geom/toc.html","topicHref":"geom/index.html","homepage":"geom/index.html"},{"name":"Execution Page","href":"execution/index.html","tocHref":"execution/toc.html","topicHref":"execution/index.html","homepage":"execution/index.html"},{"name":"General Setup Page","href":"general-setup/index.html","tocHref":"general-setup/toc.html","topicHref":"general-setup/index.html","homepage":"general-setup/index.html"},{"name":"Tool House Page","href":"tool-house/index.html","tocHref":"tool-house/toc.html","topicHref":"tool-house/index.html","homepage":"tool-house/index.html"},{"name":"Utility Pages","href":"util/index.html","tocHref":"util/toc.html","topicHref":"util/index.html","homepage":"util/index.html"},{"name":"Legacy Controller (HardNcEnv)","href":"legacy-controller.html","topicHref":"legacy-controller.html"},{"name":"Legacy Controller Settings","href":"legacy-controller-settings.html","topicHref":"legacy-controller-settings.html"},{"name":"By Source Directory","href":"by-source/index.html","tocHref":"by-source/toc.html","topicHref":"by-source/index.html","homepage":"by-source/index.html"}]}
|
||||
{"items":[{"name":"Overview","href":"index.html","topicHref":"index.html"},{"name":"Conventions","href":"conventions/index.html","tocHref":"conventions/toc.html","topicHref":"conventions/index.html","homepage":"conventions/index.html"},{"name":"Platform","href":"platform/index.html","tocHref":"platform/toc.html","topicHref":"platform/index.html","homepage":"platform/index.html"},{"name":"App Shell","href":"shell/index.html","tocHref":"shell/toc.html","topicHref":"shell/index.html","homepage":"shell/index.html"},{"name":"Widgets","href":"widget/index.html","tocHref":"widget/toc.html","topicHref":"widget/index.html","homepage":"widget/index.html"},{"name":"Geometry Panels","href":"geom/index.html","tocHref":"geom/toc.html","topicHref":"geom/index.html","homepage":"geom/index.html"},{"name":"Execution Page","href":"execution/index.html","tocHref":"execution/toc.html","topicHref":"execution/index.html","homepage":"execution/index.html"},{"name":"General Setup Page","href":"general-setup/index.html","tocHref":"general-setup/toc.html","topicHref":"general-setup/index.html","homepage":"general-setup/index.html"},{"name":"Tool House Page","href":"tool-house/index.html","tocHref":"tool-house/toc.html","topicHref":"tool-house/index.html","homepage":"tool-house/index.html"},{"name":"Utility Pages","href":"util/index.html","tocHref":"util/toc.html","topicHref":"util/index.html","homepage":"util/index.html"},{"name":"Legacy Controller Model (HardNcEnv)","href":"legacy-controller-settings.html","topicHref":"legacy-controller-settings.html"},{"name":"By Source Directory","href":"by-source/index.html","tocHref":"by-source/toc.html","topicHref":"by-source/index.html","homepage":"by-source/index.html"}]}
|
||||
|
||||
@@ -88,7 +88,7 @@
|
||||
<h1 id="freeform-remover-panel">Freeform Remover Panel</h1>
|
||||
|
||||
<p>The key model is <a class="xref" href="../../../api/Hi.Machining.FreeformRemover.html">FreeformRemover</a>: a cutter whose removal volume comes from two referenced geometries — a non-cutting strut and a cutting shaper — anchored to the holder buckle.</p>
|
||||
<p>This cutter is offered in the Cutter Type selector and nowhere else. There is no Freeform Remover editor here and no freeform-remover endpoint in the backend, so nothing on this surface can create or change one — the shipped caption says as much, naming the WPF client and HiNcRcl.</p>
|
||||
<p>This cutter is offered in the Cutter Type selector and nowhere else. There is no Freeform Remover editor here and no freeform-remover endpoint in the backend, so nothing on this surface can create or change one — the shipped caption says as much, and names HiNcRcl as the place to edit one.</p>
|
||||
<h2 id="layout">Layout</h2>
|
||||
<h3 id="web-layout">Web Layout</h3>
|
||||
<ul>
|
||||
|
||||
@@ -211,7 +211,7 @@ The model <code>UserService</code> is the server-side <code>Environments/UserSer
|
||||
<h5>Note</h5>
|
||||
<p>The fluting type is named loosely on the wire, and every spelling resolves. <code>PUT /{id}/fluting</code> accepts <code>UniformFluting</code> / <code>uniform</code> and <code>FreeFluting</code> / <code>free</code>, and equally <code>UniformContourTray</code> / <code>FreeContourTray</code>. A Control-Tree id whose cutter branch reads <code>…/contours/tray…</code> resolves to the <code>…/contours/fluting…</code> node.</p>
|
||||
</div>
|
||||
<p>One cutter type has no editor here, and the app says so where the type is chosen: the <strong>FreeformRemover</strong>. Selecting it keeps the existing model intact and shows a note — <em>FreeformRemover editor is not yet available in the web frontend. Use the WPF client or HiNcRcl for now.</em></p>
|
||||
<p>One cutter type has no editor here, and the app says so where the type is chosen: the <strong>FreeformRemover</strong>. Selecting it keeps the existing model intact and shows a note — <em>No FreeformRemover editor here. The existing model is kept unchanged; edit one in HiNcRcl.</em></p>
|
||||
<p>Three smaller surfaces are absent for the same reason: the InsertCutter and FluteInnerBeam physics groups, and the <code>CustomSpinningProfile</code> shaper-profile type — the profile tab offers the five APT types (General / Ball / Column / Cone / Taper).</p>
|
||||
<h2 id="see-also">See Also</h2>
|
||||
<ul>
|
||||
|
||||
@@ -184,7 +184,7 @@ actions.</p>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td><code>xml</code></td>
|
||||
<td><code>xml</code>, <code>hincproj</code>, <code>CoatingMaterial</code>, <code>CutterMaterial</code>, <code>Holder</code>, <code>WorkpieceMaterial</code>, <code>mp</code>, <code>MillingPara</code>, <code>SpindleCapability</code>, <code>StickMachiningTool</code>, <code>general-mech</code>, <code>mt</code></td>
|
||||
<td><code>xml</code>, <code>hincproj</code>, <code>CoatingMaterial</code>, <code>CutterMaterial</code>, <code>Holder</code>, <code>WorkpieceMaterial</code>, <code>mp</code>, <code>MillingPara</code>, <code>SpindleCapability</code>, <code>StickMachiningTool</code>, <code>GeneralMechanism</code>, <code>general-mech</code>, <code>MachineTool</code>, <code>mt</code>, <code>Controller</code>, <code>SoftNcRunner</code>, <code>Cutter</code>, <code>CoolantHeatCondition</code>, <code>MachiningToolHouse</code>, <code>Fixture</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>markdown</code></td>
|
||||
|
||||
@@ -111,10 +111,6 @@ server-side Load and Save As through the File Explorer's picker.</li>
|
||||
<li><a href="stl-preview-pane.html">STL Preview Pane</a> — the 3D preview that takes over the File Explorer's
|
||||
editor column for an <code>.stl</code> row: its cancellable load, the rendering connection it owns, and the
|
||||
transform it can bake into the file.</li>
|
||||
<li><a class="xref" href="../legacy-controller.html">Legacy-Controller</a> — the legacy controller screen, reachable from
|
||||
<code>Page → Legacy-Controller</code> below the second separator. The General Setup page's Controller branch
|
||||
is the settings face for the SoftNcRunner; this page stays reachable while it carries settings
|
||||
that tree has no editor for.</li>
|
||||
</ul>
|
||||
<h2 id="where-neighbouring-editors-live">Where Neighbouring Editors Live</h2>
|
||||
<p>Three editors a reader might expect here are shipped surfaces of other pages:</p>
|
||||
|
||||
@@ -108,7 +108,7 @@
|
||||
<li>File Menu
|
||||
<ul>
|
||||
<li>New — discards the current mechanism and starts an empty one with a root anchor.</li>
|
||||
<li>Load… — opens the server file picker (Admin / Project / Resource) filtered to <code>*.GeneralMechanism</code> / <code>*.xml</code>; the backend parses the picked file in place and records its directory so ReLoad can re-read it. <strong>That filter matches none of the shipped mechanisms</strong>, which are named <code>.general-mech</code> beside the machine tool they belong to; the dialog's appended All Files entry is what reaches them, and the backend parses whatever is picked.</li>
|
||||
<li>Load… — opens the server file picker (Admin / Project / Resource) filtered to <code>*.GeneralMechanism</code> / <code>*.general-mech</code> / <code>*.xml</code>; the backend parses the picked file in place and records its directory so ReLoad can re-read it. <code>.GeneralMechanism</code> is the canonical spelling — <code>GeneralMechanism.XName</code>, what this page's Save As writes and what the shipped mechanism inside the <code>Table-B1.default</code> package is named; <code>.general-mech</code> is the older hand-authored spelling case files still carry. The filter is display-only either way, since the backend dispatches on the parsed root element and parses whatever is picked.</li>
|
||||
<li>ReLoad — re-parses the file last loaded (disabled until a file has been loaded). The entry is spelled <code>ReLoad</code>, with the second capital.</li>
|
||||
<li>Save As General Mechanism — writes a <code>.GeneralMechanism</code> XML to the picked server location and retargets ReLoad at it.</li>
|
||||
<li>Save As Machine Tool — wraps the mechanism in a <a class="xref" href="../../api/Hi.NcMech.Xyzabc.GeneralXyzabcMachineTool.html">GeneralXyzabcMachineTool</a> and writes a <code>.MachineTool</code> XML to the picked server location, leaving the open-mechanism pointer where it is. The envelope is the Xyzabc machine tool; the menu entry names neither that nor the file type.</li>
|
||||
|
||||
@@ -89,8 +89,8 @@
|
||||
|
||||
<p>NumericInput is the single-value numeric field the rest of the web application embeds. It has no
|
||||
route and no Control-Tree node of its own: it is reached only through the editors that host it,
|
||||
and those span the equipment and mission trees, the Tool House tool editors, the Legacy Controller
|
||||
tabs, the transformer and geometry editors and the Preference menu. The rule for carrying <code>NaN</code> and
|
||||
and those span the equipment and mission trees, the Tool House tool editors, the transformer and
|
||||
geometry editors and the Preference menu. The rule for carrying <code>NaN</code> and
|
||||
the infinities across the JSON boundary is stated once in
|
||||
<a class="xref" href="../conventions/numeric-io-utilities.html">Numeric Input/Output</a>; this page is the widget that implements
|
||||
the client end of it.</p>
|
||||
|
||||
@@ -143,7 +143,7 @@
|
||||
<p>The component is generic over the radio <code>value</code> type, so <code>RenderingMode</code> / <code>HolderRenderingMode</code> / etc. stay fully typed at the call site. Besides <code>groups</code> it accepts <code>label</code>, <code>disable</code>, <code>title</code>, <code>minWidthPx</code> (default 220), <code>size</code> (default <code>sm</code>), <code>contentClass</code> and <code>compact</code>. <code>compact</code> is a tighter-than-dense row mode, used by the General Setup and Tool House panels for their long option lists; the General Setup, Tool House and Execution callers pass <code>content-class="bg-white"</code> to opt out of Quasar's transparent menu.</p>
|
||||
<h3 id="hinc-2025-webservice-quasar-cli-spa">HiNC-2025-webservice (Quasar CLI SPA)</h3>
|
||||
<ul>
|
||||
<li><code>wwwroot-src/src/components/widgets/DisplayOptionsMenu.vue</code> — the shared <code><q-btn-dropdown></code> + <code><q-list></code> implementation behind four of the app's five Scene menus. The Controller viewer is the exception: <code>wwwroot-src/src/components/controller/ControllerExtendedToolBar.vue</code> builds its Scene dropdown inline against the same <code>/api/rendering-flags</code> surface.</li>
|
||||
<li><code>wwwroot-src/src/components/widgets/DisplayOptionsMenu.vue</code> — the shared <code><q-btn-dropdown></code> + <code><q-list></code> implementation behind all four of the app's Scene menus.</li>
|
||||
<li>Callers (each reads a <code>DisplayGroup[]</code> computed from its page-local state and forwards <code>onUpdate</code> to its existing handlers):
|
||||
<ul>
|
||||
<li><code>wwwroot-src/src/components/execution/ExecutionExtendedToolBar.vue</code></li>
|
||||
@@ -158,7 +158,7 @@
|
||||
<p>See <a class="xref" href="../index.html">HiNC App Anatomy</a> for git repository links.</p>
|
||||
<p>HiNC-2025-webservice (Quasar CLI SPA):</p>
|
||||
<ul>
|
||||
<li><code>wwwroot-src/src/components/RenderingCanvasToolBar.vue</code> — the <code>View ▾</code> menu. Eight callers embed it, one per canvas: <code>wwwroot-src/src/pages/ExecutionPage.vue</code> (teleported into the canvas panel's header, beside <code>ExecutionExtendedToolBar</code>), <code>wwwroot-src/src/pages/ControllerPage.vue</code> (beside <code>ControllerExtendedToolBar</code>), <code>wwwroot-src/src/pages/MachineToolPage.vue</code>, <code>wwwroot-src/src/pages/MechBuilderPage.vue</code>, <code>wwwroot-src/src/components/mech/EquipmentSetupPanel.vue</code> (the General Setup canvas column, mounted by <code>wwwroot-src/src/pages/GeneralSetupPage.vue</code>), <code>wwwroot-src/src/components/toolhouse/ToolHouseSetupPanel.vue</code> (mounted by <code>wwwroot-src/src/pages/ToolHousePage.vue</code>), <code>wwwroot-src/src/components/StlPreviewPane.vue</code> (the File Explorer preview pane, mounted by <code>wwwroot-src/src/components/FileExplorer.vue</code>) and <code>wwwroot-src/src/components/execution/StepVolumePanel.vue</code> (the CWE footprint canvas, teleported into its host expansion's header). Four of those sit beside a <code>Scene ▾</code> menu — the Execution, General Setup, Tool House and STL preview canvases; the Machine Tool, Mechanism Builder and CWE canvases carry the <code>View ▾</code> menu alone, and the Controller viewer pairs it with an inlined Scene dropdown.</li>
|
||||
<li><code>wwwroot-src/src/components/RenderingCanvasToolBar.vue</code> — the <code>View ▾</code> menu. Seven callers embed it, one per canvas: <code>wwwroot-src/src/pages/ExecutionPage.vue</code> (teleported into the canvas panel's header, beside <code>ExecutionExtendedToolBar</code>), <code>wwwroot-src/src/pages/MachineToolPage.vue</code>, <code>wwwroot-src/src/pages/MechBuilderPage.vue</code>, <code>wwwroot-src/src/components/mech/EquipmentSetupPanel.vue</code> (the General Setup canvas column, mounted by <code>wwwroot-src/src/pages/GeneralSetupPage.vue</code>), <code>wwwroot-src/src/components/toolhouse/ToolHouseSetupPanel.vue</code> (mounted by <code>wwwroot-src/src/pages/ToolHousePage.vue</code>), <code>wwwroot-src/src/components/StlPreviewPane.vue</code> (the File Explorer preview pane, mounted by <code>wwwroot-src/src/components/FileExplorer.vue</code>) and <code>wwwroot-src/src/components/execution/StepVolumePanel.vue</code> (the CWE footprint canvas, teleported into its host expansion's header). Four of those sit beside a <code>Scene ▾</code> menu — the Execution, General Setup, Tool House and STL preview canvases; the Machine Tool, Mechanism Builder and CWE canvases carry the <code>View ▾</code> menu alone.</li>
|
||||
<li><code>wwwroot-src/src/components/widgets/DisplayOptionsMenu.vue</code> — schema-driven dropdown described above.</li>
|
||||
<li><code>wwwroot-src/src/components/RenderingCanvas.vue</code> — SignalR-hosted WebSocket canvas whose exposed <code>setView</code> / <code>setViewTo*View</code> methods the tool bar calls (see <a class="xref" href="../conventions/rendering-canvas-web-service.html">Rendering Canvas on Web Service</a>).</li>
|
||||
<li><code>wwwroot-src/src/i18n/en/widgets.ts</code> — the <code>widgets.canvas.*</code> keys: <code>view</code>, the seven preset labels, and <code>scene</code>.</li>
|
||||
@@ -166,7 +166,7 @@
|
||||
<ul>
|
||||
<li><code>Disp/RenderingHub.cs</code> — the <code>SetView(string)</code> hub method that maps each preset name onto engine calls.</li>
|
||||
<li><code>Disp/RenderingService.cs</code> — <code>GetOrCreateEngine(connectionId)</code>, the per-connection <code>DispEngine</code> store the hub resolves against.</li>
|
||||
<li><code>Common/RenderingFlagsController.cs</code> — the <code>/api/rendering-flags</code> surface (<code>GET</code>, <code>POST update</code>, <code>POST batch</code>) behind the Execution page's Scene menu and the Controller viewer's inlined one, wrapped by <code>wwwroot-src/src/api/renderingFlags.ts</code>. It reads and writes <code>ExecutionDisplayee.RenderingFlagBitArray</code> through <code>ProjectDisplayeeService</code>.</li>
|
||||
<li><code>Common/RenderingFlagsController.cs</code> — the <code>/api/rendering-flags</code> surface (<code>GET</code>, <code>POST update</code>, <code>POST batch</code>) behind the Execution page's Scene menu, wrapped by <code>wwwroot-src/src/api/renderingFlags.ts</code>. It reads and writes <code>ExecutionDisplayee.RenderingFlagBitArray</code> through <code>ProjectDisplayeeService</code>.</li>
|
||||
<li><code>wwwroot-src/src/api/equipmentSetup.ts</code>, <code>wwwroot-src/src/api/toolHouse.ts</code> and <code>wwwroot-src/src/api/stlPreview.ts</code> — the typed wrappers the other three Scene menus post through.</li>
|
||||
</ul>
|
||||
</li>
|
||||
|
||||
@@ -1943,7 +1943,12 @@ otherwise falls back to <a class="xref" href="Hi.Numerical.HardNcEnv.html#Hi_Num
|
||||
|
||||
</h3>
|
||||
|
||||
<div class="markdown level1 summary"><p>Closes the current project.</p>
|
||||
<div class="markdown level1 summary"><p>Closes the current project. Like the other five project-file operations
|
||||
this runs under <a class="xref" href="https://learn.microsoft.com/dotnet/api/system.action">RunExclusiveProjectFileOp(Action)</a>: a close arriving
|
||||
while a load or a save holds the file is cancelled with
|
||||
<a class="xref" href="Hi.MachiningProcs.ProjectFileBusyException.html">ProjectFileBusyException</a> instead of interleaving with it.
|
||||
It was the one operation left outside the gate, which is why
|
||||
<code>ProjectController.CloseProject</code>'s 409 handler could never fire.</p>
|
||||
</div>
|
||||
<div class="markdown level1 conceptual"></div>
|
||||
|
||||
@@ -1960,6 +1965,12 @@ otherwise falls back to <a class="xref" href="Hi.Numerical.HardNcEnv.html#Hi_Num
|
||||
|
||||
|
||||
|
||||
<h4 class="section">Exceptions</h4>
|
||||
<dl class="parameters">
|
||||
<dt><a class="xref" href="Hi.MachiningProcs.ProjectFileBusyException.html">ProjectFileBusyException</a></dt>
|
||||
<dd><p>Another project-file operation is in progress.</p>
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1058,8 +1058,10 @@ Internal Use Only.</p>
|
||||
<div class="markdown level1 summary"><p>Emit one-shot session <code>ConfigurationError</code>s naming the root cause when the
|
||||
currently equipped tool's <a class="xref" href="Hi.Milling.Cutters.MillingCutter.html">MillingCutter</a> has an unreasonable
|
||||
upper-beam / shank geometry (see
|
||||
<a class="xref" href="Hi.Milling.Cutters.MillingCutter.html#Hi_Milling_Cutters_MillingCutter_GetUpperBeamGeometryIssues">GetUpperBeamGeometryIssues()</a>) — e.g. an
|
||||
<a class="xref" href="Hi.Milling.Cutters.MillingCutter.html#Hi_Milling_Cutters_MillingCutter_ReportUpperBeamGeometryIssues_System_IProgress_Hi_Common_Messages_IMessage__System_Object_">ReportUpperBeamGeometryIssues(IProgress<IMessage>, object)</a>) — e.g. an
|
||||
<code>ExtendedCylinder</code> beam whose <code>FullLength</code> sits below the flute height.
|
||||
The error's wording is the cutter's own literal emit, shared with the web API's
|
||||
edit-time warnings, so the tool it belongs to rides in the detail payload.
|
||||
Before this check, such a setting surfaced only as a per-step
|
||||
<code>NullReferenceException</code> cascade inside the thermal physics, with nothing
|
||||
naming the beam. Additionally emits a <code>Cutter-Shank–ThermalModelUnavailable</code>
|
||||
|
||||
@@ -104,6 +104,7 @@ Class SetupController
|
||||
<div class="codewrapper">
|
||||
<pre><code class="lang-csharp hljs">[ApiController]
|
||||
[Route("api/[controller]/[action]")]
|
||||
[ProducesResponseType(typeof(ApiActionResult), 409)]
|
||||
public class SetupController : ControllerBase</code></pre>
|
||||
</div>
|
||||
|
||||
@@ -700,6 +701,13 @@ public class SetupController : ControllerBase</code></pre>
|
||||
|
||||
|
||||
|
||||
<h2 id="Hi_MachiningProcs_SetupController_remarks">Remarks</h2>
|
||||
<div class="markdown level0 remarks"><p>Project-level surface: every action but <a class="xref" href="Hi.MachiningProcs.SetupController.html#Hi_MachiningProcs_SetupController_LoadProject_System_String_">LoadProject(string)</a> writes through members
|
||||
that are null until a project is open. Without the filter those writes do not throw — the
|
||||
serialization helpers are extension methods and the setup-face setters return early on a
|
||||
null <code>SetupEquipment</code> — so the caller got HTTP 200 for a save that saved nothing.
|
||||
The filter turns that silent false-success into an honest HTTP 409 + <a class="xref" href="Hi.MachiningProcs.ApiActionResult.html">ApiActionResult</a>.</p>
|
||||
</div>
|
||||
|
||||
|
||||
<h2 class="section" id="constructors">Constructors
|
||||
@@ -872,6 +880,9 @@ public void LoadProject(string filePath)</code></pre>
|
||||
|
||||
|
||||
|
||||
<h4 class="section" id="Hi_MachiningProcs_SetupController_LoadProject_System_String__remarks">Remarks</h4>
|
||||
<div class="markdown level1 remarks"><p>This is how a project comes into being, so it runs before one exists.</p>
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -2472,17 +2472,12 @@ session paths read the value from
|
||||
|
||||
</h3>
|
||||
|
||||
<div class="markdown level1 summary"><p>Collects human-readable configuration issues on the upper-beam / shank
|
||||
geometry — the settings that used to surface only as an opaque per-step
|
||||
<a class="xref" href="https://learn.microsoft.com/dotnet/api/system.nullreferenceexception">NullReferenceException</a> cascade inside the thermal physics
|
||||
(e.g. an <a class="xref" href="Hi.Geom.ExtendedCylinder.html">ExtendedCylinder</a> beam whose
|
||||
<a class="xref" href="Hi.Geom.ExtendedCylinder.html#Hi_Geom_ExtendedCylinder_FullLength">FullLength</a> is below the flute height, so the
|
||||
shank solid inverts and <span class="xref">Hi.Milling.Cutters.MillingCutter.GetShankThermalZrList()</span> cannot build).
|
||||
Returns <code>(Id, Message)</code> pairs following the structured-id convention of
|
||||
the <code>IMessage</code> channel (e.g. <code>Cutter-UpperBeam–ExtendedCylinderFullLengthTooShort</code>);
|
||||
empty when no upper beam is configured (a legal state — physics runs without
|
||||
a shank) or the beam is consistent. Shared by the physics runner (tool-change
|
||||
<code>ConfigurationError</code>) and the web API (post-edit validation warnings).</p>
|
||||
<div class="markdown level1 summary"><p>The issues <a class="xref" href="Hi.Milling.Cutters.MillingCutter.html#Hi_Milling_Cutters_MillingCutter_ReportUpperBeamGeometryIssues_System_IProgress_Hi_Common_Messages_IMessage__System_Object_">ReportUpperBeamGeometryIssues(IProgress<IMessage>, object)</a> would report, as
|
||||
<code>(Id, Message)</code> pairs — the id in the structured-id convention of the
|
||||
<code>IMessage</code> channel (e.g. <code>Cutter-UpperBeam–ExtendedCylinderFullLengthTooShort</code>),
|
||||
the message its rendered English notification. Empty when no upper beam is
|
||||
configured or the beam is consistent. The web API's edit-time view of the same
|
||||
detection (<code>warnings[]</code> of the upper-beam endpoints).</p>
|
||||
</div>
|
||||
<div class="markdown level1 conceptual"></div>
|
||||
|
||||
@@ -2624,6 +2619,62 @@ and chains <code>Reg(factory)</code> on dependents. Idempotent.</p>
|
||||
|
||||
|
||||
|
||||
<a id="Hi_Milling_Cutters_MillingCutter_ReportUpperBeamGeometryIssues_" data-uid="Hi.Milling.Cutters.MillingCutter.ReportUpperBeamGeometryIssues*"></a>
|
||||
|
||||
<h3 id="Hi_Milling_Cutters_MillingCutter_ReportUpperBeamGeometryIssues_System_IProgress_Hi_Common_Messages_IMessage__System_Object_" data-uid="Hi.Milling.Cutters.MillingCutter.ReportUpperBeamGeometryIssues(System.IProgress{Hi.Common.Messages.IMessage},System.Object)">
|
||||
ReportUpperBeamGeometryIssues(IProgress<IMessage>, object)
|
||||
|
||||
</h3>
|
||||
|
||||
<div class="markdown level1 summary"><p>Reports the configuration issue on the upper-beam / shank geometry — the
|
||||
settings that used to surface only as an opaque per-step
|
||||
<a class="xref" href="https://learn.microsoft.com/dotnet/api/system.nullreferenceexception">NullReferenceException</a> cascade inside the thermal physics
|
||||
(e.g. an <a class="xref" href="Hi.Geom.ExtendedCylinder.html">ExtendedCylinder</a> beam whose
|
||||
<a class="xref" href="Hi.Geom.ExtendedCylinder.html#Hi_Geom_ExtendedCylinder_FullLength">FullLength</a> is below the flute height, so the
|
||||
shank solid inverts and <span class="xref">Hi.Milling.Cutters.MillingCutter.GetShankThermalZrList()</span> cannot build) —
|
||||
as a <code>ConfigurationError</code> on <code class="paramref">sink</code>, at most one per
|
||||
call. Nothing is reported when no upper beam is configured (a legal state —
|
||||
physics runs without a shank) or the beam is consistent. The wordings live
|
||||
here, one literal id and one literal template per emit, because the
|
||||
engine-message gate reads both off the call: the physics runner hands in its
|
||||
step-anchored sink at tool change, the web API a <a class="xref" href="Hi.Common.Messages.MessageCollector.html">MessageCollector</a>
|
||||
through <a class="xref" href="Hi.Milling.Cutters.MillingCutter.html#Hi_Milling_Cutters_MillingCutter_GetUpperBeamGeometryIssues">GetUpperBeamGeometryIssues()</a> (post-edit validation warnings).</p>
|
||||
</div>
|
||||
<div class="markdown level1 conceptual"></div>
|
||||
|
||||
<div class="codewrapper">
|
||||
<pre><code class="lang-csharp hljs">public int ReportUpperBeamGeometryIssues(IProgress<IMessage> sink, object detail = null)</code></pre>
|
||||
</div>
|
||||
|
||||
<h4 class="section">Parameters</h4>
|
||||
<dl class="parameters">
|
||||
<dt><code>sink</code> <a class="xref" href="https://learn.microsoft.com/dotnet/api/system.iprogress-1">IProgress</a><<a class="xref" href="Hi.Common.Messages.IMessage.html">IMessage</a>></dt>
|
||||
<dd><p>Destination of the error; null is a no-op.</p>
|
||||
</dd>
|
||||
<dt><code>detail</code> <a class="xref" href="https://learn.microsoft.com/dotnet/api/system.object">object</a></dt>
|
||||
<dd><p>Optional detail payload attached to the error — the runner
|
||||
names the tool here, since the templates are shared with the web API and cannot
|
||||
carry a tool prefix.</p>
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
<h4 class="section">Returns</h4>
|
||||
<dl class="parameters">
|
||||
<dt><a class="xref" href="https://learn.microsoft.com/dotnet/api/system.int32">int</a></dt>
|
||||
<dd><p>The number of issues detected, 0 or 1 — reported on <code class="paramref">sink</code> when it is non-null.</p>
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<a id="Hi_Milling_Cutters_MillingCutter_SetShaperStlResolution_" data-uid="Hi.Milling.Cutters.MillingCutter.SetShaperStlResolution*"></a>
|
||||
|
||||
<h3 id="Hi_Milling_Cutters_MillingCutter_SetShaperStlResolution_Hi_Geom_Resolution_PolarResolution2d_" data-uid="Hi.Milling.Cutters.MillingCutter.SetShaperStlResolution(Hi.Geom.Resolution.PolarResolution2d)">
|
||||
|
||||
+3
-2
@@ -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&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'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&ndash;Unsupported, or HeidenhainFn&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'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–Unsupported</code> warning names the opcode. Two
|
||||
single warning names the opcode — <code>HeidenhainFn–Unsupported</code>, or
|
||||
<code>HeidenhainFn–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
|
||||
|
||||
@@ -190,7 +190,8 @@ Extends <a class="xref" href="Hi.NcParsers.ParsingSyntaxs.TagAssignmentSyntax.ht
|
||||
<dd><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–Unsupported</code> warning names the opcode. Two
|
||||
single warning names the opcode — <code>HeidenhainFn–Unsupported</code>, or
|
||||
<code>HeidenhainFn–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
|
||||
|
||||
@@ -6,7 +6,7 @@
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
<meta name="title" content="Class RadiusCompInterference | HiAPI-C# 2025 ">
|
||||
|
||||
<meta name="description" content="Classifies cutter-compensation interference — the case a real control refuses under G41/G42: the compensated tool path runs against the programmed direction because the offset radius is larger than the inner feature it has to follow (an inner arc smaller than the offset, a groove bottom narrower than the tool). Fanuc stops with alarm PS0041 INTERFERENCE IN CUTTER COMPENSATION; Heidenhain and Siemens have equivalents. The simulation has no interference check and keeps running the swapped-side path — so a program that simulates cleanly can still stop on the machine, and a wrongly filled D row (the tool radius entered against a tool-centre CAM path that expects wear only) shows up as an overcut instead of an alarm. The diagnostics built from this class exist to close that gap; they never change the path. Today the gate is meaningful on the XY plane (G17) only: both compensation engines build the perpendicular as Z × axis whatever plane is selected, so a G18/G19 region is neither compensated in its own plane nor checked here — the planeNormalDir parameters are ready for the day the engines pass the selected plane through.">
|
||||
<meta name="description" content="Classifies cutter-compensation interference — the case a real control refuses under G41/G42: the compensated tool path runs against the programmed direction because the offset radius is larger than the inner feature it has to follow (an inner arc smaller than the offset, a groove bottom narrower than the tool). Fanuc stops with alarm PS0041 INTERFERENCE IN CUTTER COMPENSATION; Heidenhain and Siemens have equivalents. The simulation has no interference check and keeps running the swapped-side path — so a program that simulates cleanly can still stop on the machine, and a wrongly filled D row (the tool radius entered against a tool-centre CAM path that expects wear only) shows up as an overcut instead of an alarm. The diagnostics built from this class exist to close that gap; they never change the path. The gate works on the selected G17/G18/G19 plane: both engines pass the block's plane through planeNormalDir, and the in-plane projections below use it (neither engine checks a polar G12.1 block). Until 2026-09-11 both engines built the perpendicular as Z × axis whatever plane was selected, so a G18/G19 region was offset along its normal and could never be judged here.">
|
||||
<link rel="icon" href="../img/HiAPI.favicon.ico">
|
||||
<link rel="stylesheet" href="../public/docfx.min.css">
|
||||
<link rel="stylesheet" href="../public/main.css">
|
||||
@@ -110,11 +110,12 @@ radius entered against a tool-centre CAM path that expects wear only)
|
||||
shows up as an overcut instead of an alarm. The diagnostics built from
|
||||
this class exist to close that gap; they never change the path.</p>
|
||||
<p>
|
||||
Today the gate is meaningful on the XY plane (G17) only: both
|
||||
compensation engines build the perpendicular as <code>Z × axis</code>
|
||||
whatever plane is selected, so a G18/G19 region is neither compensated
|
||||
in its own plane nor checked here — the <code>planeNormalDir</code> parameters
|
||||
are ready for the day the engines pass the selected plane through.
|
||||
The gate works on the selected G17/G18/G19 plane: both engines pass
|
||||
the block's plane through <code>planeNormalDir</code>, and the in-plane
|
||||
projections below use it (neither engine checks a polar G12.1 block).
|
||||
Until 2026-09-11 both engines built the perpendicular as
|
||||
<code>Z × axis</code> whatever plane was selected, so a G18/G19 region was
|
||||
offset along its normal and could never be judged here.
|
||||
</p>
|
||||
</div>
|
||||
<div class="markdown conceptual"></div>
|
||||
|
||||
@@ -0,0 +1,285 @@
|
||||
<!DOCTYPE html>
|
||||
<html>
|
||||
<head>
|
||||
<meta charset="utf-8">
|
||||
<title>Class RadiusCompPlaneChange | HiAPI-C# 2025 </title>
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
<meta name="title" content="Class RadiusCompPlaneChange | HiAPI-C# 2025 ">
|
||||
|
||||
<meta name="description" content="Classifies a plane selection (G17/G18/G19) that arrives while cutter radius compensation is still active — the case a real control refuses. Fanuc stops with alarm PS0037 CAN NOT CHANGE PLANE IN CRC, which covers both a plane code inside the compensation mode and a plane code sharing its block with the G40 that cancels it; Siemens and Heidenhain have equivalents. Neither engine can honour such a change: the corner between the two blocks is built from one block's running axis on the old plane and the other's on the new one, so the path around the change mixes two planes — and the block after it is offset on a plane the block before it never saw. The diagnostics built from this class exist to name that; they never change the path. The check is on the plane actually resolving differently from the previous block's, so a plane code that re-selects the plane already in force stays silent, as does the plane code on the block that starts the region (a control accepts that one — compensation is not active yet).">
|
||||
<link rel="icon" href="../img/HiAPI.favicon.ico">
|
||||
<link rel="stylesheet" href="../public/docfx.min.css">
|
||||
<link rel="stylesheet" href="../public/main.css">
|
||||
<meta name="docfx:navrel" content="../toc.html">
|
||||
<meta name="docfx:tocrel" content="toc.html">
|
||||
|
||||
<meta name="docfx:rel" content="../">
|
||||
|
||||
|
||||
|
||||
<meta name="loc:inThisArticle" content="In this article">
|
||||
<meta name="loc:searchResultsCount" content="{count} results for "{query}"">
|
||||
<meta name="loc:searchNoResults" content="No results for "{query}"">
|
||||
<meta name="loc:tocFilter" content="Filter by title">
|
||||
<meta name="loc:nextArticle" content="Next">
|
||||
<meta name="loc:prevArticle" content="Previous">
|
||||
<meta name="loc:themeLight" content="Light">
|
||||
<meta name="loc:themeDark" content="Dark">
|
||||
<meta name="loc:themeAuto" content="Auto">
|
||||
<meta name="loc:changeTheme" content="Change theme">
|
||||
<meta name="loc:copy" content="Copy">
|
||||
<meta name="loc:downloadPdf" content="Download PDF">
|
||||
|
||||
<script type="module" src="./../public/docfx.min.js"></script>
|
||||
|
||||
<script>
|
||||
const theme = localStorage.getItem('theme') || 'auto'
|
||||
document.documentElement.setAttribute('data-bs-theme', theme === 'auto' ? (window.matchMedia('(prefers-color-scheme: dark)').matches ? 'dark' : 'light') : theme)
|
||||
</script>
|
||||
|
||||
</head>
|
||||
|
||||
<body class="tex2jax_ignore" data-layout="" data-yaml-mime="ManagedReference">
|
||||
<header class="bg-body border-bottom">
|
||||
<nav id="autocollapse" class="navbar navbar-expand-md" role="navigation">
|
||||
<div class="container-xxl flex-nowrap">
|
||||
<a class="navbar-brand" href="../index.html">
|
||||
<img id="logo" class="svg" src="../img/HiAPI.logo.png" alt="">
|
||||
|
||||
</a>
|
||||
<button class="btn btn-lg d-md-none border-0" type="button" data-bs-toggle="collapse" data-bs-target="#navpanel" aria-controls="navpanel" aria-expanded="false" aria-label="Toggle navigation">
|
||||
<i class="bi bi-three-dots"></i>
|
||||
</button>
|
||||
<div class="collapse navbar-collapse" id="navpanel">
|
||||
<div id="navbar">
|
||||
<form class="search" role="search" id="search">
|
||||
<i class="bi bi-search"></i>
|
||||
<input class="form-control" id="search-query" type="search" disabled placeholder="Search" autocomplete="off" aria-label="Search">
|
||||
</form>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
</nav>
|
||||
</header>
|
||||
|
||||
<main class="container-xxl">
|
||||
<div class="toc-offcanvas">
|
||||
<div class="offcanvas-md offcanvas-start" tabindex="-1" id="tocOffcanvas" aria-labelledby="tocOffcanvasLabel">
|
||||
<div class="offcanvas-header">
|
||||
<h5 class="offcanvas-title" id="tocOffcanvasLabel">Table of Contents</h5>
|
||||
<button type="button" class="btn-close" data-bs-dismiss="offcanvas" data-bs-target="#tocOffcanvas" aria-label="Close"></button>
|
||||
</div>
|
||||
<div class="offcanvas-body">
|
||||
<nav class="toc" id="toc"></nav>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div class="content">
|
||||
<div class="actionbar">
|
||||
<button class="btn btn-lg border-0 d-md-none" type="button" data-bs-toggle="offcanvas" data-bs-target="#tocOffcanvas" aria-controls="tocOffcanvas" aria-expanded="false" aria-label="Show table of contents">
|
||||
<i class="bi bi-list"></i>
|
||||
</button>
|
||||
|
||||
<nav id="breadcrumb"></nav>
|
||||
</div>
|
||||
|
||||
<article data-uid="Hi.NcParsers.RadiusCompPlaneChange">
|
||||
|
||||
|
||||
|
||||
<h1 id="Hi_NcParsers_RadiusCompPlaneChange" data-uid="Hi.NcParsers.RadiusCompPlaneChange" class="text-break">
|
||||
Class RadiusCompPlaneChange
|
||||
</h1>
|
||||
|
||||
<div class="facts text-secondary">
|
||||
<dl><dt>Namespace</dt><dd><a class="xref" href="Hi.html">Hi</a>.<a class="xref" href="Hi.NcParsers.html">NcParsers</a></dd></dl>
|
||||
<dl><dt>Assembly</dt><dd>HiMech.dll</dd></dl>
|
||||
</div>
|
||||
|
||||
<div class="markdown summary"><p>Classifies a plane selection (G17/G18/G19) that arrives while cutter
|
||||
radius compensation is still active — the case a real control refuses.
|
||||
Fanuc stops with alarm PS0037 CAN NOT CHANGE PLANE IN CRC, which covers
|
||||
both a plane code inside the compensation mode and a plane code sharing
|
||||
its block with the G40 that cancels it; Siemens and Heidenhain have
|
||||
equivalents. Neither engine can honour such a change: the corner between
|
||||
the two blocks is built from one block's running axis on the old plane
|
||||
and the other's on the new one, so the path around the change mixes two
|
||||
planes — and the block after it is offset on a plane the block before it
|
||||
never saw. The diagnostics built from this class exist to name that;
|
||||
they never change the path.</p>
|
||||
<p>
|
||||
The check is on the plane actually resolving differently from the
|
||||
previous block's, so a plane code that re-selects the plane already in
|
||||
force stays silent, as does the plane code on the block that starts the
|
||||
region (a control accepts that one — compensation is not active yet).
|
||||
</p>
|
||||
</div>
|
||||
<div class="markdown conceptual"></div>
|
||||
|
||||
<div class="codewrapper">
|
||||
<pre><code class="lang-csharp hljs">public static class RadiusCompPlaneChange</code></pre>
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
||||
<dl class="typelist inheritance">
|
||||
<dt>Inheritance</dt>
|
||||
<dd>
|
||||
<div><a class="xref" href="https://learn.microsoft.com/dotnet/api/system.object">object</a></div>
|
||||
<div><span class="xref">RadiusCompPlaneChange</span></div>
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
|
||||
|
||||
<dl class="typelist inheritedMembers">
|
||||
<dt>Inherited Members</dt>
|
||||
<dd>
|
||||
<div>
|
||||
<a class="xref" href="https://learn.microsoft.com/dotnet/api/system.object.equals#system-object-equals(system-object)">object.Equals(object)</a>
|
||||
</div>
|
||||
<div>
|
||||
<a class="xref" href="https://learn.microsoft.com/dotnet/api/system.object.equals#system-object-equals(system-object-system-object)">object.Equals(object, object)</a>
|
||||
</div>
|
||||
<div>
|
||||
<a class="xref" href="https://learn.microsoft.com/dotnet/api/system.object.gethashcode">object.GetHashCode()</a>
|
||||
</div>
|
||||
<div>
|
||||
<a class="xref" href="https://learn.microsoft.com/dotnet/api/system.object.gettype">object.GetType()</a>
|
||||
</div>
|
||||
<div>
|
||||
<a class="xref" href="https://learn.microsoft.com/dotnet/api/system.object.memberwiseclone">object.MemberwiseClone()</a>
|
||||
</div>
|
||||
<div>
|
||||
<a class="xref" href="https://learn.microsoft.com/dotnet/api/system.object.referenceequals">object.ReferenceEquals(object, object)</a>
|
||||
</div>
|
||||
<div>
|
||||
<a class="xref" href="https://learn.microsoft.com/dotnet/api/system.object.tostring">object.ToString()</a>
|
||||
</div>
|
||||
</dd></dl>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<h2 class="section" id="fields">Fields
|
||||
</h2>
|
||||
|
||||
|
||||
|
||||
<h3 id="Hi_NcParsers_RadiusCompPlaneChange_DiagnosticId" data-uid="Hi.NcParsers.RadiusCompPlaneChange.DiagnosticId">
|
||||
DiagnosticId
|
||||
|
||||
</h3>
|
||||
|
||||
<div class="markdown level1 summary"><p>Diagnostic id shared by the SoftNc and HardNc compensation paths.</p>
|
||||
</div>
|
||||
<div class="markdown level1 conceptual"></div>
|
||||
|
||||
<div class="codewrapper">
|
||||
<pre><code class="lang-csharp hljs">public const string DiagnosticId = "RadiusComp--PlaneChangeInRegion"</code></pre>
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
||||
<h4 class="section">Field Value</h4>
|
||||
<dl class="parameters">
|
||||
<dt><a class="xref" href="https://learn.microsoft.com/dotnet/api/system.string">string</a></dt>
|
||||
<dd></dd>
|
||||
</dl>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<h2 class="section" id="methods">Methods
|
||||
</h2>
|
||||
|
||||
|
||||
<a id="Hi_NcParsers_RadiusCompPlaneChange_TryDescribe_" data-uid="Hi.NcParsers.RadiusCompPlaneChange.TryDescribe*"></a>
|
||||
|
||||
<h3 id="Hi_NcParsers_RadiusCompPlaneChange_TryDescribe_System_String_System_String_System_String_System_String__System_Collections_Generic_Dictionary_System_String_System_Object___" data-uid="Hi.NcParsers.RadiusCompPlaneChange.TryDescribe(System.String,System.String,System.String,System.String@,System.Collections.Generic.Dictionary{System.String,System.Object}@)">
|
||||
TryDescribe(string, string, string, out string, out Dictionary<string, object>)
|
||||
|
||||
</h3>
|
||||
|
||||
<div class="markdown level1 summary"><p>Describes a plane change inside a compensation region: returns the
|
||||
constant notification <code class="paramref">text</code> and a value-carrying
|
||||
<code class="paramref">detail</code> when <code class="paramref">fromPlane</code> and
|
||||
<code class="paramref">toPlane</code> differ, and false when they agree (a
|
||||
re-select of the plane already in force) or either is unknown.</p>
|
||||
</div>
|
||||
<div class="markdown level1 conceptual"></div>
|
||||
|
||||
<div class="codewrapper">
|
||||
<pre><code class="lang-csharp hljs">public static bool TryDescribe(string fromPlane, string toPlane, string compensationTerm, out string text, out Dictionary<string, object> detail)</code></pre>
|
||||
</div>
|
||||
|
||||
<h4 class="section">Parameters</h4>
|
||||
<dl class="parameters">
|
||||
<dt><code>fromPlane</code> <a class="xref" href="https://learn.microsoft.com/dotnet/api/system.string">string</a></dt>
|
||||
<dd><p>Plane code in force on the previous block (G17/G18/G19).</p>
|
||||
</dd>
|
||||
<dt><code>toPlane</code> <a class="xref" href="https://learn.microsoft.com/dotnet/api/system.string">string</a></dt>
|
||||
<dd><p>Plane code this block resolves to.</p>
|
||||
</dd>
|
||||
<dt><code>compensationTerm</code> <a class="xref" href="https://learn.microsoft.com/dotnet/api/system.string">string</a></dt>
|
||||
<dd><p>The G code the region runs under (G41/G42).</p>
|
||||
</dd>
|
||||
<dt><code>text</code> <a class="xref" href="https://learn.microsoft.com/dotnet/api/system.string">string</a></dt>
|
||||
<dd><p>Constant notification text (fold-stable), or null.</p>
|
||||
</dd>
|
||||
<dt><code>detail</code> <a class="xref" href="https://learn.microsoft.com/dotnet/api/system.collections.generic.dictionary-2">Dictionary</a><<a class="xref" href="https://learn.microsoft.com/dotnet/api/system.string">string</a>, <a class="xref" href="https://learn.microsoft.com/dotnet/api/system.object">object</a>></dt>
|
||||
<dd><p>The two planes and the compensation mode, or null.</p>
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
<h4 class="section">Returns</h4>
|
||||
<dl class="parameters">
|
||||
<dt><a class="xref" href="https://learn.microsoft.com/dotnet/api/system.boolean">bool</a></dt>
|
||||
<dd></dd>
|
||||
</dl>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
</article>
|
||||
|
||||
<div class="contribution d-print-none">
|
||||
</div>
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
<div class="affix">
|
||||
<nav id="affix"></nav>
|
||||
</div>
|
||||
</main>
|
||||
|
||||
<div class="container-xxl search-results" id="search-results"></div>
|
||||
|
||||
<footer class="border-top text-secondary">
|
||||
<div class="container-xxl">
|
||||
<div class="flex-fill">
|
||||
<span> Copyright © 2025 <a href='https://superhightech.com.tw'>Tech Coordinate</a>. All rights reserved. <a href='https://superhightech.com.tw'>超級高科技股份有限公司</a> © 2025 版權所有 </span>
|
||||
</div>
|
||||
</div>
|
||||
</footer>
|
||||
</body>
|
||||
</html>
|
||||
@@ -217,11 +217,33 @@ radius entered against a tool-centre CAM path that expects wear only)
|
||||
shows up as an overcut instead of an alarm. The diagnostics built from
|
||||
this class exist to close that gap; they never change the path.</p>
|
||||
<p>
|
||||
Today the gate is meaningful on the XY plane (G17) only: both
|
||||
compensation engines build the perpendicular as <code>Z × axis</code>
|
||||
whatever plane is selected, so a G18/G19 region is neither compensated
|
||||
in its own plane nor checked here — the <code>planeNormalDir</code> parameters
|
||||
are ready for the day the engines pass the selected plane through.
|
||||
The gate works on the selected G17/G18/G19 plane: both engines pass
|
||||
the block's plane through <code>planeNormalDir</code>, and the in-plane
|
||||
projections below use it (neither engine checks a polar G12.1 block).
|
||||
Until 2026-09-11 both engines built the perpendicular as
|
||||
<code>Z × axis</code> whatever plane was selected, so a G18/G19 region was
|
||||
offset along its normal and could never be judged here.
|
||||
</p>
|
||||
</dd>
|
||||
</dl>
|
||||
<dl class="jumplist">
|
||||
<dt><a class="xref" href="Hi.NcParsers.RadiusCompPlaneChange.html">RadiusCompPlaneChange</a></dt>
|
||||
<dd><p>Classifies a plane selection (G17/G18/G19) that arrives while cutter
|
||||
radius compensation is still active — the case a real control refuses.
|
||||
Fanuc stops with alarm PS0037 CAN NOT CHANGE PLANE IN CRC, which covers
|
||||
both a plane code inside the compensation mode and a plane code sharing
|
||||
its block with the G40 that cancels it; Siemens and Heidenhain have
|
||||
equivalents. Neither engine can honour such a change: the corner between
|
||||
the two blocks is built from one block's running axis on the old plane
|
||||
and the other's on the new one, so the path around the change mixes two
|
||||
planes — and the block after it is offset on a plane the block before it
|
||||
never saw. The diagnostics built from this class exist to name that;
|
||||
they never change the path.</p>
|
||||
<p>
|
||||
The check is on the plane actually resolving differently from the
|
||||
previous block's, so a plane code that re-selects the plane already in
|
||||
force stays silent, as does the plane code on the block that starts the
|
||||
region (a control accepts that one — compensation is not active yet).
|
||||
</p>
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
@@ -469,8 +469,9 @@ Set by the current line's iteration in <a class="xref" href="Hi.Numerical.Radius
|
||||
|
||||
<h4 class="section" id="Hi_Numerical_RadiusCompensationBuf_ResolveRadiusCompensation_System_Collections_Generic_LinkedListNode_Hi_Numerical_HardNcLine__Hi_Numerical_HardNcEnv_Hi_Numerical_NcNoteCache_System_IProgress_Hi_Common_Messages_IMessage___remarks">Remarks</h4>
|
||||
<div class="markdown level1 remarks"><p>Blocks without in-plane movement of their own (comments, empty lines,
|
||||
a bare G41/G40, M/F/S-only blocks, dwells, Z-only plunges, zero-length
|
||||
moves) never take part in a corner. Before the region's first moving
|
||||
a bare G41/G40, M/F/S-only blocks, dwells, plunges along the plane
|
||||
normal, zero-length moves) never take part in a corner. Before the
|
||||
region's first moving
|
||||
block the start-up is pending (Fanuc: a G41/G42 block without
|
||||
movement starts up on the next movement block), so such blocks keep
|
||||
their nominal position; afterwards they carry the previous block's
|
||||
|
||||
@@ -6,7 +6,7 @@
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
<meta name="title" content="Class CodeXyzabcChain | HiAPI-C# 2025 ">
|
||||
|
||||
<meta name="description" content="A authored through chain code — a bracket notation for the connectivity of the mechanism's branches. On purpose of easy XML hand management. The entity is the inherited ; is a delegated representation: reading derives the codes from the mechanism's topology, assigning reseeds the mechanism (transformers and solids of same-named components carry over). Notation: each segment declares branches left to right — [O][Y];[Y][X];[X][w] pairs, or the concatenated sugar [O][Y][X][w]. Words merge by name across segments; [] is an anonymous component (each occurrence is a fresh one). Reserved words: X,Y,Z translational axes, A,B,C rotational axes, w table buckle, t tool buckle; any other word is a plain component.">
|
||||
<meta name="description" content="A authored through chain code — a bracket notation for the connectivity of the mechanism's branches. On purpose of easy XML hand management. The entity is the inherited ; is a delegated representation: reading derives the codes from the mechanism's topology, assigning reseeds the mechanism (transformers and solids of same-named components carry over). Notation: each segment declares branches left to right — [O][Y];[Y][X];[X][w] pairs, or the concatenated sugar [O][Y][X][w]. Words merge by name across segments; [] is an anonymous component (each occurrence is a fresh one). Reserved words: X,Y,Z translational axes, A,B,C rotational axes, w table buckle, t tool buckle; any other word is a plain component. Reserved words are matched exactly as written, so a word differing only in letter case is a plain component.">
|
||||
<link rel="icon" href="../img/HiAPI.favicon.ico">
|
||||
<link rel="stylesheet" href="../public/docfx.min.css">
|
||||
<link rel="stylesheet" href="../public/main.css">
|
||||
@@ -111,7 +111,8 @@ solids of same-named components carry over).</p>
|
||||
anonymous component (each occurrence is a fresh one). Reserved words:
|
||||
<code>X</code>,<code>Y</code>,<code>Z</code> translational axes, <code>A</code>,<code>B</code>,<code>C</code>
|
||||
rotational axes, <code>w</code> table buckle, <code>t</code> tool buckle; any other
|
||||
word is a plain component.</p>
|
||||
word is a plain component. Reserved words are matched exactly as written,
|
||||
so a word differing only in letter case is a plain component.</p>
|
||||
</div>
|
||||
<div class="markdown conceptual"></div>
|
||||
|
||||
|
||||
@@ -110,7 +110,8 @@ solids of same-named components carry over).</p>
|
||||
anonymous component (each occurrence is a fresh one). Reserved words:
|
||||
<code>X</code>,<code>Y</code>,<code>Z</code> translational axes, <code>A</code>,<code>B</code>,<code>C</code>
|
||||
rotational axes, <code>w</code> table buckle, <code>t</code> tool buckle; any other
|
||||
word is a plain component.</p>
|
||||
word is a plain component. Reserved words are matched exactly as written,
|
||||
so a word differing only in letter case is a plain component.</p>
|
||||
</dd>
|
||||
</dl>
|
||||
<dl class="jumplist">
|
||||
|
||||
@@ -2443,6 +2443,9 @@
|
||||
<li>
|
||||
<a href="Hi.NcParsers.RadiusCompInterference.html" name="" title="RadiusCompInterference">RadiusCompInterference</a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="Hi.NcParsers.RadiusCompPlaneChange.html" name="" title="RadiusCompPlaneChange">RadiusCompPlaneChange</a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="Hi.NcParsers.Sentence.html" name="" title="Sentence">Sentence</a>
|
||||
</li>
|
||||
|
||||
File diff suppressed because one or more lines are too long
File diff suppressed because one or more lines are too long
@@ -88,11 +88,11 @@
|
||||
<h1 id="finding-your-way">Finding Your Way</h1>
|
||||
|
||||
<p>The application is a handful of screens, and most of what a job configures lives inside a tree on
|
||||
two of them. The <strong>Page</strong> menu reaches six of those screens, and it is not all of them. Every node
|
||||
two of them. The <strong>Page</strong> menu reaches five of those screens, and it is not all of them. Every node
|
||||
of a tree has an address of its own, so a place in the application can be linked to rather than
|
||||
described.</p>
|
||||
<h2 id="the-screens">The screens</h2>
|
||||
<p>The <strong>Page</strong> dropdown on the menu bar carries six entries in three groups. The first group is the
|
||||
<p>The <strong>Page</strong> dropdown on the menu bar carries five entries in two groups. The first group is the
|
||||
job, in the order a job uses it:</p>
|
||||
<ul>
|
||||
<li><strong>Tool House</strong> — the tools, one editor per tool</li>
|
||||
@@ -106,27 +106,24 @@ run reports</li>
|
||||
<li><strong>File Explorer</strong> — browsing the files under the roots the service exposes</li>
|
||||
<li><strong>Mechanism Builder</strong> — authoring a kinematic chain</li>
|
||||
</ul>
|
||||
<p>Below a second separator, one more:</p>
|
||||
<ul>
|
||||
<li><strong>Legacy-Controller</strong> — the controller settings that the General Setup tree's Controller branch
|
||||
has no editor for. The page it opens is titled <em>Controller</em>.</li>
|
||||
</ul>
|
||||
<p>No entry is ever greyed out. All six are selectable with no project open; what they lead to is what
|
||||
<p>No entry is ever greyed out. All five are selectable with no project open; what they lead to is what
|
||||
changes.</p>
|
||||
<p>Three screens have no entry in this menu:</p>
|
||||
<ul>
|
||||
<li><strong>Machine Tool</strong>, at <code>/machine-tool</code>, reached by address only. It shows the machine chain beside a
|
||||
folder button whose tooltip reads <strong>Browse</strong> and a GUI / XML view switch, so it is more than a
|
||||
look at the chain — and it needs a project open.</li>
|
||||
folder button — whose tooltip reads <strong>Browse</strong> once a project is open, and <strong>Load a project first</strong>
|
||||
before that — and a GUI / XML view switch, so it is more than a look at the chain, and it needs a
|
||||
project open.</li>
|
||||
<li><strong>Log Viewer</strong>, reached from the <strong>Show Log</strong> button near the right-hand end of the menu bar. Its
|
||||
address is <code>/preference/log</code>.</li>
|
||||
<li>The sign-in page, which the service raises on its own when it wants one.</li>
|
||||
</ul>
|
||||
<h2 id="selecting-inside-a-tree">Selecting inside a tree</h2>
|
||||
<p>General Setup and Execution each carry a Control Tree in their left dock, under a header reading
|
||||
<strong>Control Tree</strong>, with the selected node's editor in the row beneath it. That editor row is titled
|
||||
with the path of the selection — <em>General Setup / Workpiece / Anchor / Geom To Fixture</em> — which is
|
||||
also how these pages name a place in prose.</p>
|
||||
<strong>Control Tree</strong>, with the selected node's editor in the row beneath it. That editor row names the
|
||||
path of the selection — <em>General Setup / Workpiece / Anchor / Geom To Fixture</em> — which is also how
|
||||
these pages name a place in prose; the header shows as much of it as the dock is wide, so a deep
|
||||
path arrives truncated.</p>
|
||||
<p>General Setup's tree has one root, <strong>General Setup</strong>, holding <strong>Machine Tool</strong>, <strong>Spindle
|
||||
Capability</strong>, <strong>Background</strong>, <strong>Coolant</strong>, <strong>Fixture</strong>, <strong>Workpiece</strong> and <strong>Controller</strong>, in that
|
||||
order. With a project open, a <strong>CSV Controller</strong> and a <strong>CL Controller</strong> node follow, each behind
|
||||
@@ -148,13 +145,14 @@ copying it copies the node, not just the page.</p>
|
||||
<li>To take a link from the tree instead, right-click a node's label. Every label is a real link to
|
||||
that node's address, so the browser's own copy-link and open-in-new-tab entries both apply to
|
||||
it.</li>
|
||||
<li>Ctrl-click, Cmd-click or Shift-click a label to open that node in a new tab. The current tab's
|
||||
selection stays where it is.</li>
|
||||
<li>Ctrl-click or Cmd-click a label to open that node in a new tab; Shift-click and middle-click open
|
||||
it wherever the browser opens any other link. The current tab's selection stays where it is.</li>
|
||||
<li>A plain left click selects the node in place, without navigating.</li>
|
||||
<li>Paste a <code>?tree=</code> value belonging to the other tree page and it redirects to the page that owns
|
||||
it, so a link does not have to name the right screen to reach the right node.</li>
|
||||
<li>Paste a <code>?tree=</code> value belonging to another page's tree and it redirects to the page that owns
|
||||
it — the other tree page, or Tool House — so a link does not have to name the right screen to
|
||||
reach the right node.</li>
|
||||
</ol>
|
||||
<p>Tool House has no <code>?tree=</code> at all — its address already names the selection, as
|
||||
<p>Tool House has no <code>?tree=</code> at all — its address names the selection down to the sub-tab, as
|
||||
<code>/tool-house/<tool>/<tab>/<sub-tab></code>, so <code>/tool-house/1/cutter/material</code> is a link to one tool's
|
||||
Material sub-tab.</p>
|
||||
<p>Arriving at a tree page with no <code>?tree=</code> still lands on a selected node — the last selection this
|
||||
@@ -164,8 +162,9 @@ as the tree is built, so the address bar is a whole link from then on.</p>
|
||||
<h5>Important</h5>
|
||||
<p>An address for a node its Preference checkbox is currently hiding — a <strong>CSV Controller</strong> or <strong>CL
|
||||
Controller</strong> node — is honoured only when the tree is built while that address is the current
|
||||
one, and it reveals nothing without a project open. In practice that means a full page load:
|
||||
pasting the link into a new tab, or reloading on it. Jumping to it from a screen that has already
|
||||
one, and it reveals nothing without a project open. In practice that means the tree's first build
|
||||
on that address: pasting the link into a new tab, reloading on it, or opening General Setup for the
|
||||
first time since the page or the project was loaded. Jumping to it from a screen that has already
|
||||
shown General Setup for the current project does not rebuild that tree, so the address is dropped
|
||||
in silence with the selection left where it was.</p>
|
||||
</div>
|
||||
@@ -176,7 +175,7 @@ describes the fields as column tags matched against the CSV header line: <strong
|
||||
prefix</strong> <code>MC.</code>, <strong>Cutter location prefix</strong> <code>CL.</code> and <strong>Tool id column</strong> <code>ToolId</code>.</p>
|
||||
<p><img src="finding-your-way-img/controller-csv-revealed.en.png" alt="The General Setup Control Tree with a CSV Controller node at the same indent as Controller, a sibling rather than a child of it, and the CSV column-tag editor below the tree"></p>
|
||||
<h2 id="the-addresses">The addresses</h2>
|
||||
<p>Nine addresses render a screen of their own. The bracketed segments are optional, so the bare
|
||||
<p>Eight addresses render a screen of their own. The bracketed segments are optional, so the bare
|
||||
address resolves too and the screen fills them in from its own state; File Explorer's trailing path
|
||||
carries as many segments as the browsed folder is deep.</p>
|
||||
<table>
|
||||
@@ -204,10 +203,6 @@ carries as many segments as the browsed folder is deep.</p>
|
||||
<td>Machine Tool</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>/controller/<tab></code></td>
|
||||
<td>Controller</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>/util/file-explorer/<root>/<path></code></td>
|
||||
<td>File Explorer</td>
|
||||
</tr>
|
||||
@@ -225,7 +220,7 @@ carries as many segments as the browsed folder is deep.</p>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<p><code>/</code> lands on Execution. Six further addresses render nothing of their own and redirect into a tree
|
||||
<p><code>/</code> lands on Execution. Seven further addresses render nothing of their own and redirect into a tree
|
||||
page's node instead:</p>
|
||||
<table>
|
||||
<thead>
|
||||
@@ -236,6 +231,10 @@ page's node instead:</p>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td><code>/controller</code>, and anything below it</td>
|
||||
<td>General Setup, the Controller branch — the trailing path, the retired Legacy-Controller page's tab names included, is discarded</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>/spindle-capability/<tab></code></td>
|
||||
<td>General Setup, the Spindle Capability branch — on that tab's item when the segment names one, on the branch itself otherwise</td>
|
||||
</tr>
|
||||
|
||||
@@ -89,8 +89,9 @@
|
||||
|
||||
<p>This section covers the sign-in gate in front of the application and what is true on every screen
|
||||
behind it: the frame that stays put while the page area changes, the project the rest of the
|
||||
application is configured against, the ways one screen leads to another, and the surfaces that
|
||||
report what the service is doing. The task sections build on it rather than restating it. The pages
|
||||
application is configured against, the ways one screen leads to another, the settings that follow
|
||||
the application rather than the project, and the surfaces that report what the service is doing.
|
||||
The task sections build on it rather than restating it. The pages
|
||||
below are ordered as the application presents them: the gate, the frame, the project, the screens,
|
||||
the settings, the messages.</p>
|
||||
<p>For a first end-to-end run rather than a reference, start with
|
||||
@@ -102,7 +103,7 @@ the settings, the messages.</p>
|
||||
<li><a href="projects.html">Projects</a> — Creating, opening, saving and closing a project, and what Save As does and does not copy</li>
|
||||
<li><a href="finding-your-way.html">Finding Your Way</a> — The screens the Page menu reaches and the ones it does not, selecting inside a tree, and linking to a node</li>
|
||||
<li><a href="preferences.html">Preferences</a> — The settings the service keeps for everyone on it, and the ones the browser keeps for the device it is sitting at</li>
|
||||
<li><a href="messages-and-logs.html">Messages and Logs</a> — The footer's three channels, the four session message tabs and the service log, and which answers which question</li>
|
||||
<li><a href="messages-and-logs.html">Messages and Logs</a> — Where a message lands and how long it lasts: the toasts and the footer, the four session message tabs and the service log, and which answers which question</li>
|
||||
</ul>
|
||||
<h2 id="see-also">See Also</h2>
|
||||
<ul>
|
||||
|
||||
@@ -96,14 +96,16 @@ Picking the right surface is most of the difference between a specific question
|
||||
<ul>
|
||||
<li><strong>A toast</strong> — bottom right, for a few seconds, then gone. The only surface that interrupts, and
|
||||
the only one that keeps nothing itself.</li>
|
||||
<li><strong>The footer's latest line, and the recent list behind it</strong> — every toast that carried any text is
|
||||
copied here before it is shown, so this list is the toast's afterlife. Only a toast with neither
|
||||
message nor caption is skipped, and a small number of status lines are written straight here and
|
||||
never toast at all.</li>
|
||||
<li><strong>The footer's latest line, and the recent list behind it</strong> — a toast is copied here before it is
|
||||
shown, so this list is the toast's afterlife. Two kinds never arrive: a toast carrying neither
|
||||
message nor caption, and the notices Tool House, the <strong>Spindle Capability</strong> editor and the
|
||||
Controller panels raise, which are shown once and not kept. A small number of status lines go the
|
||||
other way — written straight here, and never toasted at all.</li>
|
||||
<li><strong>The footer's session strip</strong> — the middle of the bar, drawn once a run has produced something
|
||||
and empty until then.</li>
|
||||
<li><strong>The footer's background zone</strong> — the right end, drawn only while a project file operation is in
|
||||
flight, naming the operation and the path it is working on.</li>
|
||||
<li><strong>The footer's background zone</strong> — the right end, drawn only while one of the <strong>Project</strong> menu's
|
||||
operations is in flight — <strong>Close Project</strong> included — naming the operation and the path it is
|
||||
working on.</li>
|
||||
<li><strong>The Session Messages panel</strong> — on the Execution page, four lists kept by the service.</li>
|
||||
<li><strong>The Log Viewer</strong> — the file the service itself writes for the current day.</li>
|
||||
</ul>
|
||||
@@ -111,12 +113,20 @@ flight, naming the operation and the path it is working on.</li>
|
||||
four lists, and the panel is where it stays.</p>
|
||||
<h2 id="messages-a-project-load-raises">Messages a project load raises</h2>
|
||||
<p>Opening or re-reading a project can report holes in it — a referenced STL missing from disk, or a
|
||||
mesh-geometry <code>.wct</code> file a raw geometry names but that is not there. <strong>None of these fail the load.</strong>
|
||||
The project opens, the body that needed the missing file simply comes up without its geometry, and
|
||||
the action still reports success. The message is the only thing that says otherwise.</p>
|
||||
<p>These messages then take a path of their own, and it has a consequence worth knowing before you rely
|
||||
on it. A project file operation runs outside any session, so the panel's four lists — which belong to
|
||||
the service, and are where everything a <em>run</em> reports stays — never see them. Instead the first five
|
||||
runner configuration the file names that would not load, leaving the project on a default one.
|
||||
<strong>None of these fail the load.</strong> The project opens, the body that needed the missing file simply
|
||||
comes up without its geometry, and the action still reports success. The message is the only thing
|
||||
that says otherwise.</p>
|
||||
<p>Two neighbouring cases go elsewhere. A mesh-geometry <code>.wct</code> file a raw geometry names but that is not
|
||||
there raises nothing here at all, because the load never opens it; the first word about it comes when
|
||||
the meshed geometry is next needed, and that message belongs to the run, so it lands in the Session
|
||||
Messages panel like any other. A side file the project names as a reference — the machine chain, the
|
||||
spindle capability, a material, a cutting parameter set — is the opposite case: a missing one fails
|
||||
the load outright, and that arrives as an error rather than as one of the messages described here.
|
||||
See <a href="projects.html">Projects</a>.</p>
|
||||
<p>These messages then take a path of their own, and it has a consequence worth knowing before that
|
||||
path is relied on. A project file operation runs outside any session, so the panel's four lists —
|
||||
which belong to the service, and are where everything a <em>run</em> reports stays — never see them. Instead the first five
|
||||
errors and warnings are toasted, anything past that goes straight to the footer's recent list, and
|
||||
one more toast says how many did not get their own. Anything milder than a warning is not surfaced in
|
||||
the window at all.</p>
|
||||
@@ -126,15 +136,15 @@ read <a href="#the-service-log">the service log</a>, which has them either way.
|
||||
not.</p>
|
||||
<h2 id="the-footer">The footer</h2>
|
||||
<p>The left region is this browser's own record and nothing else's. The list behind the latest line is
|
||||
newest first, capped at a hundred entries, emptied by its <strong>Clear</strong> button and by a reload, and
|
||||
written down nowhere — nothing about it survives closing the tab. Each entry keeps the wording it
|
||||
newest first, capped at a hundred entries, emptied by its <strong>Clear</strong> button — which takes the latest
|
||||
line back to <em>Ready</em> with it — and by a reload, and written down nowhere — nothing about it survives closing the tab. Each entry keeps the wording it
|
||||
was raised in, so switching the language leaves the list as a mixture while the panel's lists
|
||||
re-render at once. The frame page describes the regions themselves: see
|
||||
<a href="the-app-window.html">The Application Window</a>.</p>
|
||||
<p><strong>Nothing marks the list as having something new in it.</strong> The button carries no badge and no dot,
|
||||
deliberately, because a toast has already drawn attention once. The consequence is the failure this
|
||||
page exists to prevent: a message raised while another screen was open, or while the window was
|
||||
behind something else, is invisible until that menu is opened by hand. Opening it after an action
|
||||
page exists to prevent: a message that never toasted at all, or one whose few seconds expired while
|
||||
the window was behind something else, is invisible until that menu is opened by hand. Opening it after an action
|
||||
that seemed to do nothing is the cheapest check available.</p>
|
||||
<p>The middle strip is the other way round — the service pushes it, so every connected browser sees the
|
||||
same run activity, and each browser keeps its own short ring of the last entries behind it. What it
|
||||
@@ -149,7 +159,7 @@ appear on it at all. The lists on the service drop nothing.</p>
|
||||
header row reads <strong>Session Messages</strong> and stays visible when the panel is collapsed, so a grey strip
|
||||
with that name on it is the panel, shut.</p>
|
||||
<p><strong>The whole column can be switched off, and nothing on the page says so.</strong> The column quick-toggles
|
||||
in the middle of the menu bar include one whose tooltip reads <em>Toggle the Execution canvas &
|
||||
at the right-hand end of the menu bar include one whose tooltip reads <em>Toggle the Execution canvas &
|
||||
messages column</em>; with it off, neither the panel nor its header row is drawn, and the page simply
|
||||
looks like it has fewer parts. That choice is the browser's and survives a reload. The expanded or
|
||||
collapsed state of the panel itself is not: it is kept by the service, and is therefore the same for
|
||||
@@ -269,14 +279,14 @@ application.</p>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>what was reported while another screen was open</td>
|
||||
<td>the recent list behind it — nothing else will mention it</td>
|
||||
<td>the recent list behind it — the only copy the window keeps</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>where a run has got to</td>
|
||||
<td>the footer's session strip</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>whether a project file operation is still running</td>
|
||||
<td>whether one of the Project menu's operations is still running</td>
|
||||
<td>the footer's background zone</td>
|
||||
</tr>
|
||||
<tr>
|
||||
@@ -297,7 +307,7 @@ application.</p>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>why a project opened with pieces missing</td>
|
||||
<td>the toasts it raised, or the Log Viewer — <strong>not</strong> the Session Messages panel</td>
|
||||
<td>the footer's recent list, or the Log Viewer — <strong>not</strong> the Session Messages panel</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>what the service recorded, shown or not</td>
|
||||
|
||||
@@ -89,8 +89,9 @@
|
||||
|
||||
<p>The settings that follow the application rather than the project are kept on two sides: the service,
|
||||
where one value serves every browser signed in to it, and the browser, for the device it is sitting
|
||||
at. The <strong>Preference</strong> menu is where most of them are set, and the rest are reached from the panel
|
||||
each one belongs to. Which side keeps a setting is the thing worth knowing about it, because that is
|
||||
at. The <strong>Preference</strong> menu carries four of them — the language, the physics switch and the two
|
||||
controller checkboxes — and the rest are reached from the panel each one belongs to. Which side
|
||||
keeps a setting is the thing worth knowing about it, because that is
|
||||
what decides who else sees the change.</p>
|
||||
<h2 id="where-it-is">Where it is</h2>
|
||||
<p>The <strong>Preference</strong> dropdown on the menu bar, after <strong>Project</strong> and <strong>Page</strong>. It carries no OK and no
|
||||
@@ -126,9 +127,11 @@ for a selected step, which of that page's charts, its <strong>Session Messages</
|
||||
Properties</strong> panel are switched on, the General Setup canvas's display options including the work
|
||||
coordinate its marker draws, and the graphic cache budget.</p>
|
||||
<p><strong>The browser keeps the arrangement of the screen in front of it.</strong> That is the two tree pages'
|
||||
layout — which columns are shown, how wide the docks are, which tree nodes are left unfolded and
|
||||
which node each tree page reopens on — together with the two controller checkboxes above, and the
|
||||
File Explorer's editor pane, its split and its sort order. Three of the Execution page's panels sit
|
||||
layout — which columns are shown, how wide the docks are and how the right-hand dock is divided
|
||||
between its two columns, how tall the editor row under each tree is, which tree nodes are left
|
||||
unfolded, which node each tree page reopens on, the heights dragged between stacked panels, the two
|
||||
shared chart legend widths and the shared strip-chart x-axis mode — together with the two controller
|
||||
checkboxes above, and the File Explorer's editor pane, its split, its auto-save and its sort order. Three of the Execution page's panels sit
|
||||
on this side rather than with that page's others: the <strong>3D Rendering Canvas</strong>, <strong>CWE</strong> and
|
||||
<strong>Sentence Syntax</strong>. The browser also holds a copy of the language, used only to paint the first
|
||||
frame before the service can be asked; the service's value wins every disagreement, so a language
|
||||
@@ -139,15 +142,17 @@ reaches the service's preference file only when some later preference save write
|
||||
service stopped before any such save comes back on the budget it had before.</p>
|
||||
<h2 id="making-a-physics-change-take">Making a physics change take</h2>
|
||||
<p><strong>Show Physics Options</strong> is read while a tree or a tab row is being built, not while one is on screen,
|
||||
so the four routes below are what the tree and the tab row need; the two canvases pick the change up
|
||||
on their own next draw instead. Ticking it therefore changes nothing already built: the tree does
|
||||
not grow the nodes it gates, and the Tool House tab row does not grow the tab, until something
|
||||
builds them again. Folding a branch shut and opening it again is not a rebuild.</p>
|
||||
so the four routes below are what the tree and the tab row need; the Execution page's <strong>CWE</strong> canvas
|
||||
re-reads it the next time the selected step changes, while the Tool House canvas fixes the cutter's
|
||||
shape when its rendering connection is made and holds it until that connection is made again.
|
||||
Ticking it therefore changes nothing already built: the tree does not grow the nodes it gates, and
|
||||
the Tool House cutter's section-tab row does not grow the tab, until something builds them again.
|
||||
Folding a branch shut and opening it again is not a rebuild.</p>
|
||||
<p>Four things do rebuild one:</p>
|
||||
<ol>
|
||||
<li>Reload the browser. That rebuilds the whole application, every tree included.</li>
|
||||
<li>The project under the session changes — <strong>New</strong>, <strong>Load</strong>, <strong>Close Project</strong>, or a <strong>Save As</strong> to a
|
||||
location other than the one already open. Every screen the session has built is discarded and
|
||||
<li>The project under the session changes — <strong>New</strong>, a <strong>Load</strong> that picks a different project,
|
||||
<strong>Close Project</strong>, or a <strong>Save As</strong> to a location other than the one already open. Every screen the session has built is discarded and
|
||||
built again, and <strong>ReLoad</strong> does the same on the path already open.</li>
|
||||
<li>On Tool House, select a different tool in the left column and come back. The tab row is built for
|
||||
whichever tool is being shown, so moving between two tools rebuilds it twice.</li>
|
||||
|
||||
@@ -156,12 +156,17 @@ project file's own folder. Opening the project file in a text editor shows those
|
||||
than what they point at.</p>
|
||||
<div class="IMPORTANT">
|
||||
<h5>Important</h5>
|
||||
<p><strong>A reference that points at nothing does not stop the project opening.</strong> Load and ReLoad read what
|
||||
they can and report what they could not — a missing STL, or a mesh-geometry <code>.wct</code> file a raw
|
||||
geometry names — and the project comes up with that body simply having no geometry, the action
|
||||
still reporting success. The message is the only thing that says otherwise, and it is not kept
|
||||
where a run's messages are kept: see
|
||||
<a href="messages-and-logs.html#messages-a-project-load-raises">Messages a project load raises</a>.</p>
|
||||
<p><strong>A raw geometry that points at nothing does not stop the project opening; a missing side file
|
||||
does.</strong> Load and ReLoad read what they can and report what they could not — a missing STL, say —
|
||||
and the project comes up with that body simply having no geometry, the action still reporting
|
||||
success. A mesh-geometry <code>.wct</code> file a raw geometry names is quieter still: the load neither opens
|
||||
it nor mentions it, and the first word about it is a warning raised when the meshed geometry is
|
||||
first needed. A side file named as a reference is the other case altogether: when the machine
|
||||
chain, the spindle capability, a material or a cutting parameter set is not where the project file
|
||||
says it is, the load fails outright — no project opens, and the failure is reported as an error
|
||||
rather than as a diagnostic beside a successful load. Where a load does succeed with a hole, the
|
||||
message is the only thing that says otherwise, and it is not kept where a run's messages are kept:
|
||||
see <a href="messages-and-logs.html#messages-a-project-load-raises">Messages a project load raises</a>.</p>
|
||||
</div>
|
||||
<p>A project is therefore a folder at least as much as a file. Copying one to another machine, archiving
|
||||
one, or handing one to somebody else means taking the folder.</p>
|
||||
@@ -176,10 +181,14 @@ editor, waiting on a file to be given to it.</p>
|
||||
<div class="WARNING">
|
||||
<h5>Warning</h5>
|
||||
<p><strong>A Save As into a new folder can produce a project that finds none of its programs.</strong> Save As
|
||||
writes out every side file the project file holds as a reference, into the new folder and at the
|
||||
same relative place, and nothing it does not. What it leaves behind is whatever the project names
|
||||
as a plain path instead of as a reference — and the NC programs a mission plays are named that
|
||||
way. Nothing rewrites those paths either, so the saved project still asks for <code>NC/…</code>, now
|
||||
writes out the side files the project file references — the machine chain, the spindle capability,
|
||||
the materials, the cutting parameters, and the STL meshes the equipment and the workpiece name —
|
||||
into the new folder and at the same relative place. Two things travel as a path with nothing
|
||||
behind them: a mesh-geometry <code>.wct</code>, which is never written out at all, and an STL that was
|
||||
already missing when the project opened, which is deliberately left missing rather than replaced
|
||||
by an empty file. Neither are the NC programs a mission plays: the project records
|
||||
each as a path, and nothing on the save side copies the file. Nothing rewrites those paths either,
|
||||
so the saved project still asks for <code>NC/…</code>, now
|
||||
underneath the new folder, where nothing has put it. The programs have to be brought across by
|
||||
hand, or the Save As aimed at a folder that already holds them.</p>
|
||||
</div>
|
||||
@@ -205,8 +214,9 @@ did not change — carries on with what it was showing.</p>
|
||||
performed the Save As is told, in the reply to its own request. Every other browser goes on
|
||||
displaying the old path in its <strong>Project</strong> dropdown, although the service is working with the new one
|
||||
underneath — so a Save from any of them writes to the new path. A stale row corrects itself the next
|
||||
time the service reports its state to that browser: a reload, another project change, or a run being
|
||||
started, paused, finished or reset from any browser.</p>
|
||||
time the service reports its state to that browser: a reload, the browser's status connection
|
||||
dropping and coming back, another project change, or a run being started, paused, finished or reset
|
||||
from any browser.</p>
|
||||
<p>New, Load, ReLoad, Save and Save As take a turn each. A second one asked for while the first is still
|
||||
running is refused rather than queued, and the refusal arrives as a warning reading <em>Another project
|
||||
operation is in progress. Please try again.</em> Close Project takes no part in that turn-taking: it
|
||||
|
||||
@@ -105,8 +105,9 @@ change a password or recover one from inside the application. All three are edit
|
||||
configuration, made by whoever runs the service, and they take effect at its next restart.</p>
|
||||
<p>What the gate closes is the service's own surface: the requests each screen makes for data, and the
|
||||
live channels that keep those screens current. It does not close the page. The application shell,
|
||||
the brand image and the sign-in card itself are served before authorization is consulted, which is
|
||||
what lets the card be drawn for a browser that holds no session.</p>
|
||||
the brand image and the sign-in card itself all reach a browser that holds no session: the brand
|
||||
image and the built bundle the card is drawn from are plain files, served before authorization is
|
||||
consulted, and the shell page is exempt from the gate outright.</p>
|
||||
<h2 id="signing-in-1">Signing in</h2>
|
||||
<p>The card asks for one pair of credentials, under the prompt <em>Please sign in to continue</em>.</p>
|
||||
<ol>
|
||||
|
||||
@@ -92,7 +92,7 @@ along the bottom. The frame is built once and stays mounted for the whole sessio
|
||||
described here is present on every page. A project change is the one event that reaches into it and
|
||||
rebuilds what the middle holds.</p>
|
||||
<p>The whole frame at <code>/execution</code>, with the demo project open. Only the column quick-toggles and the
|
||||
connection badge, in the middle of the bar, are there because of the page underneath them — the logo,
|
||||
connection badge, in the right-hand group, are there because of the page underneath them — the logo,
|
||||
the three dropdowns, the page title and <strong>Show Log</strong> sit on the bar whatever page is open, and the
|
||||
sign-out button turns on whether a sign-in is asked for rather than on the page. The strip along the
|
||||
very bottom is the footer, reading <strong>Ready</strong> because nothing has been reported yet.</p>
|
||||
@@ -111,12 +111,12 @@ column), three on General Setup. Each glyph is a small map of the page with its
|
||||
and each tooltip names the column it toggles. Tool House lays itself out with draggable splitters
|
||||
and gets no buttons here.</li>
|
||||
<li><strong>The connection badge</strong> — the Execution page only. See below.</li>
|
||||
<li><strong>The current page's title</strong> — the destination's own title, which is where two controls read
|
||||
differently from where they land: the Page menu's <strong>Legacy-Controller</strong> entry opens the page titled
|
||||
<strong>Controller</strong>, and <strong>Show Log</strong> opens the page titled <strong>Log Viewer</strong>.</li>
|
||||
<li><strong>The current page's title</strong> — the destination's own title, which is where one control reads
|
||||
differently from where it lands: <strong>Show Log</strong> opens the page titled <strong>Log Viewer</strong>.</li>
|
||||
<li><strong>Show Log</strong> — present on every page.</li>
|
||||
<li><strong>The sign-out button</strong> — labelled with the signed-in user name, or <strong>Logout</strong> when the service has
|
||||
no name for it. It is there only while the service asks for a sign-in.</li>
|
||||
no name for it. It is there only while the service asks for a sign-in and this browser has passed
|
||||
it.</li>
|
||||
</ul>
|
||||
<h2 id="the-page-area">The page area</h2>
|
||||
<p>Everything between the bars is the current page, and every page reached during a session stays built:
|
||||
@@ -125,16 +125,22 @@ half-finished and an established rendering connection exactly as they were.</p>
|
||||
<p>Two things it does not carry over. Nothing restores a scroll position inside a panel: coming back to a
|
||||
page finds its panels scrolled to where a fresh mount would put them. And a browser reload is not a
|
||||
navigation — it rebuilds the whole application and empties the cache; what survives it is what lives
|
||||
outside the page area, namely the address (a <code>?tree=</code> selection in it included) and the layout the
|
||||
browser keeps for itself.</p>
|
||||
outside the page area: the address (a <code>?tree=</code> selection in it included), the layout the browser
|
||||
keeps for itself, and the preferences the service holds — the language, <strong>Show Physics Options</strong>, and
|
||||
which of the Execution page's charts, its <strong>Session Messages</strong> panel and its <strong>Step Properties</strong>
|
||||
panel are switched on.</p>
|
||||
<p>The column buttons are remembered per page — the two tree pages each keep their own choices — while
|
||||
the dock widths and the list of unfolded tree nodes are single settings both of them share, so
|
||||
widening the dock on Execution widens it on General Setup too.</p>
|
||||
<p><strong>F5 to F8 belong to the Execution page.</strong> They drive its transport — F5 starts or resumes, F6
|
||||
pauses, F7 runs one NC line, F8 runs one machining step — and they are bound only while that page is
|
||||
the one on screen, so on every other screen F5 is the browser's own reload. A key whose button is not
|
||||
available at that moment, or that is pressed with the focus in a text field, is handed back to the
|
||||
browser instead. That matters most for F5: while a run is in progress the start button is
|
||||
unavailable, so the key reloads the page and takes the session with it.</p>
|
||||
unavailable, so the key reloads the page and the screens the session had built go with it.</p>
|
||||
<h2 id="what-a-project-change-does">What a project change does</h2>
|
||||
<p><strong>New</strong>, <strong>Load</strong>, <strong>ReLoad</strong> and <strong>Close Project</strong> discard every page the session has built and
|
||||
<p><strong>New</strong>, a <strong>Load</strong> that picks a different project, <strong>ReLoad</strong>, a <strong>Save As</strong> to a location other
|
||||
than the one already open, and <strong>Close Project</strong> discard every page the session has built and
|
||||
rebuild it against whatever the project is afterwards — nothing at all, after <strong>Close Project</strong>.
|
||||
That is what stops a screen showing values from a project that is not open any more, and it is also
|
||||
why in-page state that was never saved does not survive one.</p>
|
||||
@@ -158,16 +164,18 @@ the full text with whatever caption came with it. The icon in front decodes the
|
||||
information mark for a plain status line, a green tick for a success, an amber triangle for a warning,
|
||||
a red mark for a failure. The clock button beside it opens <strong>Recent messages</strong> — newest first, capped
|
||||
at a hundred, each row repeating its severity as a coloured strip down the left edge and carrying the
|
||||
time it arrived. That list belongs to this browser and this session: <strong>Clear</strong> empties it, a reload
|
||||
empties it, and it is written down nowhere.</p>
|
||||
<p><strong>Middle — the session strip.</strong> It is drawn only while a run has produced something, and the space is
|
||||
simply empty the rest of the time. A glyph leads each line — a locator mark on a cursor tick, the
|
||||
time it arrived. That list belongs to this browser and this session: <strong>Clear</strong> empties it and returns
|
||||
the line in front of it to <strong>Ready</strong>, a reload empties it, and it is written down nowhere.</p>
|
||||
<p><strong>Middle — the session strip.</strong> It is drawn only while a run has produced something, it is emptied by
|
||||
a project change, and the space is simply empty the rest of the time. A glyph leads each line — a locator mark on a cursor tick, the
|
||||
message's own severity mark otherwise — and an anchor follows it in a monospaced prefix wherever the
|
||||
entry carries one: a cursor line carries <code>Sn</code> and the sentence index it sits on, a message line the
|
||||
anchor the message itself supplies. Hovering opens the recent activity behind it; clicking pins that
|
||||
list open.</p>
|
||||
<p><strong>Right — the background zone.</strong> It appears only while a project file operation is in flight, names
|
||||
the operation and the path it is working on, and vanishes when the operation ends.</p>
|
||||
anchor the message itself supplies. Hovering opens the recent activity behind it — newest first,
|
||||
capped at thirty, with a run of consecutive cursor ticks collapsed into its latest; clicking pins
|
||||
that list open.</p>
|
||||
<p><strong>Right — the background zone.</strong> It appears only while one of the <strong>Project</strong> menu's operations is in
|
||||
flight — <strong>Close Project</strong> included — names the operation and the path it is working on, and vanishes
|
||||
when the operation ends.</p>
|
||||
<p>Switching the language re-resolves the interface at once and without navigating: the menus, the page
|
||||
title in the bar and the browser tab title all change. The two message regions do not follow. Each
|
||||
line in the recent list and in the session strip keeps the language it was raised in, so a footer read
|
||||
@@ -188,9 +196,6 @@ healthy rather than every connection that exists.</p>
|
||||
explain and none appears. The tooltip lists one row per connection, <code>Rendering</code>, <code>Shell</code>, <code>NcDiag</code> and
|
||||
the rest, and those names are identifiers rather than interface text: in a translated session only the
|
||||
state beside each name changes language.</p>
|
||||
<p>The buttons that hide those panels' columns are remembered per page. The two tree pages each keep
|
||||
their own column choices, while the dock widths and the list of unfolded tree nodes are single
|
||||
settings both of them share — widening the dock on Execution widens it on General Setup too.</p>
|
||||
<h2 id="see-also">See Also</h2>
|
||||
<ul>
|
||||
<li><a href="index.html">Basics</a> — the rest of what is true on every screen</li>
|
||||
|
||||
@@ -100,7 +100,7 @@ job needs one.</p>
|
||||
<li><a href="basics/index.html">Basics</a> — The sign-in gate and what is true behind it: the window frame, the project the rest of the application is configured against, the ways one screen leads to another, the preferences, and the surfaces that report what the service is doing</li>
|
||||
<li><a href="setup/index.html">Setup</a> — The machine tool, spindle, fixture, workpiece and controller a simulation runs against, where each is placed relative to the machine, and the tool house and coolant around them</li>
|
||||
<li><a href="run/index.html">Running a Simulation</a> — The command list a run executes, playing it, watching it, reading a single step, and diagnosing what went wrong</li>
|
||||
<li><a href="utilities/index.html">Utilities</a> — The supporting screens the Page menu lists below its first separator: the server's file explorer, the mechanism builder, and the legacy controller settings</li>
|
||||
<li><a href="utilities/index.html">Utilities</a> — The supporting screens the Page menu lists below its first separator: the server's file explorer and the mechanism builder</li>
|
||||
</ul>
|
||||
<h2 id="see-also">See Also</h2>
|
||||
<ul>
|
||||
|
||||
@@ -90,8 +90,11 @@
|
||||
<p>A mission written as one Script runs, and tells you nothing. The same run written as commands reads
|
||||
as values, switches a row at a time, and — with two Record Meshed Geometry entries around the
|
||||
program — restarts from where the last run got to instead of from the stock.</p>
|
||||
<p>This page is the layout that gets you all three. It is a recommendation, not a rule: every command
|
||||
is placeable anywhere, and <a href="building-a-mission.html">Building a Mission</a> is the mechanics.</p>
|
||||
<p>This page is the layout that gets you all three. <strong>Treat it as the shape a project starts from, not
|
||||
as an optimisation to add later</strong> — the two records in particular are part of the layout, and a
|
||||
mission built without them replays from the stock every single time. Placement itself is not
|
||||
enforced: every command goes anywhere, and <a href="building-a-mission.html">Building a Mission</a> is the
|
||||
mechanics.</p>
|
||||
<h2 id="the-shape">The shape</h2>
|
||||
<table>
|
||||
<thead>
|
||||
|
||||
@@ -141,6 +141,53 @@ kind can appear in this dialog before this manual has a page for it.</p>
|
||||
pressed. The five category headings are the grouping in the table above, the search box at the top
|
||||
is what narrows them, and the first result is highlighted ready for <kbd>Enter</kbd>.</p>
|
||||
<p><img src="building-a-mission-img/add-command.en.png" alt="The Add Command dialog open over the Execution page: a Search commands box above thirteen entries under five headings — Setup with Machining Resolution, Machining Motion Resolution, Collision Detection, Pause on Failure and Physics; Program with Program File, NC Code and Script; Optimization with NC Optimization Config; Output with Post-Execution, Record Meshed Geometry and Export Meshed Geometry STL; and Flow with List"></p>
|
||||
<h2 id="the-shape-to-start-from">The shape to start from</h2>
|
||||
<p>An empty list is legal, but it is not where a project should end up. A finished mission has the
|
||||
same shape whatever it machines: <strong>setup at the top, the program in the middle, the program held
|
||||
between two Record Meshed Geometry entries, output at the bottom.</strong></p>
|
||||
<table>
|
||||
<thead>
|
||||
<tr>
|
||||
<th></th>
|
||||
<th></th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>Setup</td>
|
||||
<td>Machining Resolution, Machining Motion Resolution, Collision Detection, Pause on Failure, Physics</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Output</td>
|
||||
<td><strong>Record Meshed Geometry</strong> — <code>Cache/<stage>-init.wct</code>, the stock</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Program</td>
|
||||
<td>Program File</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Output</td>
|
||||
<td><strong>Record Meshed Geometry</strong> — <code>Cache/<stage>-done.wct</code>, the result</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Output</td>
|
||||
<td>Post-Execution</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<p>The two records are what make a run restartable, and they are part of the shape rather than an
|
||||
advanced extra — a mission without them replays the whole job from the stock every time. Two rules
|
||||
travel with them:</p>
|
||||
<ul>
|
||||
<li><strong>Machining Resolution belongs above the first record.</strong> The cache is meshed at whatever
|
||||
resolution is in force when the record runs, so a resolution set below it is silently baked out
|
||||
of the file.</li>
|
||||
<li><strong>Keep the first record where the stock is an STL, drop it where the stock is procedural</strong> (a box
|
||||
or a cylindroid) or is already a recorded mesh. Meshing an STL is a fixed cost paid on every
|
||||
play; a box the kernel builds instantly, and caching it costs more than it saves.</li>
|
||||
</ul>
|
||||
<p><a href="a-mission-that-resumes.html">A Mission That Resumes</a> is this layout in full, with the reasoning and
|
||||
the measurements behind each row.</p>
|
||||
<h2 id="read-a-row">Read a row</h2>
|
||||
<p>Each row shows the command's kind followed by the detail that identifies it, in brackets. Where you
|
||||
can name a command that detail is the title you typed, so a row still says what it is after it has
|
||||
@@ -215,7 +262,7 @@ the child node's own checkbox. Which commands do that, and what each card holds,
|
||||
<li><a href="index.html">Running a Simulation</a> — the rest of running a job</li>
|
||||
<li><a href="playing-a-program.html">Playing a Program</a> — the two commands that put NC code into a run</li>
|
||||
<li><a href="the-other-commands.html">The Other Commands</a> — what the rest of the command kinds are for</li>
|
||||
<li><a href="a-mission-that-resumes.html">A Mission That Resumes</a> — a layout that reads as values and restarts mid-job</li>
|
||||
<li><a href="a-mission-that-resumes.html">A Mission That Resumes</a> — the shape a mission should start from, in full</li>
|
||||
<li><a href="running-a-simulation.html">Starting and Stepping</a> — the transport that plays the list built here</li>
|
||||
<li><a class="xref" href="../../anatomy/execution/mission/mission-root-panel.html">Mission Root Panel</a> — the component behind this branch: the list editor, the picker and the three drag landings</li>
|
||||
<li><a class="xref" href="../../anatomy/execution/mission/ListCommand-panel.html">List Command Panel</a> — the component behind a group: what nesting costs, and what a disabled list skips</li>
|
||||
|
||||
@@ -222,7 +222,7 @@ to what the mission asked for — see <a href="the-program-branch.html">The Prog
|
||||
<li><a href="the-program-branch.html">The Program Branch</a> — what the run recorded against each line</li>
|
||||
<li><a href="the-other-commands.html">The Other Commands</a> — the rest of the command kinds, including the script that drives a session without NC</li>
|
||||
<li><a class="xref" href="../../anatomy/execution/mission/NcFileCommand-panel.html">NcFileCommand Panel</a> — the component behind Program File: its fields, its picker and the endpoints behind the banner</li>
|
||||
<li><a href="a-mission-that-resumes.html">A Mission That Resumes</a> — the layout these two commands sit in when the run has to be restartable</li>
|
||||
<li><a href="a-mission-that-resumes.html">A Mission That Resumes</a> — the layout these two commands sit in, and the records that bracket them</li>
|
||||
<li><a class="xref" href="../../anatomy/execution/mission/NcCodeCommand-panel.html">NcCodeCommand Panel</a> — the component behind NC Code: its editor, its stats row and how it saves</li>
|
||||
</ul>
|
||||
|
||||
|
||||
@@ -227,7 +227,7 @@ Pause with <kbd>F6</kbd> first.</p>
|
||||
<li><a href="inspecting-a-step.html">Inspecting a Step</a> — the column that reads whichever step you stopped on</li>
|
||||
<li><a href="when-something-goes-wrong.html">When Something Goes Wrong</a> — what to read when the run does not do what you expected</li>
|
||||
<li><a href="../basics/the-app-window.html">The Application Window</a> — the menu bar's connection badge, and the footer this page's state is reported in</li>
|
||||
<li><a href="a-mission-that-resumes.html">A Mission That Resumes</a> — how to lay the mission out so a stopped run restarts from where it got to</li>
|
||||
<li><a href="a-mission-that-resumes.html">A Mission That Resumes</a> — the shape a mission should have, and how it lets a stopped run restart</li>
|
||||
<li><a class="xref" href="../../anatomy/execution/execution-tool-bar.html">Execution Tool Bar</a> — the component behind these buttons: the enable rules, the status feed and the key bindings</li>
|
||||
</ul>
|
||||
|
||||
|
||||
@@ -165,9 +165,12 @@ only G54–G57 — and, on Fanuc, Mazak and Syntec, the extended <code>G59.1</co
|
||||
brand-neutral table that sits behind the brand table; it shows the <code>G54.1P</code> and <code>G505</code>–<code>G599</code> rows
|
||||
once a value is non-zero or the <strong>Show all</strong> toggle is on. Each row carries <strong>P0</strong>, which writes the machine coordinate the
|
||||
workpiece's program-zero anchor sits at, and <strong>M0</strong>, which writes machine zero; clicking anywhere in
|
||||
a row also marks that coordinate on the canvas. Aligning program zero <em>onto</em> a row's offset is not
|
||||
on this branch: <strong>Align P0</strong> is on the Legacy Controller screen's Coordinate Table tab, which edits a
|
||||
separate controller model — <a href="../utilities/legacy-controller.html">Legacy Controller</a>.</p>
|
||||
a row also marks that coordinate on the canvas. Both write into the table; neither moves the part.
|
||||
The other direction — moving the part so that program zero lands on the offset a row already
|
||||
holds — is not offered on the runner path: this branch is the runner's own settings face and has
|
||||
no such control, and the Legacy-Controller screen that used to carry one (Align P0) was removed on
|
||||
2026-09-11. Placing the part on a recorded offset is done by hand —
|
||||
<a href="program-zero-alignment.html">Program Zero Alignment</a>.</p>
|
||||
<h2 id="a-table-that-is-not-there">A table that is not there</h2>
|
||||
<p>A node the active brand has no concept of is never created rather than shown and disabled — Frames
|
||||
on Fanuc, Retained Common Variables on Siemens, Block Skip / Delete on Heidenhain — and a <code>?tree=</code>
|
||||
@@ -189,7 +192,6 @@ settings; leaving it off on a project that plays neither costs nothing.</p>
|
||||
<h2 id="see-also">See Also</h2>
|
||||
<ul>
|
||||
<li><a href="../../technique/nc-dialects/index.html">NC Dialects</a> — what each brand's G and M vocabulary actually does, once the brand is picked</li>
|
||||
<li><a href="../utilities/legacy-controller.html">Legacy Controller</a> — the superseded screen that still owns Align P0 and the two switches this branch has no editor for</li>
|
||||
<li><a href="machine-tool.html">Machine Tool</a> — the chain whose axes fill the per-axis rows on the machine plane</li>
|
||||
<li><a href="program-zero-alignment.html">Program Zero Alignment</a> — the other half of a work offset: where program zero sits on the workpiece</li>
|
||||
<li><a href="index.html">Setup</a> — the rest of the pre-simulation configuration</li>
|
||||
|
||||
@@ -180,7 +180,7 @@ able to produce an STL, so the voxel meshed-geometry kind offered on the Workpie
|
||||
<li><a href="anchor.html">Anchor</a> — what the two transform nodes above are for, and the order to place them in</li>
|
||||
<li><a href="workpiece.html">Workpiece</a> — the part this fixture holds, and its own geometry and material</li>
|
||||
<li><a href="machine-tool.html">Machine Tool</a> — the chain carrying the table buckle the fixture is pinned to</li>
|
||||
<li><a href="program-zero-alignment.html">Program Zero Alignment</a> — the alignment that moves this fixture's Geom To Table transform when program zero is aligned onto a work offset</li>
|
||||
<li><a href="program-zero-alignment.html">Program Zero Alignment</a> — the task that moves this fixture's Geom To Table transform when the part has to be placed on a recorded work offset</li>
|
||||
<li><a href="index.html">Setup</a> — the rest of the pre-simulation configuration</li>
|
||||
</ul>
|
||||
|
||||
|
||||
@@ -125,7 +125,7 @@ body types, the two ways a cutting envelope is expressed, the upper beam and the
|
||||
<li><a href="../../technique/nc-dialects/index.html">NC Dialects</a> — what each controller brand's code actually does, brand by brand</li>
|
||||
<li><a href="../basics/index.html">Basics</a> — the window, the project and the screens these tasks are performed in</li>
|
||||
<li><a href="../run/index.html">Running a Simulation</a> — what the equipment configured here is then used for</li>
|
||||
<li><a href="../utilities/index.html">Utilities</a> — the screens beside these tasks: browsing a project's files, assembling a machine chain, and the settings the legacy controller screen still owns</li>
|
||||
<li><a href="../utilities/index.html">Utilities</a> — the screens beside these tasks: browsing a project's files and assembling a machine chain</li>
|
||||
</ul>
|
||||
|
||||
</article>
|
||||
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 60 KiB |
@@ -136,8 +136,7 @@ returned to no offset at all.</li>
|
||||
<code>/general-setup?tree=equipment/controller/program-data/work-coordinates</code>. The grey line above the
|
||||
table names where this brand keeps the offsets — on Fanuc, its own parameter table — and the rows
|
||||
below it are the coordinate ids that brand holds, with only <code>G54</code> carrying a value here. The panel
|
||||
is narrow, so the row actions sit off the right edge; the same three are shown in full on the Legacy
|
||||
Controller screen below.</p>
|
||||
is narrow, so the row actions sit off the right edge.</p>
|
||||
<p><img src="program-zero-alignment-img/work-coordinates.en.png" alt="The Work Coordinates leaf of the Control Tree selected on the General Setup page, its panel showing a caption reading that the offsets are stored in the Fanuc parameter table and a table of G54 through G57 rows with X, Y and Z fields, G54 holding values and the rest zero"></p>
|
||||
<p><strong>P0 has something to write only once the scene is assembled.</strong> It works out where the program-zero
|
||||
anchor is by walking the machine chain to it, so a project with no machine tool attached, or a
|
||||
@@ -146,32 +145,25 @@ the machine position at program zero rather than writing a wrong number.</p>
|
||||
<p>The row's values can also be typed in directly when the offset is already known from the machine.
|
||||
Clicking anywhere in a row marks that coordinate on the canvas, so the offset can be seen rather
|
||||
than only read.</p>
|
||||
<h2 id="reproducing-a-real-cut-move-the-workpiece-onto-the-offset">Reproducing a real cut: move the workpiece onto the offset</h2>
|
||||
<p>Going the other way — leaving the offset alone and moving the part to meet it — is <strong>Align P0</strong>, and
|
||||
it is on the Legacy Controller screen's <strong>Coordinate Table</strong> tab (<code>/controller/coordinate-table</code>),
|
||||
not on the Controller branch. It moves the workpiece and fixture together, by changing where the
|
||||
fixture sits on the machine table, until program zero lands on the offset the row holds. The toast
|
||||
reports the translation it assigned.</p>
|
||||
<p>The tab on a demo project. Each row carries <strong>P0</strong> and <strong>M0</strong> — the same two writes the branch's
|
||||
leaf offers — and <strong>ALIGN P0</strong> beside them, which is the one control that moves the part instead of
|
||||
writing a number. <strong>Undo Align</strong> and <strong>Redo Align</strong> in the header step back and forth through the
|
||||
alignments this screen has recorded; <strong>Show on Display</strong> turns the coordinate marker in the viewer on
|
||||
and off, and the checkbox at the left of each row picks which coordinate it marks.</p>
|
||||
<p><img src="program-zero-alignment-img/align-p0.en.png" alt="The Legacy Controller screen's Coordinate Table tab: an ISO Coordinate Table with Undo Align, Redo Align and Show on Display in its header, and rows G54 through G59.5 each carrying X, Y and Z fields and an Actions column with P0, M0 and ALIGN P0"></p>
|
||||
<p>Align P0 needs a workpiece, a fixture and a machine tool on the project; without all three it writes
|
||||
nothing and says so. Driving the screen itself — the tab strip, the alignment history and what it
|
||||
does and does not survive — is <a href="../utilities/legacy-controller.html">Legacy Controller</a>.</p>
|
||||
<div class="WARNING">
|
||||
<h5>Warning</h5>
|
||||
<p><strong>Align P0 reads a different table from the one the run uses.</strong> The offsets on the Legacy
|
||||
Controller screen and the offsets on the Controller branch's Work Coordinates leaf are two
|
||||
separate stores: typing a value into one does not change the other, and nothing keeps them in
|
||||
step. A run resolves its work offsets through the branch's table, while Align P0 takes its target
|
||||
from the legacy screen's. So before aligning, check that the row you are about to press <strong>ALIGN
|
||||
P0</strong> on holds the same offset as the branch's row of the same name — otherwise the part is moved
|
||||
onto a number the program will never use. A project built with both tables filled in agrees only
|
||||
because it was written that way.</p>
|
||||
</div>
|
||||
<h2 id="reproducing-a-real-cut-place-the-workpiece-on-the-offset">Reproducing a real cut: place the workpiece on the offset</h2>
|
||||
<p>Going the other way — leaving the offset alone and moving the part to meet it — is not offered on
|
||||
the runner path. The Legacy-Controller screen that used to carry a one-press control for it
|
||||
(Align P0) was removed on 2026-09-11, and the Work Coordinates leaf's two row actions both write
|
||||
the row — <strong>P0</strong> from where program zero sits, <strong>M0</strong> to machine zero — and neither moves the part.
|
||||
So in the reproducing direction the part is placed by hand, and the row checks the placement rather
|
||||
than making it:</p>
|
||||
<ol>
|
||||
<li>Type the recorded offset into the row the program uses — the values can be entered directly, as
|
||||
above — and click the row so the canvas marks that coordinate.</li>
|
||||
<li>Move the part to meet the mark by changing where the fixture sits on the machine table: the
|
||||
fixture's <strong>Geom To Table</strong> transform, in <a href="anchor.html">Anchor</a>. The workpiece rides on the
|
||||
fixture, so its program-zero anchor moves with it.</li>
|
||||
<li>Once the program-zero anchor sits on the mark, the part sits where it really sat. Pressing <strong>P0</strong>
|
||||
afterwards rewrites the row from the scene, so use it only as a check: the numbers it writes should
|
||||
be the ones you typed, and any difference is how far the placement is off. If they differ, fix the
|
||||
placement and type the recorded offset back in — the run resolves against whatever the row holds,
|
||||
and P0 has just overwritten it.</li>
|
||||
</ol>
|
||||
<h2 id="checking-that-it-worked">Checking that it worked</h2>
|
||||
<p>A wrong alignment — a wrong offset, or a workpiece at the wrong height — shows up as <strong>overcut</strong>,
|
||||
<strong>collision</strong> or <strong>nocut</strong>, and it shows up early: usually within the first hundred or so NC lines.
|
||||
@@ -227,17 +219,16 @@ is easiest to reason about when each sits at the middle of the face it meets:</p
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<p>Align P0 does not depend on this convention — it works out the fixture's placement from the
|
||||
assembly as it stands, whatever the transforms hold — but a scene built this way is far easier to
|
||||
check by eye.</p>
|
||||
<p>Nothing above depends on this convention — <strong>P0</strong> walks the assembly as it stands, whatever the
|
||||
transforms hold — but a scene built this way is far easier to check by eye, and far easier to place
|
||||
by hand in the reproducing direction.</p>
|
||||
<h2 id="see-also">See Also</h2>
|
||||
<ul>
|
||||
<li><a href="anchor.html">Anchor</a> — placing the workpiece, fixture and tool relative to the machine, which comes before this</li>
|
||||
<li><a class="xref" href="../../technique/mechanism/assembly-anchors.html">Assembly Anchors</a> — the named buckle anchors this alignment resolves against</li>
|
||||
<li><a href="workpiece.html">Workpiece</a> — the branch carrying the Geom To Program Zero transform this task sets, and the Mesh resolution the check above uses</li>
|
||||
<li><a href="fixture.html">Fixture</a> — the transform Align P0 rewrites when it moves the part onto an offset</li>
|
||||
<li><a href="fixture.html">Fixture</a> — the Geom To Table transform that moves the part onto a recorded offset in the reproducing direction</li>
|
||||
<li><a href="controller.html">Controller</a> — the branch whose work-offset table a run resolves against</li>
|
||||
<li><a href="../utilities/legacy-controller.html">Legacy Controller</a> — the screen Align P0 lives on, and its alignment history</li>
|
||||
<li><a href="../../technique/nc-dialects/index.html">NC Dialects</a> — how each brand's code names the work offset this alignment is expressed against</li>
|
||||
<li><a class="xref" href="../../workflows/project-data-checklist.html">Project Data Checklist</a> — the collection step this alignment closes</li>
|
||||
<li><a class="xref" href="../../workflows/basic-simulation.html">Workflow: Basic Machining Simulation</a> — driving a simulation from an NC file or a controller log</li>
|
||||
|
||||
@@ -88,16 +88,14 @@
|
||||
<h1 id="utilities">Utilities</h1>
|
||||
|
||||
<p>The supporting screens the Page menu lists below its first separator, rather than the three that
|
||||
carry a job from the tool house to a finished run: browsing the files a project is built from,
|
||||
assembling a mechanism outside the equipment tree, and the controller screen that still owns a
|
||||
handful of settings on its own. Two of the three open with no project loaded, which is what makes
|
||||
them supporting screens rather than steps.</p>
|
||||
carry a job from the tool house to a finished run: browsing the files a project is built from, and
|
||||
assembling a mechanism outside the equipment tree. Both open with no project loaded, which is what
|
||||
makes them supporting screens rather than steps.</p>
|
||||
<p>Ordered as the Page menu lists them.</p>
|
||||
<h2 id="pages">Pages</h2>
|
||||
<ul>
|
||||
<li><a href="file-explorer.html">File Explorer</a> — Finding, reading, editing and moving the server's files, and the editor beside the listing</li>
|
||||
<li><a href="mech-builder.html">Mechanism Builder</a> — Building a mechanism out of anchors and branches, and writing it out as a machine tool file</li>
|
||||
<li><a href="legacy-controller.html">Legacy Controller</a> — The three settings that have no editor anywhere else, and which face to edit for everything else</li>
|
||||
</ul>
|
||||
<h2 id="see-also">See Also</h2>
|
||||
<ul>
|
||||
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 34 KiB |
BIN
Binary file not shown.
|
Before Width: | Height: | Size: 61 KiB |
@@ -1,208 +0,0 @@
|
||||
<!DOCTYPE html>
|
||||
<html>
|
||||
<head>
|
||||
<meta charset="utf-8">
|
||||
<title>Legacy Controller | HiAPI-C# 2025 </title>
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
<meta name="title" content="Legacy Controller | HiAPI-C# 2025 ">
|
||||
|
||||
|
||||
<link rel="icon" href="../../img/HiAPI.favicon.ico">
|
||||
<link rel="stylesheet" href="../../public/docfx.min.css">
|
||||
<link rel="stylesheet" href="../../public/main.css">
|
||||
<meta name="docfx:navrel" content="../../toc.html">
|
||||
<meta name="docfx:tocrel" content="toc.html">
|
||||
|
||||
<meta name="docfx:rel" content="../../">
|
||||
|
||||
|
||||
|
||||
<meta name="loc:inThisArticle" content="In this article">
|
||||
<meta name="loc:searchResultsCount" content="{count} results for "{query}"">
|
||||
<meta name="loc:searchNoResults" content="No results for "{query}"">
|
||||
<meta name="loc:tocFilter" content="Filter by title">
|
||||
<meta name="loc:nextArticle" content="Next">
|
||||
<meta name="loc:prevArticle" content="Previous">
|
||||
<meta name="loc:themeLight" content="Light">
|
||||
<meta name="loc:themeDark" content="Dark">
|
||||
<meta name="loc:themeAuto" content="Auto">
|
||||
<meta name="loc:changeTheme" content="Change theme">
|
||||
<meta name="loc:copy" content="Copy">
|
||||
<meta name="loc:downloadPdf" content="Download PDF">
|
||||
|
||||
<script type="module" src="./../../public/docfx.min.js"></script>
|
||||
|
||||
<script>
|
||||
const theme = localStorage.getItem('theme') || 'auto'
|
||||
document.documentElement.setAttribute('data-bs-theme', theme === 'auto' ? (window.matchMedia('(prefers-color-scheme: dark)').matches ? 'dark' : 'light') : theme)
|
||||
</script>
|
||||
|
||||
</head>
|
||||
|
||||
<body class="tex2jax_ignore" data-layout="" data-yaml-mime="">
|
||||
<header class="bg-body border-bottom">
|
||||
<nav id="autocollapse" class="navbar navbar-expand-md" role="navigation">
|
||||
<div class="container-xxl flex-nowrap">
|
||||
<a class="navbar-brand" href="../../index.html">
|
||||
<img id="logo" class="svg" src="../../img/HiAPI.logo.png" alt="">
|
||||
|
||||
</a>
|
||||
<button class="btn btn-lg d-md-none border-0" type="button" data-bs-toggle="collapse" data-bs-target="#navpanel" aria-controls="navpanel" aria-expanded="false" aria-label="Toggle navigation">
|
||||
<i class="bi bi-three-dots"></i>
|
||||
</button>
|
||||
<div class="collapse navbar-collapse" id="navpanel">
|
||||
<div id="navbar">
|
||||
<form class="search" role="search" id="search">
|
||||
<i class="bi bi-search"></i>
|
||||
<input class="form-control" id="search-query" type="search" disabled placeholder="Search" autocomplete="off" aria-label="Search">
|
||||
</form>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
</nav>
|
||||
</header>
|
||||
|
||||
<main class="container-xxl">
|
||||
<div class="toc-offcanvas">
|
||||
<div class="offcanvas-md offcanvas-start" tabindex="-1" id="tocOffcanvas" aria-labelledby="tocOffcanvasLabel">
|
||||
<div class="offcanvas-header">
|
||||
<h5 class="offcanvas-title" id="tocOffcanvasLabel">Table of Contents</h5>
|
||||
<button type="button" class="btn-close" data-bs-dismiss="offcanvas" data-bs-target="#tocOffcanvas" aria-label="Close"></button>
|
||||
</div>
|
||||
<div class="offcanvas-body">
|
||||
<nav class="toc" id="toc"></nav>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div class="content">
|
||||
<div class="actionbar">
|
||||
<button class="btn btn-lg border-0 d-md-none" type="button" data-bs-toggle="offcanvas" data-bs-target="#tocOffcanvas" aria-controls="tocOffcanvas" aria-expanded="false" aria-label="Show table of contents">
|
||||
<i class="bi bi-list"></i>
|
||||
</button>
|
||||
|
||||
<nav id="breadcrumb"></nav>
|
||||
</div>
|
||||
|
||||
<article data-uid="">
|
||||
<h1 id="legacy-controller">Legacy Controller</h1>
|
||||
|
||||
<p>The Legacy Controller screen owns three settings that have no editor anywhere else in the
|
||||
application. It edits a different controller model from the General Setup page's Controller branch,
|
||||
and neither screen sees the other's edits: those three are edited here, and everything else on the
|
||||
branch.</p>
|
||||
<h2 id="where-it-is">Where it is</h2>
|
||||
<p>Its own page, reached from the menu bar's <strong>Page → Legacy-Controller</strong>, at <code>/controller/:tab?</code>. It is
|
||||
not a Control-Tree branch; nothing in a tree reaches it. The left pane is a strip of seven tabs, each
|
||||
addressable as the last URL segment: <strong>Coordinate Table</strong> (<code>coordinate-table</code>, which a bare
|
||||
<code>/controller</code> opens), <strong>Datum Preset</strong>, <strong>Datum Shift</strong>, <strong>Offset Table</strong>, <strong>Machine</strong>, <strong>Brand</strong> and
|
||||
<strong>Config</strong>; the two datum tab buttons are shown only while the brand reads Heidenhain. The right pane
|
||||
is a 3D view, described under <a href="#what-the-right-pane-draws">What the right pane draws</a> below.</p>
|
||||
<h2 id="which-face-to-edit">Which face to edit</h2>
|
||||
<p>Controller setup for a project belongs on the General Setup page's Controller branch —
|
||||
<a href="../setup/controller.html">Controller</a>. The brand, the stroke limits, the rapid feedrate, the
|
||||
tool-change time, the tool offset table, the work coordinates and the Heidenhain datum tables all
|
||||
have an editor there as well, and apart from one shared project flag — <strong>Set ideal offset dependent
|
||||
on tool house</strong>, which this screen's Offset Table tab and the branch's Tool Offsets leaf both write —
|
||||
the two screens edit different models. A value changed on one is not the value the other shows.</p>
|
||||
<h2 id="align-program-zero-onto-a-work-offset">Align program zero onto a work offset</h2>
|
||||
<p><strong>Align P0</strong> is on the <strong>Coordinate Table</strong> tab and nowhere else. The branch's Work Coordinates leaf
|
||||
carries <strong>P0</strong> and <strong>M0</strong> on every row too; the alignment is this screen's. Which direction an
|
||||
alignment runs — the work offset moved onto program zero, or program zero moved onto the offset as
|
||||
this button does — and where program zero sits on the workpiece in the first place, are both
|
||||
<a href="../setup/program-zero-alignment.html">Program Zero Alignment</a>.</p>
|
||||
<ol>
|
||||
<li>Find the row holding the work offset program zero should sit at. Ticking the table's selection
|
||||
column is not part of this — that only moves the viewer's coordinate marker onto the row, and
|
||||
that marker is not drawn until <strong>Show on Display</strong> in the tab's toolbar is on. It ships off, so
|
||||
on an untouched project the selection column appears to do nothing.</li>
|
||||
<li>Press <strong>Align P0</strong> in that row. It does not write the coordinate — it moves the workpiece and
|
||||
fixture together so that program zero lands on the offset the row already holds. The toast names
|
||||
the translation it assigned. It needs a workpiece, a fixture and a machine tool on the project —
|
||||
<a href="../setup/index.html">Setup</a> — and without them nothing is written and the button says so.</li>
|
||||
<li><strong>Undo Align</strong> and <strong>Redo Align</strong>, in the tab's toolbar, step back and forward through the
|
||||
alignments this screen has recorded.</li>
|
||||
</ol>
|
||||
<p>That history belongs to the screen rather than to the project: it holds 32 steps, survives a walk to
|
||||
another page and back, and is cleared when the project changes or the browser reloads the page. Each
|
||||
step restores the whole transform from a snapshot taken earlier, so if the fixture's placement was
|
||||
changed on another screen in between, an undo replaces that change rather than merging with it.</p>
|
||||
<p><img src="legacy-controller-img/coordinate-table.en.png" alt="The Legacy Controller on its Coordinate Table tab: five tab buttons, the ISO Coordinate Table with its Undo Align, Redo Align and Show on Display toolbar, and fifteen work-offset rows each carrying P0, M0 and Align P0 in an Actions column"></p>
|
||||
<p><em>At <code>/controller/coordinate-table</code>. <strong>Align P0 is a row action</strong> — every offset from G54 to G59.9
|
||||
has its own, and there is no single button for the table. The tab strip shows five buttons here
|
||||
rather than seven because this project's brand is not Heidenhain; the two datum tabs appear only
|
||||
under that brand, though their addresses stay valid under any of them.</em></p>
|
||||
<h2 id="the-two-switches-nothing-else-carries">The two switches nothing else carries</h2>
|
||||
<table>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Tab</th>
|
||||
<th>Setting</th>
|
||||
<th>What it is for</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td><strong>Config</strong></td>
|
||||
<td><strong>Enable Shortest Rotary Path</strong></td>
|
||||
<td>Takes each rotary axis of a block to the equivalent angle nearest the previous block's, so an axis turns the short way round instead of unwinding a whole turn. It arrives on. Under Heidenhain the same normalisation runs whatever the box reads, so clearing it changes nothing there.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><strong>Brand</strong></td>
|
||||
<td><strong>Master-axis character</strong></td>
|
||||
<td>Which rotary axis — <code>A</code>, <code>B</code> or <code>C</code> — the Heidenhain <code>PLANE … SEQ</code> orientations are resolved against; what that dialect's words do is <a href="../../technique/nc-dialects/index.html">NC Dialects</a>. The card holding it is present only while the brand reads Heidenhain.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<p>Both commit on the click. If the master-axis write is refused a toast says so, but the select goes on
|
||||
showing the character that was picked, so a reload is what shows which one actually took — and a
|
||||
reloaded <code>A</code> settles nothing, because the Brand tab also falls back to <code>A</code>, silently, when the read
|
||||
itself fails.</p>
|
||||
<p><img src="legacy-controller-img/config-tab.en.png" alt="The Config tab: a single Options card holding the Enable Shortest Rotary Path switch, turned on, above an information banner restating what it does"></p>
|
||||
<p><em>At <code>/controller/config</code>. The whole tab is that one switch. The master-axis select is not beside it
|
||||
— it is on the <strong>Brand</strong> tab and, as the table above says, only while the brand reads Heidenhain,
|
||||
which is why it is absent here.</em></p>
|
||||
<h2 id="what-the-right-pane-draws">What the right pane draws</h2>
|
||||
<p>The 3D view beside the tabs draws the same scene as the <a href="../run/index.html">Execution page</a>, and
|
||||
its <strong>Scene</strong> dropdown writes the same switches — so what is ticked here is ticked there. It offers
|
||||
three groups: the machine tool, the cutter, the workpiece and the fixture; the program-zero and
|
||||
work-offset markers, the Heidenhain one appearing only under that brand; and the dimension bar and
|
||||
colour scale bar. Of those, only the <strong>workpiece, the fixture and the dimension bar arrive on</strong>. The
|
||||
machine tool and the cutter arrive off, and so do the coordinate markers — the work-offset one is
|
||||
exactly what <strong>Show on Display</strong> turns on for this screen's table. A freshly loaded project
|
||||
therefore opens this pane with little or nothing in it, and that is the shipped state rather than a
|
||||
failure to draw.</p>
|
||||
<h2 id="see-also">See Also</h2>
|
||||
<ul>
|
||||
<li><a href="index.html">Utilities</a> — the other screens the Page menu lists beside this one</li>
|
||||
<li><a href="mech-builder.html">Mechanism Builder</a> — another of the supporting screens the Page menu lists, for assembling a machine chain</li>
|
||||
<li><a href="../setup/controller.html">Controller</a> — the branch that owns controller setup for a project, and every setting this screen does not exclusively hold</li>
|
||||
<li><a href="../setup/program-zero-alignment.html">Program Zero Alignment</a> — which direction an alignment runs, where program zero sits on the workpiece, and why this screen's table is not the one a run reads</li>
|
||||
<li><a class="xref" href="../../anatomy/legacy-controller.html">Legacy Controller Page</a> — the component behind this page: its seven tabs, how an edit commits, and its viewer</li>
|
||||
</ul>
|
||||
|
||||
</article>
|
||||
|
||||
<div class="contribution d-print-none">
|
||||
</div>
|
||||
|
||||
<div class="next-article d-print-none border-top" id="nextArticle"></div>
|
||||
|
||||
</div>
|
||||
|
||||
<div class="affix">
|
||||
<nav id="affix"></nav>
|
||||
</div>
|
||||
</main>
|
||||
|
||||
<div class="container-xxl search-results" id="search-results"></div>
|
||||
|
||||
<footer class="border-top text-secondary">
|
||||
<div class="container-xxl">
|
||||
<div class="flex-fill">
|
||||
<span> Copyright © 2025 <a href='https://superhightech.com.tw'>Tech Coordinate</a>. All rights reserved. <a href='https://superhightech.com.tw'>超級高科技股份有限公司</a> © 2025 版權所有 </span>
|
||||
</div>
|
||||
</div>
|
||||
</footer>
|
||||
</body>
|
||||
</html>
|
||||
@@ -125,7 +125,7 @@ editor.</p>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><strong>Load…</strong></td>
|
||||
<td>Opens the server file picker — <a href="file-explorer.html">File Explorer</a>'s browser in picker mode, over the roots that page lists — filtered to <code>*.GeneralMechanism</code> and <code>*.xml</code>. The server reads the file where it sits and remembers its folder.</td>
|
||||
<td>Opens the server file picker — <a href="file-explorer.html">File Explorer</a>'s browser in picker mode, over the roots that page lists — filtered to <code>*.GeneralMechanism</code>, <code>*.general-mech</code> and <code>*.xml</code> — the first is what this page's own Save As writes and what the shipped mechanism is named; the second is the older spelling hand-authored files still carry, and it loads the same way. The server reads the file where it sits and remembers its folder.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><strong>ReLoad</strong></td>
|
||||
@@ -146,14 +146,6 @@ where the result goes. Under the File menu the left column shows the open file's
|
||||
<code>(unsaved)</code> while the mechanism has no file yet — after <strong>New</strong>, until the first Save As.</p>
|
||||
<div class="NOTE">
|
||||
<h5>Note</h5>
|
||||
<p><strong>Load's file-type filter does not list the extension the shipped mechanisms use.</strong> The picker
|
||||
opens filtered to <code>*.GeneralMechanism</code> and <code>*.xml</code>, while the mechanism beside each shipped
|
||||
machine tool under the Resource root is named <code>.general-mech</code>. Switch the picker's file-type
|
||||
selector to <strong>All Files (*.*)</strong> to see it. The filter hides those files; it does not refuse
|
||||
them, and one picked that way loads normally.</p>
|
||||
</div>
|
||||
<div class="NOTE">
|
||||
<h5>Note</h5>
|
||||
<p><strong>Save As Machine Tool does not check the end-anchor keywords.</strong> The write succeeds and reports
|
||||
the file saved whatever the anchors are called, including a mechanism whose tool-end and
|
||||
worktable-end anchors are mis-cased or missing altogether. A file written here asks for its
|
||||
@@ -208,7 +200,6 @@ is the resting one. The sentence under the fields names the same three parts.</e
|
||||
<ul>
|
||||
<li><a href="file-explorer.html">File Explorer</a> — the server-side browser behind this page's Load and Save As dialogs, and the roots they offer</li>
|
||||
<li><a href="index.html">Utilities</a> — the other screens the Page menu lists beside this one</li>
|
||||
<li><a href="legacy-controller.html">Legacy Controller</a> — the other supporting screen in the Page menu, for the three settings nothing else edits</li>
|
||||
<li><a href="../setup/machine-tool.html">Building Virtual Machine Tools</a> — the naming keywords, branch direction and CAD practice a machine chain built here must follow, and where the saved file is attached to a project</li>
|
||||
<li><a class="xref" href="../../anatomy/util/mech-builder.html">Mechanism Builder Page</a> — the component behind this page: its cards, its file IO and how edits reach the canvas</li>
|
||||
</ul>
|
||||
|
||||
@@ -21,9 +21,6 @@
|
||||
<li>
|
||||
<a href="mech-builder.html" name="" title="Mechanism Builder">Mechanism Builder</a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="legacy-controller.html" name="" title="Legacy Controller">Legacy Controller</a>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
@@ -1,2 +1,2 @@
|
||||
|
||||
{"items":[{"name":"Overview","href":"index.html","topicHref":"index.html"},{"name":"File Explorer","href":"file-explorer.html","topicHref":"file-explorer.html"},{"name":"Mechanism Builder","href":"mech-builder.html","topicHref":"mech-builder.html"},{"name":"Legacy Controller","href":"legacy-controller.html","topicHref":"legacy-controller.html"}]}
|
||||
{"items":[{"name":"Overview","href":"index.html","topicHref":"index.html"},{"name":"File Explorer","href":"file-explorer.html","topicHref":"file-explorer.html"},{"name":"Mechanism Builder","href":"mech-builder.html","topicHref":"mech-builder.html"}]}
|
||||
|
||||
@@ -99,10 +99,10 @@
|
||||
interface is built to that language level, and an older browser cannot run it. The 3D view is
|
||||
rendered on the server and arrives as a stream of images, so the browser itself needs no graphics
|
||||
capability</li>
|
||||
<li><strong>Runtime</strong>: none to install. Both the web service and the Windows desktop application are
|
||||
published self-contained, so they carry the runtime they need. A .NET project that references the
|
||||
HiAPI packages directly is the one case that needs a runtime installed, and it must be <strong>.NET
|
||||
10.0</strong> — every published package targets it, and an earlier runtime cannot load them at all</li>
|
||||
<li><strong>Runtime</strong>: none to install. The web service is published self-contained, so it carries the
|
||||
runtime it needs. A .NET project that references the HiAPI packages directly is the one case that
|
||||
needs a runtime installed, and it must be <strong>.NET 10.0</strong> — every published package targets it, and
|
||||
an earlier runtime cannot load them at all</li>
|
||||
<li><strong>Memory (RAM)</strong>:
|
||||
<ul>
|
||||
<li>Minimum: 8GB RAM (suitable for low-resolution models)</li>
|
||||
|
||||
@@ -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 <ClassName>()</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 <ClassName>()</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/<tab></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>
|
||||
|
||||
+8
@@ -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
|
||||
|
||||
@@ -180,7 +180,7 @@ public static void Reg(XFactory factory = null)
|
||||
<p><strong><code>exhibitionOnly</code> suppresses the XML writes; it does not reach the copy.</strong> <code>MakeXmlSourceToFileRef</code> and <code>SaveToFileRef</code> both honour it and produce the reference elements without creating anything, but <code>StlFile</code>'s copy-on-save does not consult it at all. So a purely in-memory round trip still copies cached meshes into a base directory that lacks them — which is what a project load does when it materialises the runtime equipment from the authored one. Writing is not confined to saving.</p>
|
||||
</div>
|
||||
<h2 id="boot-path">Boot path</h2>
|
||||
<p>An application's entry point (web service <code>Program.cs</code>, WPF <code>App.xaml.cs</code>, test fixture, etc.) must call the appropriate top-level <code>Reg()</code> once at startup, before any project XML is deserialized. For the simulation pipeline this is:</p>
|
||||
<p>An application's entry point (web service <code>Program.cs</code>, the <code>App</code> class of a WPF host, test fixture, etc.) must call the appropriate top-level <code>Reg()</code> once at startup, before any project XML is deserialized. For the simulation pipeline this is:</p>
|
||||
<pre><code class="lang-csharp">LocalProjectService.Reg();
|
||||
</code></pre>
|
||||
<p><code>LocalProjectService.Reg()</code> chains <code>MachiningProject.Reg()</code>, which in turn chains every type the simulation pipeline may deserialize. After this single call returns, <code>XFactory.Default.Generators</code> carries the full deserialization graph.</p>
|
||||
|
||||
@@ -112,17 +112,17 @@ the word on its left to the word on its right.</p>
|
||||
<li><p>Reserved words are the topology keywords: <code>X</code>, <code>Y</code>, <code>Z</code>, <code>A</code>, <code>B</code>, <code>C</code> become motion axes, and <code>w</code>
|
||||
and <code>t</code> become the end anchors. <strong>Any other word is a plain component</strong> carried along without
|
||||
motion, such as <code>base</code> or <code>S</code> above. A code must name exactly one <code>[w]</code> and one <code>[t]</code>; the six
|
||||
axes are optional, and each may be used at most once. That uniqueness check reads the words
|
||||
without regard to letter case, so it refuses a code naming no table buckle at all — <em>the chain
|
||||
code must contain the table buckle [w]</em> — and a code letting two components claim one role —
|
||||
<em>more than one component claims the table buckle: [w], [W]</em>. A lone <code>[W]</code> satisfies it, one
|
||||
component claiming the role, and builds a component named <code>W</code>; that code is refused further
|
||||
along, by the exact-match end-anchor check below.</p>
|
||||
axes are optional, and each may be used at most once. Words merge by exact name, so no two
|
||||
components can claim one role; what the check refuses is a code naming no table buckle at all —
|
||||
<em>the chain code must contain the table buckle [w].</em> A code carrying only <code>[W]</code> is refused by
|
||||
that same check, and the message names the near miss: <em>The code carries [W], which differs only
|
||||
in letter case; the keyword is matched exactly, so rename it to [w].</em></p>
|
||||
</li>
|
||||
<li><p><strong>Spell the keywords exactly</strong> — upper case for the axes, lower case for <code>t</code> and <code>w</code>. Everything
|
||||
downstream of the code compares them as written: axis discovery, the default collision pairs, and
|
||||
the end-anchor check a machine file is loaded through. So a mis-cased axis contributes no motion,
|
||||
and a mis-cased end anchor stops the file loading, with a message naming the near miss.</p>
|
||||
<li><p><strong>Spell the keywords exactly</strong> — upper case for the axes, lower case for <code>t</code> and <code>w</code>. The code
|
||||
itself and everything downstream of it compare them as written: role resolution, axis discovery,
|
||||
the default collision pairs, and the end-anchor check a machine file is loaded through. So a
|
||||
mis-cased axis is a plain component contributing no motion, and a mis-cased end anchor stops the
|
||||
code building, with a message naming the near miss.</p>
|
||||
</li>
|
||||
<li><p><code>[]</code> is an anonymous component. Each occurrence is a separate one, it cannot be referred to from
|
||||
another segment, and it cannot hold a geometric shape — shapes are stored by component name.</p>
|
||||
|
||||
@@ -246,7 +246,8 @@ its own for the rest — see <a href="#siemens-sinumerik">Siemens SINUMERIK</a>.
|
||||
</table>
|
||||
<p>Radius compensation is resolved against the blocks that actually travel in the compensation plane. A
|
||||
block whose own words command no movement in that plane — a bare <code>G41</code> / <code>G42</code>, a comment, an empty
|
||||
line, a Z-only plunge — takes no offset of its own and no part in a corner:</p>
|
||||
line, a plunge along the plane normal (Z under G17) — takes no offset of its own and no part in a
|
||||
corner:</p>
|
||||
<ul>
|
||||
<li><strong>Start-up waits for motion.</strong> A <code>G41</code> or <code>G42</code> block that does not move in the plane does not
|
||||
start the offset; the first block that travels in the plane is the start-up block and takes the
|
||||
@@ -254,8 +255,15 @@ perpendicular (type A) offset. The blocks between them carry the previous block'
|
||||
so nothing moves on their account.</li>
|
||||
<li><strong>Corners are resolved between travelling blocks.</strong> Wordless blocks sitting between two moves are
|
||||
passed over, and the corner is the intersection of the two real segments. Running axes are the
|
||||
in-plane part of each displacement, so a ramping move keeps its full offset and a Z-only plunge
|
||||
stays on the offset line.</li>
|
||||
in-plane part of each displacement, so a ramping move keeps its full offset and a plunge along
|
||||
the plane normal stays on the offset line.</li>
|
||||
<li><strong>The plane cannot change inside a region.</strong> <code>G17</code> / <code>G18</code> / <code>G19</code> selects the
|
||||
compensation plane, and it may only be selected while compensation is cancelled. A plane
|
||||
code that resolves to a different plane while <code>G41</code> / <code>G42</code> is active — including one
|
||||
sharing its block with the <code>G40</code> that cancels the region — is reported as
|
||||
<code>RadiusComp--PlaneChangeInRegion</code>, because the corner spanning the change would be built
|
||||
from one running axis per plane. A control alarms there (Fanuc PS0037 CAN NOT CHANGE
|
||||
PLANE IN CRC). Re-selecting the plane already in force is not a change and is accepted.</li>
|
||||
<li><strong>A bare <code>G40</code> closes the region.</strong> The last compensated block ends on its own perpendicular
|
||||
offset rather than turning toward the first uncompensated move after the cancel. A <code>G40</code> that
|
||||
carries motion is the last corner's partner instead, and the compensated path meets the cancel
|
||||
|
||||
@@ -58,9 +58,6 @@ references:
|
||||
- uid: Anatomy-ControllerNativeParameters
|
||||
name: Native Parameters
|
||||
href: anatomy/general-setup/controller/machine/native-parameters.html
|
||||
- uid: Anatomy-ControllerPage
|
||||
name: Legacy Controller Page
|
||||
href: anatomy/legacy-controller.html
|
||||
- uid: Anatomy-ControllerParameters
|
||||
name: Interface Parameters
|
||||
href: anatomy/general-setup/controller/machine/interface-parameters.html
|
||||
@@ -158,7 +155,7 @@ references:
|
||||
name: Language Selection SubMenu
|
||||
href: anatomy/shell/language-selection-submenu.html
|
||||
- uid: Anatomy-LegacyControllerSettings
|
||||
name: Legacy Controller Settings
|
||||
name: Legacy Controller Model (HardNcEnv)
|
||||
href: anatomy/legacy-controller-settings.html
|
||||
- uid: Anatomy-ListCommandPanel
|
||||
name: List Command Panel
|
||||
@@ -92002,6 +91999,22 @@ references:
|
||||
isSpec: "True"
|
||||
fullName: Hi.Milling.Cutters.MillingCutter.ReliefAngle_rad
|
||||
nameWithType: MillingCutter.ReliefAngle_rad
|
||||
- uid: Hi.Milling.Cutters.MillingCutter.ReportUpperBeamGeometryIssues(System.IProgress{Hi.Common.Messages.IMessage},System.Object)
|
||||
name: ReportUpperBeamGeometryIssues(IProgress<IMessage>, object)
|
||||
href: api/Hi.Milling.Cutters.MillingCutter.html#Hi_Milling_Cutters_MillingCutter_ReportUpperBeamGeometryIssues_System_IProgress_Hi_Common_Messages_IMessage__System_Object_
|
||||
commentId: M:Hi.Milling.Cutters.MillingCutter.ReportUpperBeamGeometryIssues(System.IProgress{Hi.Common.Messages.IMessage},System.Object)
|
||||
name.vb: ReportUpperBeamGeometryIssues(IProgress(Of IMessage), Object)
|
||||
fullName: Hi.Milling.Cutters.MillingCutter.ReportUpperBeamGeometryIssues(System.IProgress<Hi.Common.Messages.IMessage>, object)
|
||||
fullName.vb: Hi.Milling.Cutters.MillingCutter.ReportUpperBeamGeometryIssues(System.IProgress(Of Hi.Common.Messages.IMessage), Object)
|
||||
nameWithType: MillingCutter.ReportUpperBeamGeometryIssues(IProgress<IMessage>, object)
|
||||
nameWithType.vb: MillingCutter.ReportUpperBeamGeometryIssues(IProgress(Of IMessage), Object)
|
||||
- uid: Hi.Milling.Cutters.MillingCutter.ReportUpperBeamGeometryIssues*
|
||||
name: ReportUpperBeamGeometryIssues
|
||||
href: api/Hi.Milling.Cutters.MillingCutter.html#Hi_Milling_Cutters_MillingCutter_ReportUpperBeamGeometryIssues_
|
||||
commentId: Overload:Hi.Milling.Cutters.MillingCutter.ReportUpperBeamGeometryIssues
|
||||
isSpec: "True"
|
||||
fullName: Hi.Milling.Cutters.MillingCutter.ReportUpperBeamGeometryIssues
|
||||
nameWithType: MillingCutter.ReportUpperBeamGeometryIssues
|
||||
- uid: Hi.Milling.Cutters.MillingCutter.SetShaperStlResolution(Hi.Geom.Resolution.PolarResolution2d)
|
||||
name: SetShaperStlResolution(PolarResolution2d)
|
||||
href: api/Hi.Milling.Cutters.MillingCutter.html#Hi_Milling_Cutters_MillingCutter_SetShaperStlResolution_Hi_Geom_Resolution_PolarResolution2d_
|
||||
@@ -149083,6 +149096,34 @@ references:
|
||||
isSpec: "True"
|
||||
fullName: Hi.NcParsers.RadiusCompInterference.TryDescribeLinear
|
||||
nameWithType: RadiusCompInterference.TryDescribeLinear
|
||||
- uid: Hi.NcParsers.RadiusCompPlaneChange
|
||||
name: RadiusCompPlaneChange
|
||||
href: api/Hi.NcParsers.RadiusCompPlaneChange.html
|
||||
commentId: T:Hi.NcParsers.RadiusCompPlaneChange
|
||||
fullName: Hi.NcParsers.RadiusCompPlaneChange
|
||||
nameWithType: RadiusCompPlaneChange
|
||||
- uid: Hi.NcParsers.RadiusCompPlaneChange.DiagnosticId
|
||||
name: DiagnosticId
|
||||
href: api/Hi.NcParsers.RadiusCompPlaneChange.html#Hi_NcParsers_RadiusCompPlaneChange_DiagnosticId
|
||||
commentId: F:Hi.NcParsers.RadiusCompPlaneChange.DiagnosticId
|
||||
fullName: Hi.NcParsers.RadiusCompPlaneChange.DiagnosticId
|
||||
nameWithType: RadiusCompPlaneChange.DiagnosticId
|
||||
- uid: Hi.NcParsers.RadiusCompPlaneChange.TryDescribe(System.String,System.String,System.String,System.String@,System.Collections.Generic.Dictionary{System.String,System.Object}@)
|
||||
name: TryDescribe(string, string, string, out string, out Dictionary<string, object>)
|
||||
href: api/Hi.NcParsers.RadiusCompPlaneChange.html#Hi_NcParsers_RadiusCompPlaneChange_TryDescribe_System_String_System_String_System_String_System_String__System_Collections_Generic_Dictionary_System_String_System_Object___
|
||||
commentId: M:Hi.NcParsers.RadiusCompPlaneChange.TryDescribe(System.String,System.String,System.String,System.String@,System.Collections.Generic.Dictionary{System.String,System.Object}@)
|
||||
name.vb: TryDescribe(String, String, String, String, Dictionary(Of String, Object))
|
||||
fullName: Hi.NcParsers.RadiusCompPlaneChange.TryDescribe(string, string, string, out string, out System.Collections.Generic.Dictionary<string, object>)
|
||||
fullName.vb: Hi.NcParsers.RadiusCompPlaneChange.TryDescribe(String, String, String, String, System.Collections.Generic.Dictionary(Of String, Object))
|
||||
nameWithType: RadiusCompPlaneChange.TryDescribe(string, string, string, out string, out Dictionary<string, object>)
|
||||
nameWithType.vb: RadiusCompPlaneChange.TryDescribe(String, String, String, String, Dictionary(Of String, Object))
|
||||
- uid: Hi.NcParsers.RadiusCompPlaneChange.TryDescribe*
|
||||
name: TryDescribe
|
||||
href: api/Hi.NcParsers.RadiusCompPlaneChange.html#Hi_NcParsers_RadiusCompPlaneChange_TryDescribe_
|
||||
commentId: Overload:Hi.NcParsers.RadiusCompPlaneChange.TryDescribe
|
||||
isSpec: "True"
|
||||
fullName: Hi.NcParsers.RadiusCompPlaneChange.TryDescribe
|
||||
nameWithType: RadiusCompPlaneChange.TryDescribe
|
||||
- uid: Hi.NcParsers.Segmenters
|
||||
name: Hi.NcParsers.Segmenters
|
||||
href: api/Hi.NcParsers.Segmenters.html
|
||||
|
||||
Reference in New Issue
Block a user