When Something Goes Wrong

A run that does not do what was expected has usually already said why, somewhere. This page is about which somewhere — the four lists on the Execution page at /execution, the Program branch at Control-Tree path execution/program, and the service's own log.

Start with the right list

The Session Messages panel, below the canvas, splits the session's messages across four lists, and picking the right one is most of the diagnosis. A tab carries a count only once its list has something in it, so a tab with no number beside its name is a sink nothing has reached.

Shell — the session's own account of itself: what started, what finished, what it built, and the verdicts it reaches at the end of a play. A conversion or an optimization reports itself here too, from its opening row to its closing count — an optimization stage by stage and file by file; a conversion in those two rows alone, the closing one carrying the count and the names of every file written in a single sentence, and a row of its own only for a file it could not write. These rows carry no anchor, because there is nothing in the program to anchor them to. This is the list a run that appears to have done nothing is diagnosed from — with two blind spots. A play that produced steps, none of which touched the workpiece, is reported here as Play-Touch--None, and the message names the usual causes — an incremental header with no G90 after it, a work offset or program zero that puts the program somewhere else, stock that is not where the program expects it, and the tool geometry. A play that produced no steps at all never reaches that warning, and still ends finished, with the strip charts empty. Most often no tool was ever mounted, and that is reported on Step Diagnostics, not here — Step-Tool--NotEquipped, at the first feed move made with the spindle empty — while NC Diagnostics often carries no trace of it: a G43 H1 compensates from the table whether or not a tool is in the spindle. The causes and their fixes are under A finished run with nothing to show. Nor is a play that touched the stock only in some of the places it should have — a part of a multi-part job played at the wrong offset, or a finishing program grazing a stock that was already finished — because one touching step anywhere is enough to silence the warning.
NC Diagnostics — everything the NC pipeline said while playing, which is not only complaints. It closes each file with the line count it read — the contains lines row is written once the file's last line has been consumed, so it follows every diagnostic that file raised, and a file the play is still reading has no such row yet — and a row about one sentence carries an anchor naming it. This is the list to read when the program did not do what its text says.
Step Diagnostics — anchored to a machining step rather than to a position in the text. Most of it is about motion, but not all: an NC-embedded script that fails to compile is reported here too, against the step it was reached from.
NC Manipulation — what the writeback found in the program while converting it to NC files or optimizing it: a block whose words it would not rewrite, an edit that matched no piece in the stream, a block the optimizer would not re-interpolate and optimized whole instead, a split arc whose written fragments no longer share one radius. It holds findings and nothing else, so a conversion or an optimization with nothing to complain about leaves this list empty; the run's own account of itself is on Shell.

A message about a G word and a message about a move are different problems, and they never share a list. Looking in the wrong one reads as silence.

A run that produced no steps can still show a cut part. In a mission laid out to resume, every Read On First Or Write record below the program reads its file when no step has been produced — so an end-of-stage file left by an earlier good run is loaded back, and the canvas and any geometry comparison show that earlier result as if this run had made it. Before trusting a result, check that the run produced steps at all: the strip charts carry them, and on the Program branch every file the run should have executed has marked lines. A Mission That Resumes is the layout this comes from.

A finished run with nothing to show

Three complaints lead here: a run that ends finished but cut nothing, a run whose steps cut but carry no cutting force, cutter temperature or Feed per Tooth, and a run that ends finished but left no step or shot file behind. All three start from one question — did the run produce machining steps at all? The strip charts carry them, and over HTTP GET /api/execution/cl-strip/range answers their number as count.

