HiNC-2025-win-desktop-Deploy/App/wwwroot/HiAPI-docsite/manual/run/a-mission-that-resumes.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 &quot;{query}&quot;">
      <meta name="loc:searchNoResults" content="No results for &quot;{query}&quot;">
      <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. <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>
<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/&lt;stage&gt;-init.wct</code> — the stock, meshed once. Keep this row whenever the stock is an STL; drop it where the stock is procedural, or is already a recorded mesh (<a href="#the-stage-0-cache-goes-stale-silently">which, and why</a>)</td>
</tr>
<tr>
<td>6</td>
<td><strong>Program File</strong></td>
<td>Program</td>
<td>the stage's program — one control file, whole</td>
</tr>
<tr>
<td>7</td>
<td><strong>Record Meshed Geometry</strong></td>
<td>Output</td>
<td><code>Cache/&lt;stage&gt;-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>
<p><strong>A stage is rows 5–7 wrapped in a List command.</strong> List is the one command in the Flow category
of Add Command; give it the stage's name and its row reads <code>List [Roughing]</code>, with the record,
the Program File and the closing record as its rows one level down. The Setup rows stay loose
above the first stage and Post-Execution loose below the last. The List row carries a checkbox of
its own, and clearing it greys every row inside and skips the whole group — that checkbox is
what the re-running section below turns on and off.
<a href="building-a-mission.html#group-with-a-list">Group with a list</a> is how the group is made, titled
and moved.</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 the command's
editor below the tree 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 of its row in the
Control Tree's <strong>Mission</strong> branch, 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 <strong>List</strong> row of each stage 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 List row with its
entries beneath it; clear that row's checkbox and every entry inside greys with it and the group 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 when the stock costs real time to mesh, and not otherwise.</strong> The
test is what the workpiece's initial geometry actually is:</p>
<table>
<thead>
<tr>
<th>Stock geometry</th>
<th>Stage-0 record</th>
<th>Why</th>
</tr>
</thead>
<tbody>
<tr>
<td><strong>An STL of any size that is not trivial</strong> — a CAD export, a scanned blank, anything with more than a few thousand triangles</td>
<td><strong>Yes</strong></td>
<td>meshing it is a fixed, single-threaded cost paid on every play, and it does not shrink with a shorter program</td>
</tr>
<tr>
<td>A box, a cylindroid, or another procedural solid</td>
<td>No</td>
<td>the kernel builds it in moments; the record would cost more than it saves</td>
</tr>
<tr>
<td>A mesh recorded by an earlier stage</td>
<td><strong>No</strong> — see below</td>
<td>it is already a cache</td>
</tr>
</tbody>
</table>
<p>The first row is the case worth spelling out, because the cost does not look like it belongs to the
geometry. A stock STL is meshed into the cube tree when the first program plays, so the time lands
inside the run and reads as if the NC were slow. It is not: it is a constant. One measured example
is a 8.9 MB stock STL whose mesh build was <strong>168 s of every play, unchanged when the program was
swapped for a 4.8 KB one</strong> — on a 193 s run, 168 s of it was the stock. Recording that mesh once
turns the second and every later play into a file read of a few hundredths of a second.</p>
<p>The cost climbs steeply with triangle count, so the finer the tessellation the more a stage-0 record
is worth: a 1.17-million-triangle stock at 0.125 mm had still not finished meshing after 268 s.</p>
<p>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>
<p>One thing the record does not do is make a stock that the kernel cannot mesh meshable. The record
writes what the build produced; if the build itself fails, there is nothing to write, and the
mission fails in the same place on every run.</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 stages — one List per stage, each with its Program File — 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>