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. It is a recommendation, not a rule: every command is placeable 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; drop this row where the stock is already a recorded mesh
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.

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 only when the stock costs real time to mesh — 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.

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