2. The window

Figure 1. Default demo, part.nc (the figure predates the DryRun shell: the regions are the same, the look is not; figure 1a shows the G-code tab and the strip as they are). Stock status at the top left of the viewport; the toolbar and the nav cube at the top right; the DRO, the timeline and the transport in the strip under the viewport; the G-code tab on the right with the program, the code and Problems.

Header (top)

Library

The Library (header, the Projects window's Library of machines and fixtures, or the account menu's Library) holds the machines and the fixtures your setups are built from. It opens over the workspace, the full height of the window, and has the main window's layout: on the left the tabs Machines and Fixtures, a search field, + New machine / + New fixture, Import… and the list; in the middle a viewport with the selected item (a machine at its home pose — all axes at 0 on DDCS, at controller.home on GRBL —, a fixture alone on the ground; drag to orbit, scroll to zoom); on the right its fields. × or Esc closes it; the project behind is not touched by anything you do in the Library (a setup takes a copy when you choose an item, see below). The arrow keys move through the list (Home, End), ← → switch the tabs.

The lists. First the Catalogue — what comes with DryRun: the machines of the machines/ folder (section 4.2; the first is the default machine) and the Machine vise (the adjustable vise, jaws 100 × 30 mm along X, opening to 150 mm). Catalogue cards are read-only; their ⋯ menu has Copy to my machines (Copy to my fixtures), which is also the button under their fields. Then Your machines / Your fixtures, newest first, kept in this browser (online: in your account, section 4.5.9). Each card shows the name, a meta line and the date: machines 4 axes · X 600 · Y 600 · Z 300 mm · A rotary · DDCS V4.1 (axes, travel, controller), fixtures Box · 120 × 60 × 20 mm, Vise · jaws 120 × 30 mm along X, opens 150 mm or STL mesh · 440 × 60 × 10 mm; then DryRun catalogue or added Oct 12. The ⋯ menu of your own items has Rename (in place: Enter keeps the new name, Esc the old one), Duplicate (<name> copy) and Delete (it asks: Delete "<name>"? — The machine is removed from this browser. Projects that use it keep their own copy.).

Machines. Import… asks for a machine folder (machine.json at its top and its meshes; section 4.2): if it is a machine and every mesh reads, its machine.json and the meshes its links name are kept (nothing else of the folder) and selected; otherwise the reason is shown, for example machine.json: units must be "mm", and nothing is kept. + New machine starts from a copy of the default machine named New machine. The fields of your own machine: Name, the travel of each linear axis (X travel 0 to 600 mm — its joint limits; 0 must stay inside), the Controller (DDCS V4.1, GRBL 1.1, grblHAL) with Rapid feed, and for DDCS Ignore the program's F, use the default feed (#101) and Default feed, for GRBL Soft limits ($20); Spoilboard (mm) for a machine whose table link has one. The meshes and the kinematics stay as imported. Save writes them into the machine's machine.json; a value the loader refuses says why under the fields, for example link "x_carriage": limits must include 0 (the start pose), and nothing is saved. Changing the controller drops the other controller's switches (the file stays loadable).

Fixtures. + New fixture makes a box, New fixture, 100 × 100 × 20. A fixture of yours is a Box or a Vise (the Kind switch):

• Box — Size x, y, z (mm) and Mount offset x, y, z: a block standing where a fixture stands by default (centred under the tool at mid-travel, on the table), moved by the offset. In a setup it is a mesh the tool is checked against, like any fixture.
• Vise — Jaw width, Jaw height, Max opening (mm) and Jaws along X / Y: the adjustable vise of section 4.5.4, its jaws turned 90° about Z for Y. In a setup its jaws open to the stock.

Import… on the Fixtures tab takes an STL file as a fixture (STL mesh, named after the file); only its name can be changed. The viewport follows the fields as you type; Save keeps them.

Using the Library in a project. The Machine item of a setup lists the Library's machines (section 4.5.1) and the Fixture item its fixtures (section 4.5.4). Choosing one copies it into the project — the machine into machine/, a vise's parameters into project.json, a box as an STL file next to it, an STL's file — so a saved project never depends on the Library. A later change in the Library reaches a project only when you choose the item there again.

The panel's tabs (right)

The panel on the right (400 px; 340 px below 1280 px window width) has two tabs, and the tab is the mode:

