Archived
323 lines
16 KiB
HTML
323 lines
16 KiB
HTML
<!DOCTYPE html>
|
|
<html>
|
|
<head>
|
|
<meta charset="utf-8">
|
|
<title>A Mission That Resumes | HiAPI-C# 2025 </title>
|
|
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
|
<meta name="title" content="A Mission That Resumes | 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="a-mission-that-resumes">A Mission That Resumes</h1>
|
|
|
|
<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>
|
|
<h2 id="the-shape">The shape</h2>
|
|
<table>
|
|
<thead>
|
|
<tr>
|
|
<th>#</th>
|
|
<th>Command</th>
|
|
<th>Category</th>
|
|
<th>Why it is there</th>
|
|
</tr>
|
|
</thead>
|
|
<tbody>
|
|
<tr>
|
|
<td>1</td>
|
|
<td><strong>Physics</strong></td>
|
|
<td>Setup</td>
|
|
<td>the run's switches, above everything they govern</td>
|
|
</tr>
|
|
<tr>
|
|
<td>2</td>
|
|
<td><strong>Machining Resolution</strong></td>
|
|
<td>Setup</td>
|
|
<td>must precede the first record — see below</td>
|
|
</tr>
|
|
<tr>
|
|
<td>3</td>
|
|
<td><strong>Collision Detection</strong></td>
|
|
<td>Setup</td>
|
|
<td></td>
|
|
</tr>
|
|
<tr>
|
|
<td>4</td>
|
|
<td><strong>Script</strong></td>
|
|
<td>Program</td>
|
|
<td>only what no command covers</td>
|
|
</tr>
|
|
<tr>
|
|
<td>5</td>
|
|
<td><strong>Record Meshed Geometry</strong></td>
|
|
<td>Output</td>
|
|
<td><code>Cache/<stage>-init.wct</code> — the stock, meshed once; drop this row where the stock is already a recorded mesh</td>
|
|
</tr>
|
|
<tr>
|
|
<td>6</td>
|
|
<td><strong>Program File</strong></td>
|
|
<td>Program</td>
|
|
<td>the stage</td>
|
|
</tr>
|
|
<tr>
|
|
<td>7</td>
|
|
<td><strong>Record Meshed Geometry</strong></td>
|
|
<td>Output</td>
|
|
<td><code>Cache/<stage>-done.wct</code> — the result of the stage; the next stage's stock</td>
|
|
</tr>
|
|
<tr>
|
|
<td>8</td>
|
|
<td><strong>Post-Execution</strong></td>
|
|
<td>Output</td>
|
|
<td>what the run writes out</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
<p>Every entry keeps its own checkbox, so any of them can be switched off without being deleted and
|
|
without its settings being lost.</p>
|
|
<h2 id="why-commands-rather-than-one-script">Why commands rather than one script</h2>
|
|
<p>A script sets the same values, and that is the whole of its advantage. Against it:</p>
|
|
<ul>
|
|
<li><strong>A row states its value.</strong> <code>Machining Resolution [0.125 mm]</code>, <code>Physics [On]</code>,
|
|
<code>Program File [NC/facing.ptp]</code> — the mission is legible without opening anything.</li>
|
|
<li><strong>A checkbox replaces commenting-out.</strong> A commented line is invisible in the tree and survives
|
|
into the saved project as text nobody reads. A cleared checkbox greys the row and says so.</li>
|
|
<li><strong>The fields are typed.</strong> A resolution is a number field with a unit, not a line that has to
|
|
compile.</li>
|
|
<li><strong>The order is the run.</strong> Moving a setting above or below a program is a drag, not an edit.</li>
|
|
</ul>
|
|
<p>Leave in the Script only what no command covers, and title it for what it is.</p>
|
|
<h2 id="resolution-before-the-first-record">Resolution before the first record</h2>
|
|
<p><strong>Machining Resolution has to sit above the first Record Meshed Geometry entry.</strong> The record writes
|
|
the workpiece as a meshed geometry, and the mesh is built at whatever resolution is in force when it
|
|
runs. Put the resolution command below it and the cached mesh is built at the previous value —
|
|
which the next run then reads back, silently, as if it were the one you asked for.</p>
|
|
<p>The same holds for anything else that changes what the geometry is: the Setup commands go first.</p>
|
|
<h2 id="what-read-on-first-or-write-does">What Read On First Or Write does</h2>
|
|
<p>Record Meshed Geometry has four actions, and the fourth is the one that makes a mission resumable:</p>
|
|
<table>
|
|
<thead>
|
|
<tr>
|
|
<th>Action</th>
|
|
<th>What it does</th>
|
|
</tr>
|
|
</thead>
|
|
<tbody>
|
|
<tr>
|
|
<td><strong>No Action</strong></td>
|
|
<td>nothing; the entry is a placeholder</td>
|
|
</tr>
|
|
<tr>
|
|
<td><strong>Read</strong></td>
|
|
<td>always loads the file into the session</td>
|
|
</tr>
|
|
<tr>
|
|
<td><strong>Write</strong></td>
|
|
<td>always writes the session's geometry to the file</td>
|
|
</tr>
|
|
<tr>
|
|
<td><strong>Read On First Or Write</strong></td>
|
|
<td>reads the file if it exists <strong>and no machining step has been produced yet this run</strong>; otherwise writes</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
<p>The condition is a property of the run, not of the entry — there is no per-entry counter. It is
|
|
also about steps, not about cutting: a pass that only positions the tool still produces steps, so a
|
|
program that removed no material still counts as having played, and the next record writes rather
|
|
than reads. Only a program that produced no steps at all — no tool selected, no motion, or a file
|
|
that was not found — leaves the run in its opening state.</p>
|
|
<p>So in the layout above:</p>
|
|
<ul>
|
|
<li><strong>First run.</strong> Neither file exists. Entry 5 writes the meshed stock; the program plays; entry 7
|
|
writes the result.</li>
|
|
<li><strong>Every run after.</strong> Entry 5 finds its file and nothing has played, so it <strong>reads</strong> — the stock is
|
|
not re-meshed. The program plays, so by entry 7 something has played, and it <strong>writes</strong> the fresh
|
|
result.</li>
|
|
<li><strong>Re-running one stage.</strong> Clear the checkbox on the stages you do not want. The first record entry
|
|
that is still ticked becomes the first thing to run, so it reads its cache, and the run picks up
|
|
from there.</li>
|
|
</ul>
|
|
<p><strong>Clearing a stage clears everything in it, including its record.</strong> A stage is a checkbox around a
|
|
list, and a cleared one is skipped whole — so in a chain where the cache a stage resumes from is the
|
|
<em>previous</em> stage's end-of-stage record, clearing that previous stage removes the very entry that
|
|
would have loaded it. The run then starts from the stock, quietly and without an error. Either leave
|
|
the earlier stages ticked and clear only the Program File rows inside them, or clear them but keep
|
|
the one stage whose end-of-stage record you are resuming from, with its own programs cleared. The
|
|
rule is simply that <strong>the record you are resuming from has to be reachable</strong>: every checkbox above
|
|
it stays ticked.</p>
|
|
<p>That last line is the point of the layout. The cost of getting back to the middle of a long job is
|
|
one file read.</p>
|
|
<h2 id="the-stage-0-cache-goes-stale-silently">The stage-0 cache goes stale, silently</h2>
|
|
<p>This is the price of the layout, and it is worth stating on its own.</p>
|
|
<p>The record above the program caches the <strong>stock</strong>, meshed. From the second run onward that cache is
|
|
what the run starts from — so <strong>changing the workpiece geometry, its initial resolution, or the
|
|
Machining Resolution has no effect until the cache is cleared.</strong> Nothing warns you: the run simply
|
|
reproduces the previous one. After changing any of those three, Reset the stage-0 record (or delete
|
|
its file) before reading anything into the result.</p>
|
|
<p><strong>Give a stage a stage-0 record only when the stock costs real time to mesh</strong> — a large mesh or a
|
|
solid the kernel has to build. Where a stage's stock is itself a recorded mesh, as it is for the
|
|
second operation in a chained pair, a stage-0 record buys no time at all and freezes the chain: the
|
|
upstream stage can be re-run all it likes and this one keeps reading the copy it took the first
|
|
time. There, the previous stage's own end-of-stage file is already the cache, and the stage needs
|
|
no record above its program.</p>
|
|
<h2 id="resuming-then-cutting-finer">Resuming, then cutting finer</h2>
|
|
<p>A record freezes the workpiece <strong>as meshed at the width in force when it ran</strong>. Reading one back
|
|
does not pin the rest of the run to that width: put a finer Machining Resolution below the record
|
|
and above the next program, and that program's removal is built at the finer width. Measured on a
|
|
roughing stage recorded at 0.5 mm — read back, then cut at 0.0625 mm — the cut ran at 0.0625 mm and
|
|
took 779 s where the same program at 0.5 mm took 27 s, for five times the mesh's own memory. The
|
|
request binds; the record is not a ceiling, and at this end of the ladder it is not free either.</p>
|
|
<p>What reading back cannot do is add detail that was never stored. Surfaces inherited from the record
|
|
keep the width they were recorded at; only what the later program cuts is meshed finer. That is
|
|
normally exactly right — the roughed surface is about to be cut away, and the finish surface is the
|
|
one the fine mesh is for.</p>
|
|
<p>So <strong>record each stage at the width that stage needs — with one exception: the stage the finishing
|
|
pass reads from.</strong> Everything the finishing tool does not touch keeps that record's width, and that
|
|
includes the surface the finish is measured against. Choose that one record's width against the
|
|
finish, then, rather than against the roughing stage it happens to belong to.</p>
|
|
<p>The earlier stages have no such constraint. Roughing at the finishing width to be safe buys nothing
|
|
and costs the whole roughing run at the finishing price.</p>
|
|
<p>This is a different thing from the stage-0 trap above, which is about the record above a program
|
|
caching the <em>stock</em>: there the frozen mesh is what the run starts from, so the resolution really is
|
|
stuck until the file is cleared.</p>
|
|
<h2 id="one-record-per-stage">One record per stage</h2>
|
|
<p>A mission with several Program File entries gets a record after each, plus the stage-0 record where
|
|
that one earns its place. Name each file after the stage it ends, not after the program that wrote
|
|
it, so the file that a stage <em>reads</em> is the one named for the stage before it.</p>
|
|
<p>Do not split one control file into several Program File entries to get finer stages. A program's
|
|
modal state — units, plane, work offset, absolute or incremental — is established in its header and
|
|
carried forward; cutting it in half hands the second half to a runner that never saw the header. The
|
|
stage boundary is a file boundary.</p>
|
|
<h2 id="what-stays-in-a-script">What stays in a Script</h2>
|
|
<p>Two things belong there and little else:</p>
|
|
<ol>
|
|
<li><strong>Process-wide settings with no command of their own.</strong> <code>MillingCycleDivisionNum</code> is the standing
|
|
example: it is process-wide, it survives a runtime reset and a project switch, and a training
|
|
script that raised it leaks into every project loaded afterwards. Pinning it in the mission is a
|
|
guard, not a setting.</li>
|
|
<li><strong>Genuinely one-off session work</strong> — see the Script section of
|
|
<a href="the-other-commands.html">The Other Commands</a>.</li>
|
|
</ol>
|
|
<p>Anything with a command belongs in the command. A script line that duplicates a command's default is
|
|
worse than nothing: it reads as a decision when it is a leftover.</p>
|
|
<h2 id="the-cache-is-a-by-product">The cache is a by-product</h2>
|
|
<p><code>Cache/</code> holds rebuildable artifacts, which is why the record command defaults there. A meshed
|
|
workpiece is large — hundreds of megabytes at a fine resolution is ordinary — and it is derived
|
|
entirely from the stock geometry, the resolution and the programs above it. Keep it out of version
|
|
control, and delete it whenever you want the run rebuilt from the stock: the record command's own
|
|
<strong>Reset</strong> clears the file it points at.</p>
|
|
<h2 id="see-also">See Also</h2>
|
|
<ul>
|
|
<li><a href="building-a-mission.html">Building a Mission</a> — adding, ordering, ticking and grouping the entries</li>
|
|
<li><a href="the-other-commands.html">The Other Commands</a> — what each command kind holds</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="running-a-simulation.html">Starting and Stepping</a> — the transport that plays the list</li>
|
|
<li><a href="../basics/projects.html">Projects</a> — what a project folder holds</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>
|