Building a Mission

A mission is the list of commands a run executes, in order. Nothing plays until there is one, and what plays is exactly what the list says — including which entries are ticked and which are not.

Where it is

The Execution page at /execution, Mission branch of the Control Tree; /mission lands on the same place. This is the page the application opens on.

The branch root is the list editor: it is where the list is assembled and rearranged. A command's own settings are edited one level in, on that command's node.

Add a command

Add Command opens a search-first picker. Type to narrow it: the search matches a command's display name, its internal kind key and the aliases it declares, and an alias matches both by its English key and by its word in the interface language. Arrow keys walk the results and Enter takes the highlighted one.

Results are grouped by category. Thirteen kinds ship:

Category	Commands
Setup	Machining Resolution, Machining Motion Resolution, Collision Detection, Pause on Failure, Physics
Program	Program File, NC Code, Script
Optimization	NC Optimization Config
Output	Post-Execution, Record Meshed Geometry, Export Meshed Geometry (STL)
Flow	List

What you pick is appended to the end of the list you added it to, and the selection stays on the list rather than jumping into the new command. Nothing is pinned to a position: the order is entirely yours, and every command is placeable anywhere.

Add Command is disabled until a project is open. With nothing open the list reads No project loaded; with a project and an empty mission it reads No commands yet and names the button.

The set on offer is served by the application rather than built into the interface, so a command kind can appear in this dialog before this manual has a page for it.

The picker over the demo mission, at /execution?tree=execution/mission with Add Command pressed. The five category headings are the grouping in the table above, the search box at the top is what narrows them, and the first result is highlighted ready for Enter.

The shape to start from

An empty list is legal, but it is not where a project should end up. A finished mission has the same shape whatever it machines: setup at the top, the program in the middle, the program held between two Record Meshed Geometry entries, output at the bottom.


Setup	Machining Resolution, Machining Motion Resolution, Collision Detection, Pause on Failure, Physics
Output	Record Meshed Geometry — `Cache/<stage>-init.wct`, the stock
Program	Program File
Output	Record Meshed Geometry — `Cache/<stage>-done.wct`, the result
Output	Post-Execution

The two records are what make a run restartable, and they are part of the shape rather than an advanced extra — a mission without them replays the whole job from the stock every time. Two rules travel with them:

Machining Resolution belongs above the first record. The cache is meshed at whatever resolution is in force when the record runs, so a resolution set below it is silently baked out of the file.
Keep the first record where the stock is an STL, drop it where the stock is procedural (a box or a cylindroid) or is already a recorded mesh. Meshing an STL is a fixed cost paid on every play; a box the kernel builds instantly, and caching it costs more than it saves.

A Mission That Resumes is this layout in full, with the reasoning and the measurements behind each row.

Read a row

Each row shows the command's kind followed by the detail that identifies it, in brackets. Where you can name a command that detail is the title you typed, so a row still says what it is after it has been named: List [Roughing], NC Code [Inline finishing pass]. Where you cannot, the command brackets what it holds instead — Program File [NC/circle.ptp], Machining Resolution [1 mm], Collision Detection [On] — so a mission is readable without opening anything.

Beside the label sit four buttons — up, down, duplicate and delete. Up and down are disabled at the ends of the list. Delete asks first, in a dialog naming the command. Duplicate is a deep copy: a group copies with everything inside it, and the copy lands directly after the original.

Clicking a row anywhere but on a button selects that command's node and opens its editor.

Tick what runs

The checkbox is on the tree item, not in the row, and it is the only thing that decides whether a command runs. Clearing it greys the row and the tree node; the editor stays open and fully editable. Clearing the box on a group greys the whole group, and the run skips the group together with everything nested inside it.

Leaving a command in place with its box cleared is how you skip a step without losing its settings, which is what you want while you narrow down a problem.

Group with a list

List is an ordinary command in the Flow category, and adding one grows a sub-tree: its children are its own entries, edited by the same list editor one level down. That nests to any depth, so a mission can be grouped by operation rather than left flat.

A list carries an optional title, entered on its own node above the embedded editor. The row reads List while the title is empty and List [title] once it says something; a title of nothing but spaces counts as unset. The Mission root is the one list with no title field — it reads Mission.

The demo mission at /execution?tree=execution/mission: two groups and seven loose entries. The tree above shows List [Roughing] and List [Finishing] opened, with the two Program File entries inside each bracketing their files; the editor below shows the same nine root entries as rows. The greyed Program File and Post-Execution rows are entries left in place with their checkboxes cleared — part of the mission, and not run.

Reorder, and move in and out

Up and down move an entry within its own list and never change which list owns it. Dragging does more, and where you drop decides which:

Drop it on	What happens
Another row	Reorder within this list. A row splits at its midline into before and after.
The middle band of a List row	Move the entry into that list. The row's outer quarters still reorder around it.
The drop-out zone below a nested list's entries	Move the entry out, landing directly after the list it came from.

The drop-out zone belongs to a nested list's editor and appears only while a row inside it is being dragged. Moving a list into itself, or into one of its own groups, is refused.

Dragging serves rearrangement only — dropping text or files on the list does nothing. To bring several programs in at once, use one Program File command's picker and select them together; see Playing a Program.

Edit one command

Select a command's node. Its editor opens below a control bar carrying the same up, down, duplicate and delete operations the row has, and a note while the command is switched off.

A command with one job — Program File, NC Code, Script — puts its whole editor on that one node. A command with several cards spreads them: the general settings stay on the command node and each remaining card becomes a child node beneath it, so a long command is read by walking down the tree rather than by scrolling one panel. Where a card had its own Enable switch, that switch is the child node's own checkbox. Which commands do that, and what each card holds, is The Other Commands.

Table of Contents