deploy.
This commit is contained in:
@@ -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"}]}
|
||||
|
||||
Reference in New Issue
Block a user