No steps: the spindle was empty. A session starts with no tool in the spindle unless the project saves one with its equipment; from then on a tool is mounted only by a tool-change command, or by a Manual Tooling entry in the mission. A program written for a machine whose operator changes tools by hand carries no T… M06, so nothing is ever mounted and none of its moves builds a step. Step Diagnostics reports it once per Reset, as Step-Tool--NotEquipped at the first feed move made with the spindle empty, naming that move's line and file. Give the simulation the tool the operator loads by hand, before the cuts. First choice: a Manual Tooling entry naming that tool above the program's Program File in the mission — Mounting the tool the operator loads by hand; the program keeps its lines and its file number. Otherwise a tool-change block at the start of the copy of the program you play — T1 M06. Not an NC Code entry holding T1 M06 above the Program File: it is played as a file of its own, so it takes a file number and every program after it moves up one, which misplaces a controller log mapped onto the run by file number (Mapping measured data onto the run). A program that applies no length compensation needs the tool's length as well: a G43 H for the tool in that copy, or the length folded into the work offset's Z the way the shop keeps it — Program Zero Alignment. Without it the tip runs a whole tool length below every programmed Z, and the play either touches nothing, ending with Play-Touch--None, or plunges that far into the stock.

The other causes of a run with no steps report themselves: a tool number the tool house does not hold raises Tooling--NotFound on Step Diagnostics, and a program file that is not there raises RunNcFile--NotFound on Shell and is skipped.

Steps, but no tool values: the spindle holds the project's own tool. A project that saves a tool with its equipment starts every session with a copy of it in the spindle, and that copy is not a tool of the tool house: until a tool-change command replaces it, HiNC counts it as tool 0. With no tool 0 in the tool house, the usual case, the moves made with it build steps and cut the stock, but nothing HiNC takes from a tool-house tool is there: Feed per Tooth reads NaN, and so does Program Side Cusp on the cutting steps; with physics on, the steps carry no cutting force, cutter temperature or wear, the spindle's own temperature is worked out as for a spindle running idle, and on the cutting steps Spindle Meter Power reads NaN and neither spindle energy grows; and the step-physics recompute leaves those steps out. Step Diagnostics reports it once per Reset, as Step-Tool--NotInHouse at the first step not made at rapid traverse, naming that step's line and file; a G00 or G28 move and a tool change's own travel say nothing. The fix is the one for an empty spindle: mount the tool-house tool before the cuts, with a Manual Tooling entry above the Program File or a tool-change block at the start of the program. A change to tool 0, T0 M06, mounts nothing when the tool house holds no tool 0, and the tool in the spindle stays: when an earlier tool change or a Manual Tooling entry took it from the tool house, the steps after the change go on with its number and those values, and Tooling--ZeroKeepsTool says so on that line; when it is the project's own tool, they remain tool 0.

Steps, but no file: the writer ran too early. A Post-Execution writes only what the session has played above it, so one placed before the programs it should cover has nothing to write. Each file a writer does write is announced on Shell as Creating file[…] between the writer's starts and finished rows, with the path the template expanded to — relative to the project folder unless the template is absolute. A writer that opened no file ends on the warning StepFile-Write--NoFile or ShotFile-Write--NoFile instead of finished, which is also what a run with no steps leaves. Move the Post-Execution below the programs; its rules are in Writing out what the run produced.

A second play without a Reset. A Start after a finished or stopped run plays the mission again on top of the session that run left — its steps, its messages and the stock as cut. A Post-Execution then walks the earlier play's steps along with the new ones, and one placed above the programs writes the earlier play's steps alone. What each file keeps follows the writers' rules: a lone program's file holds both plays, while with several programs — an NC Code entry among them — every file is reopened by the second play and holds that play alone. Press Reset before every run — Starting again: Reset first.

Reading a row

The four lists at /execution, with NC Diagnostics selected. Two of the four tabs carry no badge, which is how an empty sink looks. The warning at Sn 2105 sits above the line-count row for Inline finishing pass because that row closes its file rather than opening it.

A row carries, left to right, the position it is about, the category, the message's own id, and its text. The position is the anchor. On the two NC lists it is Sn and a number, naming a sentence. On Step Diagnostics it opens with S and the step's number, and when that step was reached from a sentence the one anchor carries both markers — S12 · Sn 340 names the step and then the sentence behind it; a step with no sentence behind it reads S and its number alone. A collision, a licence refusal or a step failure whose step was not built — the run paused or stopped before building it, building it failed, or a later step took its number — names its own program line instead, marked step not built (circle.nc:9 · step not built); Messages and Logs says when that happens. Not every row has one — a complaint about the pipeline rather than about a particular sentence has nothing to anchor to, and neither has anything on Shell.