• Project (setup): the project's settings as an accordion — the Stock card (its size: From program extents or a measured block), the Setup 1 card with the items Machine, Fixture, Placement (which face of the stock rests on the support, its turn about Z, its offset in the jaws, the height above them; section 4.5.5a), Tools, one Program item per program (the work zero is set there; the main program says · main) and + Add program (the program list: add files, choose the main program, include or leave out programs), and the Check card (the project's summary: what to fix, what is assumed, the zero for the controller). One card is open at a time; a click on an item opens it in place with Apply (applies the pending edit and closes it) and Cancel (puts the project back as it was when the item opened). Edits apply as you type (after a short pause, at once on Enter or a choice), so the viewport follows while the item is open. Under the cards: the run line and Export…. A new project is made in the same cards (section 4.5.8); with nothing open they are empty and Setup 1 says Start by choosing a machine — opening any item starts a new project there.
• G-code (simulation): the program row, the code and the Problems block (section 2, Simulation). Opening or loading a project shows this tab.

Click a tab, or focus one and use ← →.

Viewport (left)

What is drawn:

• The machine links from their STL meshes, in greys: the root link (base, table) light grey, the first link on a linear joint (a moving gantry) mid-grey, the links further down that chain (X carriage, Z head) and every other link (rotary chuck, tailstock) dark grey. Tool-side collision shapes are not drawn; only meshes are.
• The fixture, dark grey.
• The tool, drawn from exactly the shapes the collision check uses (without the 0.25 mm inflation of section 7.4): holder dark, shank mid-grey, cutter light grey.
• The stock. Until the first part of the machined stock arrives from the background computation, and whenever it is not simulated, the blank is drawn translucent tan with a darker outline. After that the machined stock is drawn opaque at the playback time: faces of the blank in tan, faces created by cutting in bright metal grey (a mesh stock is tan everywhere). Playing shows the material disappearing behind the tool; seeking back, stepping or clicking a warning shows the stock as it was then. The shown cut is updated every 2 mm of tool path, so it can lag the tool by up to 2 mm.
• The toolpath: the path of the tool tip, light blue for rapids and ink (near black) for feed moves and arcs. The part already run, up to the last finished segment, is drawn in full colour; the rest is faded (light grey for feeds, pale blue for rapids), so at time 0 the whole path is faded. It is attached to the link that carries the stock (or the fixture, or the first work mount), so on the rotary axis it turns with A.
• If the project cannot be loaded, the viewport is covered by a red list of every load error.

The verdict (bug080: the tag in the Problems header of the G-code tab, and the same word after the save state in the header, for example Unsaved changes · Do not run, so it stays in view on the Project tab). Always a word, never colour alone; hover the tag for the whole sentence:

A run whose stock is not simulated is never shown as clean (bug031): the tag says Incomplete and its title says why.

Stock status (the G-code tab: a muted line under the Problems header; bug091). Always one of these, or nothing when setup.json has no stock. The first two are progress: they are shown as the viewport's hint at the top left (unless a hint of the Project tab is shown) and the line stays empty until the result.

The viewport's chrome. Top left: a hint when the panel asks something of the viewport (jogging in Work zero: Jogging — the tool shows where the spindle is. Set zero when the tip touches the point.; the Work zero's Click way: Click a snap point on the stock) and, with neither, the run's progress while it computes (Simulating… 37% · stock computed to 0:42.0, then Drawing stock…). Nothing stays there: the stock status itself is the line under the Problems header in the G-code tab. Top right: the toolbar and, to its right, the nav cube. Bottom left: the axis triad (X red, Y green, Z blue), turning with the camera.

The fit and view buttons change only the camera, never what is shown, and act once per click: during playback the camera does not follow the part.

Collision highlight. The two bodies of a collision are tinted red and their red edges are drawn on top of everything, so a part hidden behind others still shows (as an outline; a large body such as the table does not cover the bodies in front of it).

• While playing, seeking or stepping, a pair glows while the playback is inside a segment with a collision entry, past the point where that contact starts, and only while the two bodies still touch at the current pose. Pairs with the stock never glow this way (the touching test has no access to the machined stock); they glow only when their entry is clicked. A tool part completely buried in a body can make the glow drop out and flicker (seen in overtravel.nc), and segments that were merged into an earlier entry of the same line are not highlighted.
• Clicking a collision row in Problems pauses, jumps to its first touching sample and pins the glow to that entry's pair (stock pairs included); Show on that row (and Show first problem →) also frames the contact from the current direction. The glow stays pinned until you play, seek or step.
• The machined stock is tinted without the edges, so the cut stays visible.

Axis-limit envelope. While an axis-limit entry is the one jumped to (clicked, or Show first problem →), the travel box of the tool tip is drawn as red edges: the tip of the current tool at the eight combinations of the X, Y and Z joint limits, with A at 0. It goes away when you play, seek or step. A machine with an axis without limits shows no box.

Mouse and keyboard controls (mouse: three.js OrbitControls defaults):

