This repository has been archived on 2026-10-11. You can view files and clone it. You cannot open issues or pull requests or push a commit.
Files
HiNC-2025-win-desktop-Deploy/App/wwwroot/HiAPI-docsite/manual/run/when-something-goes-wrong.html
T
2026-09-09 17:35:23 +08:00

245 lines
16 KiB
HTML

<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>When Something Goes Wrong | HiAPI-C# 2025 </title>
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="title" content="When Something Goes Wrong | HiAPI-C# 2025 ">
<link rel="icon" href="../../img/HiAPI.favicon.ico">
<link rel="stylesheet" href="../../public/docfx.min.css">
<link rel="stylesheet" href="../../public/main.css">
<meta name="docfx:navrel" content="../../toc.html">
<meta name="docfx:tocrel" content="toc.html">
<meta name="docfx:rel" content="../../">
<meta name="loc:inThisArticle" content="In this article">
<meta name="loc:searchResultsCount" content="{count} results for &quot;{query}&quot;">
<meta name="loc:searchNoResults" content="No results for &quot;{query}&quot;">
<meta name="loc:tocFilter" content="Filter by title">
<meta name="loc:nextArticle" content="Next">
<meta name="loc:prevArticle" content="Previous">
<meta name="loc:themeLight" content="Light">
<meta name="loc:themeDark" content="Dark">
<meta name="loc:themeAuto" content="Auto">
<meta name="loc:changeTheme" content="Change theme">
<meta name="loc:copy" content="Copy">
<meta name="loc:downloadPdf" content="Download PDF">
<script type="module" src="./../../public/docfx.min.js"></script>
<script>
const theme = localStorage.getItem('theme') || 'auto'
document.documentElement.setAttribute('data-bs-theme', theme === 'auto' ? (window.matchMedia('(prefers-color-scheme: dark)').matches ? 'dark' : 'light') : theme)
</script>
</head>
<body class="tex2jax_ignore" data-layout="" data-yaml-mime="">
<header class="bg-body border-bottom">
<nav id="autocollapse" class="navbar navbar-expand-md" role="navigation">
<div class="container-xxl flex-nowrap">
<a class="navbar-brand" href="../../index.html">
<img id="logo" class="svg" src="../../img/HiAPI.logo.png" alt="">
</a>
<button class="btn btn-lg d-md-none border-0" type="button" data-bs-toggle="collapse" data-bs-target="#navpanel" aria-controls="navpanel" aria-expanded="false" aria-label="Toggle navigation">
<i class="bi bi-three-dots"></i>
</button>
<div class="collapse navbar-collapse" id="navpanel">
<div id="navbar">
<form class="search" role="search" id="search">
<i class="bi bi-search"></i>
<input class="form-control" id="search-query" type="search" disabled placeholder="Search" autocomplete="off" aria-label="Search">
</form>
</div>
</div>
</div>
</nav>
</header>
<main class="container-xxl">
<div class="toc-offcanvas">
<div class="offcanvas-md offcanvas-start" tabindex="-1" id="tocOffcanvas" aria-labelledby="tocOffcanvasLabel">
<div class="offcanvas-header">
<h5 class="offcanvas-title" id="tocOffcanvasLabel">Table of Contents</h5>
<button type="button" class="btn-close" data-bs-dismiss="offcanvas" data-bs-target="#tocOffcanvas" aria-label="Close"></button>
</div>
<div class="offcanvas-body">
<nav class="toc" id="toc"></nav>
</div>
</div>
</div>
<div class="content">
<div class="actionbar">
<button class="btn btn-lg border-0 d-md-none" type="button" data-bs-toggle="offcanvas" data-bs-target="#tocOffcanvas" aria-controls="tocOffcanvas" aria-expanded="false" aria-label="Show table of contents">
<i class="bi bi-list"></i>
</button>
<nav id="breadcrumb"></nav>
</div>
<article data-uid="">
<h1 id="when-something-goes-wrong">When Something Goes Wrong</h1>
<p>A run that does not do what was expected has usually already said why, somewhere. This page is about
which <em>somewhere</em> — the four lists on the Execution page at <code>/execution</code>, the Program branch at
Control-Tree path <code>execution/program</code>, and the service's own log.</p>
<h2 id="start-with-the-right-list">Start with the right list</h2>
<p>The <strong>Session Messages</strong> 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.</p>
<ul>
<li><strong>Shell</strong> — 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, stage by stage and file by file, from its opening row to its closing count. These rows carry
no anchor, because there is nothing
in the program to anchor them to. <strong>This is the list a run that appears to have done nothing is
diagnosed from</strong>: a play that ends with no step having touched the workpiece is reported here, and
the message names the usual causes — an incremental header with no <code>G90</code> after it, a work offset
or program zero that puts the program somewhere else, stock that is not where the program expects
it.</li>
<li><strong>NC Diagnostics</strong> — everything the NC pipeline said while playing, which is not only complaints.
It opens each file with the line count it found, 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.</li>
<li><strong>Step Diagnostics</strong> — 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.</li>
<li><strong>NC Manipulation</strong> — 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 <strong>Shell</strong>.</li>
</ul>
<p>A message about a <code>G</code> word and a message about a move are different problems, and they never share a
list. Looking in the wrong one reads as silence.</p>
<h2 id="reading-a-row">Reading a row</h2>
<p><img src="when-something-goes-wrong-img/nc-diagnostics.en.png" alt="The Execution page with the left and right columns switched off: the canvas above, and below it the Session Messages panel with the NC Diagnostics tab selected. The tab row shows Shell badged 10 and NC Diagnostics badged 7, with Step Diagnostics and NC Manipulation carrying no badge at all. Under a filter toolbar of Severity, Category, a text box, Reset and Export, seven rows are listed: six System rows reading Sys-Init&ndash;FileLines with each file and its line count, and one warning row whose anchor column reads Sn 2105, category Unsupported, id Parsing&ndash;Unconsumed, text Unconsumed Parsing entries: G02"></p>
<p><em>The four lists at <code>/execution</code>, with NC Diagnostics selected. Two of the four tabs carry no badge,
which is how an empty sink looks.</em></p>
<p>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: <code>Sn</code> and a number for a sentence, <code>S</code> and a number for a step. 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 <strong>Shell</strong>.</p>
<p>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 <strong>Filter text…</strong> box, the <strong>Severity</strong> and <strong>Category</strong> lists and <strong>Export</strong> are described with
the rest of the panel in <a href="../basics/messages-and-logs.html">Messages and Logs</a>.</p>
<div class="IMPORTANT">
<h5>Important</h5>
<p><strong>On the two NC lists, a row is not an occurrence.</strong> <strong>NC Diagnostics</strong> folds across a play and
<strong>NC Manipulation</strong> across one conversion or optimization run; <strong>Shell</strong> and <strong>Step Diagnostics</strong>
fold nothing, and every report they take becomes a row of its own. 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 reading <em>repeated N
times in this run, first at</em> the sentence it was first seen on. So a diagnostic raised on forty
different sentences leaves two rows for that program: the first occurrence, and the summary.</p>
<p>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 <strong>the summary row's anchor is the last occurrence while its text names the
first</strong>, so jumping from it lands at the end of the run of repeats, not at the beginning.
Everything between the two rows has no anchor at all: to find those positions, fix the first one
and play again.</p>
</div>
<h2 id="then-the-runs-own-record">Then the run's own record</h2>
<p>The <strong>Program</strong> 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
<a href="the-program-branch.html">The Program Branch</a>.</p>
<p>The two records answer different questions and are worth reading together: <strong>NC Diagnostics</strong> says
what the pipeline thought of a sentence while it was playing, the <strong>Program</strong> branch says what that
sentence produced.</p>
<h2 id="then-the-service-log">Then the service log</h2>
<p><strong>Show Log</strong> on the menu bar opens the log the service is writing for the current day, with a
<strong>Download</strong> for sending it to someone else. It holds things the four lists never carry — the
exception behind a failure, and the engine's own start-up account of itself — and it is the only
one of these surfaces that outlives the session. What it does not hold is the four lists: those are
pushed to the browser and are never written to the file, so a message seen in a list is not
findable there. The viewer itself is described in
<a href="../basics/messages-and-logs.html">Messages and Logs</a>.</p>
<h2 id="while-an-optimization-is-running">While an optimization is running</h2>
<p>An optimization reports itself on <strong>Shell</strong>, stage by stage. It opens with <em>Start NC optimization.</em>
and ends with <em>Total N files optimized.</em> and <em>optimization cache cleared.</em>, and between them every
stage announces itself as it begins: <em>Computing Optimized Feed by indivisual step..</em>, closed by
<em>Optimization Feedrate built.</em> once the per-step feeds are solved, then <em>Constrain feedrate By
expaneded segment..</em>, <em>Constrain Feedrate By Acceleration..</em>, <em>Build Compensation..</em> and <em>Regenerate
NC commands..</em>, with one <em>File optimized:</em> row naming each output file as it is finished.</p>
<p>Two of those stages count aloud, and they are the only way to tell a slow optimization from a
stopped one. While the per-step feeds are being solved, every thousandth step adds another
<em>Computing Optimized Feed by indivisual step..</em> row carrying the source file and line it has
reached; while the optimized text is being written, every thousandth line adds a <em>Now optimizing
to:</em> row carrying the same two numbers. <strong>Shell appends every one of them and folds nothing</strong>, so
its newest row is where the run has got to: numbers that keep advancing 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.</p>
<p>The counting rows are the instrument, not the stage rows. A stage with fewer than a thousand steps
to solve, or fewer than a thousand lines to write, announces its start and then says nothing until
it ends — so a short program crosses the whole ladder in near-silence, and that silence means
nothing on its own.</p>
<p><strong>A Stop ends an optimization on a success row.</strong> Stop reaches the optimizer between steps and
between output files rather than only at the end, and what it leaves on <strong>Shell</strong> is <em>optimization
canceled.</em> followed immediately by <em>Total N files optimized.</em> in success green — even <em>Total 0 files
optimized.</em> arrives as a success. 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 <em>File optimized:</em> row appeared before the cancel.</p>
<h2 id="three-things-that-look-like-faults-and-are-not">Three things that look like faults and are not</h2>
<p><strong>An English message in a translated interface is the safe answer, not a bug.</strong> Engine messages
arrive with an id and their English text, and the interface substitutes its own translation only
when its copy of that message matches the one the engine sent. An engine built against a different
message set, or a message the interface has no copy of, leaves the original English in place rather
than rendering text that might say something else. The English is the accurate text.</p>
<p><strong>An action refused because a run is playing is a guard, not a fault.</strong> Switching the NC runner and
switching the controller brand are both refused while a program is playing, rather than swapping the
parser underneath it; the refusal names the reason and asks for the run to be paused or finished
first. It arrives on the action itself — no row is added to any of the four lists, so there is
nothing to go looking for afterwards.</p>
<p><strong>An empty Step Diagnostics list is not proof that nothing was wrong.</strong> 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.</p>
<h2 id="if-it-is-a-configuration-problem-rather-than-a-run-problem">If it is a configuration problem rather than a run problem</h2>
<p>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 <strong>Step Diagnostics</strong> — provided
physics is on, which is what makes that check run. See
<a class="xref" href="../../technique/milling-physics/cutter-geometry.html">Cutter Geometry</a>.</p>
<h2 id="see-also">See Also</h2>
<ul>
<li><a href="index.html">Running a Simulation</a> — the rest of running a job</li>
<li><a href="running-a-simulation.html">Starting and Stepping</a> — the transport, and the run state this page reads</li>
<li><a href="the-program-branch.html">The Program Branch</a> — what the run recorded against each line</li>
<li><a href="../basics/messages-and-logs.html">Messages and Logs</a> — the panel these four lists live in, the footer, and the service's log viewer</li>
</ul>
</article>
<div class="contribution d-print-none">
</div>
<div class="next-article d-print-none border-top" id="nextArticle"></div>
</div>
<div class="affix">
<nav id="affix"></nav>
</div>
</main>
<div class="container-xxl search-results" id="search-results"></div>
<footer class="border-top text-secondary">
<div class="container-xxl">
<div class="flex-fill">
<span> Copyright © 2025 <a href='https://superhightech.com.tw'>Tech Coordinate</a>. All rights reserved. <a href='https://superhightech.com.tw'>超級高科技股份有限公司</a> © 2025 版權所有 </span>
</div>
</div>
</footer>
</body>
</html>