The id is worth reading. It is stable across languages and releases, so it is the thing to quote when asking someone else about a message, and the thing to filter on when one message is repeating. The Filter text… box, the Severity and Category lists and Export are described with the rest of the panel in Messages and Logs.

Important

On the two NC lists, a row is not an occurrence. NC Diagnostics folds across the play of one mission command — one Program File or one NC Code entry, subprograms included, so a file played twice is two windows — and NC Manipulation across one conversion or optimization run; Shell and Step Diagnostics do no such folding — a report there gets a row of its own unless it is identical to the row just before it, in which case it joins that row under the multiplier badge described below. Where it applies, the pipeline keeps one entry per distinct message — same id, same wording — and drops every repeat instead of listing it. When the program ends, each message that occurred more than once gets one summary row: the first occurrence's text followed by [repeated Nx in this run, first at Sn=…], with the count in place of N and the sentence it was first seen on after Sn= (a message with no sentence to anchor to ends in [repeated Nx in this run] instead). So a diagnostic raised on forty different sentences of one file leaves two rows for that file: the first occurrence, and the summary — and the same diagnostic raised again in the next file, or on the same file's second play, starts over with a first occurrence and a summary of its own. The screenshot above shows the window's edge: circle.ptp is played twice, and its line-count row is listed twice rather than folded.

Two consequences are worth holding on to. The count is only in that summary sentence — the multiplier badge that marks consecutive identical messages is a different mechanism and does not appear on these. And the summary row's anchor is the last occurrence while its text names the first, so the Sn in its anchor column is the end of the run of repeats and the Sn= in its text the beginning. Neither is a link: clicking a row opens its detail when it has one and does nothing else, so an anchor is a position to read off, not a place to go. Everything between the two rows has no anchor at all: to find those positions, fix the first one and play again.

Then the run's own record

The Program branch holds what the run did to each line — the passes it made and the marks each one left. A line that was expected to cut and was not marked was not executed in that pass. See The Program Branch.

The two records answer different questions and are worth reading together: NC Diagnostics says what the pipeline thought of a sentence while it was playing, the Program branch says what that sentence produced.

Then the service log

Log Viewer, on the Help menu, opens the log the service is writing for the current day, with a Download for sending it to someone else. It holds things the four lists do not carry — the engine's own start-up account of itself, one line for each run with the errors and warnings it counted for NC, step and shell, and the exception behind a failure the engine did not report through a message, which the service writes to the log and nowhere else — and it outlives the session: a Reset on the transport — the eject button in the run header, not the Reset in a tab's filter toolbar, which clears that tab's filters and touches no list — empties Shell, NC Diagnostics and Step Diagnostics, and the log keeps what it had. Of the four lists themselves the log keeps only the warnings and errors, each with its message id, its anchor and the exception it carried, and no more than twenty of one message id in a run — the run's closing line counts the rest. Milder rows, and repeats past that cap, are in the lists alone. An exception the engine reported through a message also rides its row, which carries a chevron; opening it shows the exception in full, with a Copy of its own, so a script that would not compile or a step record that could not be read is answered from the list first. The one list the transport's Reset leaves alone is NC Manipulation — the next conversion or optimization is what empties it — so the last conversion's findings are still on that tab after the run has been reset away, and its warnings and errors are in the log as well. The viewer itself is described in Messages and Logs.

While an optimization is running

An optimization reports itself on Shell, stage by stage. It opens with Start NC optimization. and ends with Total N files optimized. Between them it first scans the program, matching each line to the steps it made; the scan has no row of its own to open it, and closes with NC line to step segment mapped. Un-optable lines are filtered. From there every stage announces itself as it begins: Computing Optimized Feed by indivisual step.., closed by Optimization Feedrate built. once the per-step feeds are solved, then Constrain feedrate By expaneded segment.., Constrain Feedrate By Acceleration.., Build Compensation.. and Regenerate NC commands.., with one File optimized: row naming each output file as it is finished.