The keys work anywhere in the window except while a text field, the seek slider or a drop-down list has the focus, and not with Ctrl, Cmd or Alt held (Ctrl+F / Cmd+F stays the browser's find).

Simulation (the G-code tab and the strip under the viewport)

Figure 1a. overtravel.nc of the demo: the program row and the code with its problem lines on the right, Problems with the chips under it; under the viewport the DRO, the timeline of the project's programs and the transport.

The program row (top of the G-code tab):

The code. The program text with line numbers, in a monospace font. G words are tinted violet (G0–G3 and the other G codes), the work offsets G54–G59 amber, T, M and S words blue, comments grey. The executing line has an amber bar on the left and an amber row, and the view scrolls to keep it in sight while playing. Lines with problems have a tinted row and a word on the right: collision and error in red (a collision; an axis-limit violation, a line not executed, the stock model's stop or another error), warning and note in amber. Click a line to pause and jump to the end of its first move (a line without a move does nothing).

Problems (under the code):

• Header: Problems, the number of entries (red when there is an error), the status tag (as in the program list: Checking 37%, Do not run, Incomplete, Not simulated, Clean), the scope and the collapse arrow, which hides the chips and the list and gives the code the room. The tag is the project's worst verdict: when another program run in this session is worse than the one on screen (and its run is not stale), the tag shows that one's word and its tooltip says which, for example Do not run: S1 · overtravel.nc (the project's worst). This program: Clean — No collisions, all moves within limits; the program list keeps each program's own tag. The header's save-state line repeats the word.

• Scope: This program (default) lists the program on screen. Whole project lists the problems of every program run in this session, in every setup, by the project's time (the timeline's): the monospace line starts with the setup and the program (S2 · back.nc · line 40 · 0:03:10). Rows of a run whose inputs changed since (an edit of its setup or of a setup before it) are dimmed and end with ↻ stale; play or select that program to run it again. The count and the chips follow the scope. Clicking a row of another program shows that program (opening its setup first) and jumps to the problem.

• Chips: All · 19, Collisions · 16, Code · 2, Warnings · 1 — a click shows only that kind. Collisions are the collisions found on program lines. Code is what breaks or stops the run: axis-limit violations, lines not executed (an error, or a warning for a skipped line), lines a GRBL controller rejects, the stock model's stop, a skipped collision check. Warnings is everything else, the notes included.

• Collision status, a muted line under the chips while the check runs, or when it was partial, skipped or failed (bug093: a finished result is in the tag, and No collisions found (0.4 s) is the Collisions chip's row when it has none):

  Text	Meaning
  Checking collisions… 37% — 2 collisions so far	The check runs in the background, in program order, together with the material removal. Collisions appear in the list as they are found and can be clicked at once; the program after 37 % is not checked yet, so 0 collisions so far is not a result.
  No collisions found (0.4 s)	The check ran on every link and found nothing. The seconds are the time the whole pass took.
  No collisions found (0.4 s) — 2 machine links not checked	Same, but tool-side links with a mesh and no collision shapes were not checked (a whole-program entry names each).
  3 collisions (0.4 s)	Collisions were found (with — 2 machine links not checked appended when that applies).
  Collision check incomplete: stock model stopped at line <n> (memory limit) — later moves are not checked against the stock	The stock model stopped at line n (section 7.6); nothing was found before or after it. Never shown as Clean.
  <k> collisions — check incomplete after line <n>	Collisions were found, and the stock model stopped at line n.
  Collision check skipped: <reason>	The machine has a joint arrangement the check does not support; nothing was checked (section 7.4).
  Collision check failed: <error>	Internal failure of the check.

• Note under it while the check runs: Checked to 37% of the program. Lines after that aren't checked yet. A chip without rows says so in one row (No problems found, None so far — still checking).

• What is checked, a closed disclosure under the rows once the check found no collision. With a stock: Checked: tool, holder and declared machine shapes against fixture, table-side links and the machined stock; rapids whose cutter enters remaining material deeper than 0.1 mm. / Not checked: table-side bodies against each other. Stock accuracy is limited by the resolution shown in the stock status. Without a stock: Checked: tool, holder and declared machine shapes against fixture and table-side links. / Not checked: table-side bodies against each other. No stock in the setup: nothing is cut and nothing is checked against a stock. It is a reminder, not the full list; section 7 is.

• The rows. An icon (a red burst for a collision, a red </> for Code, an amber triangle for a warning), the title — the kind and the message, for a collision what touches what, for example Collision: holder T1 hits stock (bug085; hover the row for the machine point, Machine X 220.000 Y 270.000 Z -170.000 A 0.000) — and a monospace line S1 · overtravel.nc · line 12 · 0:00:46 with a detail when there is one: how deep a cutter cuts into a spoilboard (1.4 mm deep), else a collision's point in work coordinates as the DRO shows them (X 0 Y 50 Z -20), how far past an axis limit (40 mm over), GRBL's error number (error:20 · job stops), line skipped, stock stopped. Whole-program entries say whole program instead of a line and a time. The time is the project's: where the problem happens on the timeline under the viewport (the programs before this one included). The kinds are Collision, Axis limit, Not executed, Stock, Note (the "not confirmed on DDCS" class — unconfirmed and unsupported codes, macros, an ignored F, a move without F; on a GRBL machine also no tool change in program — GRBL ignores T; …, the normal one-tool-per-file case) and Warning (everything else, including a machine link not checked). Order: collisions, axis-limit violations and lines not executed first, then everything else, each group by line.

• Click a row, or Tab to it and press Enter or Space: playback pauses and jumps to where the problem starts (for a collision, the first sample where the bodies touch), the line is highlighted in the code, and the row is marked (amber, red for an error) until you play, seek or step. The list is one Tab stop (bug088): ↑ ↓ move between the rows, Home and End to the first and the last, → to a row's Show and ← back. The marked row of a collision has Show: the same jump, and the camera frames the contact of the two bodies from the current direction (about 12 times the contact's size across, at least 120 mm). The first row also has Show while the verdict is Do not run or Incomplete (bug080).

• The code view is one Tab stop too: ↑ ↓, Page Up / Down, Home and End move a line cursor, Enter seeks to that line as a click does. While playing, the current line stays about a third from the top, so the next lines are visible. A warning inside a subprogram appears once per pass (known).

Figure 2. overtravel.nc after clicking the row Collision: holder T1 hits stock (machine point X 220 Y 270 Z −170) and Show: holder and stock glow red, line 12 is highlighted, the row is marked and has Show.

The DRO (the strip under the viewport, top): X · G54, Y · G54, Z · G54 — the position in the work offset of the current move (the machine value minus the work offset, G54–G59 plus G92, and on Z minus the active tool length offset; the label changes to G55 while a G55 move runs; at time 0 the first move's offsets, a known limitation); an A · G54 cell only when the machine has an A joint; Feed, mm/min of the current move (3 000 G0 for a rapid at the rapid rate, – for a dwell or before the first move); Spindle — the S speed while M3 or M4 runs, Off otherwise; Tool — T2 · Ø8 (the number and the diameter from the tool table), – for none. Under each axis value, small and muted, its machine coordinate (MCS 640.000, bug086): compare it with axis-limit messages and the controller's soft limits.

The timeline (under the DRO): one bar through the whole project — every program of every setup in order — the first program of each setup labelled with the setup (S1 · part, dialect, …, S2 · back), the others by name (without the extension). A program is as wide as its run time once it has been run in this session (also when a later setup's recompute ran it); a program not run yet is hatched and as wide as an estimate (its line count × the average seconds per line of the programs run so far). A program whose run is stale — its setup or a setup before it changed since — is hatched with ↻ after its name (hover: ↻ stale: its inputs changed, recomputed when played). No part is a sliver (bug082): the current program takes at least 27 % of the bar, every other at least 6 % (less with very many programs). The current program is the part with the playhead: amber up to the current time, red ticks at its problems (the Collisions and Code rows; a darker tick for a line not executed; hover a tick for Collision · S1 · overtravel · 0:01:46 — the project's time —, click it to jump there as the row does; Tab from the bar reaches the ticks in time order, Enter jumps; ticks within 0.1 % of the program's time and of the same kind are one). The other programs run in this session keep their ticks too; a click on one jumps there. Click or drag on the current part to seek, or focus it with Tab and use the arrow keys (the other programs' parts are mouse shortcuts and not Tab stops, bug094). While the background computation runs, the current part is mid grey up to the time the stock is computed to and dark after it. Programs before the current one that ran in this session are amber, those after it grey. Click another program's part to seek there: that program is shown at the point clicked (a program of another setup opens that setup first, on the material the setups before it left — recomputed first where their inputs changed, with the progress on the viewport's hint). To the right of the buttons: elapsed / total of the whole project in h:mm:ss (the programs not run yet by their estimates); hover it for the current program's own part.nc: 0:00:12 / 0:00:58. The run times are estimates from feeds and the rapid speed only, without acceleration, so the real run takes longer.

The transport (bottom):

Space works also when a button has the focus, but not in a text field, the seek bar or a drop-down list, not with Ctrl, Cmd, Alt or Shift held, and not while a dialog is open. ← → and Home work the same way, except in the panel and the header, whose lists and tabs use those keys.