A Mission That Resumes

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.

This page is the layout that gets you all three. Treat it as the shape a project starts from, not as an optimisation to add later — 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 Building a Mission is the mechanics.

The shape

#	Command	Category	Why it is there
1	Physics	Setup	the run's switches, above everything they govern
2	Machining Resolution	Setup	must precede the first record — see below
3	Collision Detection	Setup
4	Script	Program	only what no command covers
5	Record Meshed Geometry	Output	`Cache/<stage>-init.wct` — 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 (which, and why)
6	Program File	Program	the stage
7	Record Meshed Geometry	Output	`Cache/<stage>-done.wct` — the result of the stage; the next stage's stock
8	Post-Execution	Output	what the run writes out

Every entry keeps its own checkbox, so any of them can be switched off without being deleted and without its settings being lost.

Why commands rather than one script

A script sets the same values, and that is the whole of its advantage. Against it:

A row states its value. Machining Resolution [0.125 mm], Physics [On], Program File [NC/facing.ptp] — the mission is legible without opening anything.
A checkbox replaces commenting-out. 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.
The fields are typed. A resolution is a number field with a unit, not a line that has to compile.
The order is the run. Moving a setting above or below a program is a drag, not an edit.

Leave in the Script only what no command covers, and title it for what it is.

Resolution before the first record

Machining Resolution has to sit above the first Record Meshed Geometry entry. 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.

The same holds for anything else that changes what the geometry is: the Setup commands go first.

What Read On First Or Write does

Record Meshed Geometry has four actions, and the fourth is the one that makes a mission resumable:

Action	What it does
No Action	nothing; the entry is a placeholder
Read	always loads the file into the session
Write	always writes the session's geometry to the file
Read On First Or Write	reads the file if it exists and no machining step has been produced yet this run; otherwise writes

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.

So in the layout above:

First run. Neither file exists. Entry 5 writes the meshed stock; the program plays; entry 7 writes the result.
Every run after. Entry 5 finds its file and nothing has played, so it reads — the stock is not re-meshed. The program plays, so by entry 7 something has played, and it writes the fresh result.
Re-running one stage. 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.

Clearing a stage clears everything in it, including its record. 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 previous 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 the record you are resuming from has to be reachable: every checkbox above it stays ticked.

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.

The stage-0 cache goes stale, silently

This is the price of the layout, and it is worth stating on its own.

The record above the program caches the stock, meshed. From the second run onward that cache is what the run starts from — so changing the workpiece geometry, its initial resolution, or the Machining Resolution has no effect until the cache is cleared. 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.

Give a stage a stage-0 record when the stock costs real time to mesh, and not otherwise. The test is what the workpiece's initial geometry actually is:

Stock geometry	Stage-0 record	Why
An STL of any size that is not trivial — a CAD export, a scanned blank, anything with more than a few thousand triangles	Yes	meshing it is a fixed, single-threaded cost paid on every play, and it does not shrink with a shorter program
A box, a cylindroid, or another procedural solid	No	the kernel builds it in moments; the record would cost more than it saves
A mesh recorded by an earlier stage	No — see below	it is already a cache

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 168 s of every play, unchanged when the program was swapped for a 4.8 KB one — 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.

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.

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.

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.

Resuming, then cutting finer

A record freezes the workpiece as meshed at the width in force when it ran. 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.

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.

So record each stage at the width that stage needs — with one exception: the stage the finishing pass reads from. 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.

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.

This is a different thing from the stage-0 trap above, which is about the record above a program caching the stock: there the frozen mesh is what the run starts from, so the resolution really is stuck until the file is cleared.

One record per stage

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 reads is the one named for the stage before it.

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.

What stays in a Script

Two things belong there and little else:

Process-wide settings with no command of their own. MillingCycleDivisionNum 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.
Genuinely one-off session work — see the Script section of The Other Commands.

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.

The cache is a by-product

Cache/ 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 Reset clears the file it points at.

Table of Contents