Three of those stages count aloud, and they are the only way to tell a slow optimization from a stopped one. While the program is scanned, every thousandth block adds a Scanning NC for optimization.. row carrying the source file and line it has reached; while the per-step feeds are being solved, every thousandth step adds another Computing Optimized Feed by indivisual step.. row carrying the same two numbers; while the optimized text is being written, every thousandth line adds a Now optimizing to: row carrying them too. Each of them is a row on Shell, subject to the one folding Shell does: the file and line on a step row are those of the sentence the step came from, so a sentence that expands to more than a thousand steps — a long arc at a fine resolution — puts the same two numbers on two consecutive rows, and those join under the multiplier badge. And because the per-step feeds are solved in parallel, the numbers on successive step rows need not climb in strict order. What holds either way is that the newest row is where the run has got to: numbers that keep changing are a run still working, and a list that has stopped growing on a stage whose successor has not been announced is a run that is not.

The counting rows are the instrument, not the stage rows. A stage with fewer than a thousand blocks to scan, steps to solve or lines to write adds no counting row between its first row and its last — for the scan, none between Start NC optimization. and the mapping row — so a short program crosses the whole ladder in near-silence, and that silence means nothing on its own.

A Stop ends an optimization on the same closing row as a finished one. Stop reaches the optimizer between blocks while the program is scanned, between steps while the feeds are solved and between the pieces of a file while it is written — a constraint, compensation or edit-building pass it lands in runs to its end first, and one after the compensation build is seen only at the first file — rather than only at the end, and what it leaves on Shell is optimization canceled. followed immediately by Total N files optimized. in success green, after which the run ends: only the run's own end-of-run notices can follow. Even Total 0 files optimized. arrives as a success. A Stop that lands while the per-step feeds are being solved puts one more row ahead of those: Optimization Feed Process canceled. stands where Optimization Feedrate built. would have. The count is of the files the run had opened, so a file the Stop landed part-way through is counted with the rest and is left on disk short. The complete ones are those whose own File optimized: row appeared before the cancel. The files after it are not touched at all, so one an earlier run wrote keeps that run's content, which can pass for this run's.

Three things that look like faults and are not

An English message in a translated interface is the safe answer, not a bug. Engine messages arrive with an id and their English text, and the interface translates by id. For a message that carries values — a file name, a count, a line number — it substitutes its own translation only when its template for that id matches the one the engine sent; an engine built against a different message set, or a message the interface has no entry for, leaves the original English in place rather than rendering text that might say something else. A message with no values in it is swapped on its id alone, with no comparison of wording, so an engine that has reworded such a message while keeping its id shows, in a translated interface, the translation of the wording it had before. In both cases the English the engine sent is the accurate text, and switching the interface to English shows every message exactly as it arrived.

An action refused because a program is playing or paused is a guard, not a fault. Switching the NC runner and switching the controller brand are both refused while an NC program is playing or paused, rather than swapping the parser underneath it. The refusal is a toast that opens with the name of the action it refused and the status the service answered with: Switch controller brand: HTTP 409: Cannot switch the controller brand while an NC program is playing or paused; stop it, or let it finish first. for a brand switch, and Install NC runner: HTTP 409: Cannot switch the NC runner while an NC program is playing or paused; stop it, or let it finish first. for a runner installed through the Controller branch's Object Management menu, by a Load, a paste or an XML Mode Apply. Those three also raise a green toast of their own beside it — Loaded …, Pasted … or XML applied — which says only that the runner was read in: the controller in force has not changed. The refusal arrives on the action itself — no row is added to any of the four lists, so there is nothing to go looking for afterwards.

An empty Step Diagnostics list is not proof that nothing was wrong. Collision detection is off unless the mission turns it on, and the physics-dependent warnings — the cutter geometry checks raised at tool change among them — are not raised at all when physics is off. A quiet list on a run with those switched off says only that nothing was being watched for.

If it is a configuration problem rather than a run problem

Some failures are the setup answering late. A cutter whose upper beam is shorter than its flute cannot build its thermal shell. The Upper Beam editor flags it while the tool is being edited, and a run that equips that tool reports it again at tool change, in Step Diagnostics — provided physics is on, which is what makes that check run. See Cutter Geometry.

Table of Contents