|
|
|
@@ -217,6 +217,14 @@ result.</li>
|
|
|
|
|
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>
|
|
|
|
@@ -232,6 +240,26 @@ second operation in a chained pair, a stage-0 record buys no time at all and fre
|
|
|
|
|
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
|
|
|
|
|
