deploy webservice static-file routing for docsite folder URLs, per-instance step-cache db, and constant-height panel title bars.

This commit is contained in:
2026-08-27 14:51:37 +08:00
parent 1fc510af5e
commit 2a98ae7556
1468 changed files with 182837 additions and 18888 deletions
@@ -153,6 +153,7 @@ N… G01 Y10.005 (last layer)
</div>
<h2 id="see-also">See Also</h2>
<ul>
<li><a href="probabilistic-peak-crack.html">Probabilistic Peak &amp; Cutter Crack</a> — The general statement of the probabilistic peak effect this section describes</li>
<li><a href="corner-behavior.html">Corner Feedrate Behavior</a> — Force-peak interaction with controller deceleration at corners</li>
<li><a href="smart-holder-training.html">Smart Holder Training</a> — Smart tool holder measurement that confirms sub-micron sensitivity</li>
<li><a href="relief-face-avoidance.html">Relief Face Avoidance</a> — Related geometry sensitivity on the relief side</li>
@@ -95,15 +95,26 @@
<p>Cutting force computation begins after CWE is obtained. Since it is independent of computation order, it runs in multi-threaded mode under normal conditions. Torque and other physical quantities are also computed in parallel during this stage.</p>
<p>Temperature computation must follow time-series order, so it converges back to a single thread.</p>
<p>The entire machining simulation alternates between these modes. Once a step is fully computed, it is colored according to the designated indicator.</p>
<h2 id="two-independent-cost-drivers">Two Independent Cost Drivers</h2>
<p>Total simulation time comes from two largely independent parts:</p>
<ul>
<li><strong>Per-step physics</strong> (force, torque, power, temperature, wear) — computed once per <strong>step</strong>. The total physics cost scales with the <strong>number of steps</strong>, which is set by the <a href="../../workflows/basic-simulation.html#33-machining-motion-resolution">machining motion resolution</a> together with the spindle revolutions along the toolpath. It does <strong>not</strong> depend on the mesh resolution, and it does <strong>not</strong> depend on the overall workpiece size.</li>
<li><strong>Geometry removal</strong> (voxel subtraction) — its cost is set by the mesh resolution (<a class="xref" href="../../api/Hi.MachiningProcs.SessionShell.html#Hi_MachiningProcs_SessionShell_MachiningResolution_mm">MachiningResolution_mm</a>). A finer mesh (smaller value) is more expensive; a coarser mesh (larger value) is cheaper. Removal work is localized to the tool–workpiece contact region, so it is roughly area-scaled and, again, largely independent of the bulk workpiece size.</li>
</ul>
<p><code>MachiningResolution_mm</code> genuinely controls the removal resolution — it is <strong>not</strong> clamped away or ignored. But because removal and physics run concurrently, the <strong>larger</strong> of the two costs governs wall-clock time:</p>
<ul>
<li>When geometry removal dominates — <strong>the common case at the fine resolutions real NC machining needs</strong> — a finer mesh is much slower, and a coarser mesh reduces total time.</li>
<li>When the mesh is coarse enough that geometry removal is already cheap, several <strong>fixed per-step costs</strong> (physics, thermal/wear, per-step bookkeeping) dominate instead. Coarsening further — e.g. raising <code>MachiningResolution_mm</code> from 1.0 to 2.0 mm — then barely changes total time; to speed up, <strong>reduce the number of steps</strong> with a coarser motion resolution. (Note: 1–2 mm is already very coarse for NC machining.)</li>
</ul>
<h2 id="cpu-usage">CPU Usage</h2>
<h3 id="high-geometry-resolution">High Geometry Resolution</h3>
<p>When geometry resolution is high, geometry removal is faster than physics computation, so a large area of light pink follows behind the tool during simulation. There is a cap on the number of unfinished steps; geometry removal only proceeds when the count is within that limit. When physics computation cannot keep up with geometry removal, the number of pink steps stays constant.</p>
<p>In this scenario, the workload is primarily multi-core (physics computation), and you are more likely to see high multi-core CPU utilization.</p>
<p><img src="cpu-usage-img/geom-quick.png" alt="High geometry resolution"></p>
<h3 id="low-geometry-resolution">Low Geometry Resolution</h3>
<p>When geometry resolution is low, geometry removal is slower than physics computation, so the light pink area is barely visible.</p>
<p>In this scenario, the workload is primarily single-core (geometry computation).</p>
<p><img src="cpu-usage-img/geom-slow.png" alt="Low geometry resolution"></p>
<h3 id="coarse-mesh--physics-bound">Coarse Mesh — Physics-Bound</h3>
<p>When the mesh is coarse (a large <code>MachiningResolution_mm</code>), geometry removal is faster than physics computation, so a large area of light pink follows behind the tool during simulation. There is a cap on the number of unfinished steps; geometry removal only proceeds when the count is within that limit. When physics computation cannot keep up with geometry removal, the number of pink steps stays constant.</p>
<p>In this scenario, the workload is primarily multi-core (physics computation), and you are more likely to see high multi-core CPU utilization. Making the mesh even coarser will not reduce total time — the step count (physics) is the limit.</p>
<p><img src="cpu-usage-img/geom-quick.png" alt="Coarse mesh: geometry removal outruns physics, leaving a large pink trail"></p>
<h3 id="fine-mesh--geometry-bound">Fine Mesh — Geometry-Bound</h3>
<p>When the mesh is fine (a small <code>MachiningResolution_mm</code>), geometry removal is slower than physics computation, so the light pink area is barely visible.</p>
<p>In this scenario, the workload is primarily single-core (geometry computation), and a coarser mesh will reduce total time.</p>
<p><img src="cpu-usage-img/geom-slow.png" alt="Fine mesh: physics keeps up with geometry removal, almost no pink trail"></p>
<h3 id="balanced-state">Balanced State</h3>
<p>If the geometry resolution is such that geometry and physics computation do not bottleneck each other, the light pink area appears and fluctuates within a certain range. In this case, physics computation does not hold back geometry computation, and geometry computation is typically the performance bottleneck.</p>
<h3 id="cpu-not-fully-utilized">CPU Not Fully Utilized</h3>
@@ -100,6 +100,7 @@
<li><a href="relief-face-avoidance.html">Relief Face Avoidance</a> — Minimum relief angle and clearance</li>
<li><a href="radial-angle-measurement.html">Radial Angle Measurement</a> — Measuring radial rake and relief angles</li>
<li><a href="cam-floating-point-drift.html">CAM Floating-Point Drift</a> — A subtle CAM-NC issue that most workflows miss: sub-thousandth-mm drift between layers triggers floor-contact force peaks. HiNC detects and diagnoses it.</li>
<li><a href="probabilistic-peak-crack.html">Probabilistic Peak &amp; Cutter Crack</a> — Why the same cut passes most of the time and only occasionally cracks the cutter: a narrow high-contact window sampled by discrete flutes</li>
</ul>
<h2 id="simulation-performance">Simulation Performance</h2>
<ul>
@@ -103,6 +103,12 @@ For the underlying boundary curves and how each ratio's denominator is computed
<p><strong>Tool Breakage Solutions</strong></p>
<p>Modify the toolpath to reduce cutting width/depth, or use HiNC's optimization feature to adjust feed rates, bringing the <strong>Yielding Stress Ratio</strong>, <strong>Max Spindle Torque Ratio</strong>, and <strong>Max Spindle Power Ratio</strong> below 100%.</p>
</div>
<h2 id="ripple-on-curved-and-tilted-cuts-mesh-quantization">Ripple on Curved and Tilted Cuts (Mesh Quantization)</h2>
<p>On a nominally constant-engagement cut that is <strong>curved or tilted</strong> — arc or helical hole milling, ramping, or 5-axis moves — the <strong>Yielding Stress Ratio</strong> (and the underlying <a class="xref" href="../../api/Hi.MachiningSteps.MachiningStep.html#Hi_MachiningSteps_MachiningStep_MaxAbsForce_N">MaxAbsForce_N</a><small>(API)</small>) can show a small step-to-step ripple even though the theoretical engagement is steady. This is a discretization artifact, not a bug.</p>
<p><strong>Cause.</strong> The workpiece is represented by an axis-aligned cubic voxel mesh (see <a href="../../workflows/basic-simulation.html#31-workpiece-entity-resolution">Workpiece Entity Resolution</a>). Orthogonal cubes cannot represent a circle or an inclined face smoothly, so the removed volume and the contact engagement area quantize against the grid from step to step. That quantization shows up as ripple in the per-step peak force, and therefore in the ratio.</p>
<p><strong>What helps.</strong> A <strong>finer</strong> <code>MachiningResolution_mm</code> makes the quantization step smaller, so the ripple amplitude shrinks — at the cost of slower geometry removal (see <a href="cpu-usage.html">CPU Usage During Simulation</a>).</p>
<p><strong>What does <em>not</em> help.</strong> Switching to <strong>fixed-pace / sweeping</strong> motion resolution (<code>FixedPace</code>) does not remove this ripple. The ripple comes from the spatial cubic grid, not from the spacing between steps, so changing the step spacing leaves it essentially unchanged.</p>
<p><strong>Getting a smooth curve.</strong> There is no built-in filter that smooths step-series curves. If a smooth curve is needed for a report, post-process the exported CSV (<a class="xref" href="../../api/Hi.MachiningProcs.SessionShell.html#Hi_MachiningProcs_SessionShell_WriteStepFiles_">WriteStepFiles</a><small>(API)</small>) yourself — e.g. a moving average. Note that the Yielding Stress Ratio is defined on the per-revolution <strong>peak</strong> force only (there is no averaged variant); the averaged force fields (<code>Avg…</code>) are inherently smoother when a trend, rather than the breakage peak, is what you need to read.</p>
<h2 id="thermal-plastic-deformation-of-cutting-edge">Thermal Plastic Deformation of Cutting Edge</h2>
<p>If the <strong>Thermal Yield Ratio</strong> <small>[<a class="xref" href="../../api/Hi.MachiningSteps.MachiningStep.html#Hi_MachiningSteps_MachiningStep_ThermalYieldRatio">ThermalYieldRatio</a> (API)]</small> exceeds 100%, thermal plastic deformation of the cutting edge occurs, accelerating wear.
Unlike the Yielding Stress Ratio, Max Spindle Torque Ratio, and Max Spindle Power Ratio, this is a long-term indicator — exceeding 100% does not cause immediate effects.</p>
Binary file not shown.

After

Width:  |  Height:  |  Size: 79 KiB

@@ -0,0 +1,144 @@
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>Probabilistic Peak: Why a Cut Passes Most of the Time and Occasionally Cracks the Cutter | HiAPI-C# 2025 </title>
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="title" content="Probabilistic Peak: Why a Cut Passes Most of the Time and Occasionally Cracks the Cutter | 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="probabilistic-peak-why-a-cut-passes-most-of-the-time-and-occasionally-cracks-the-cutter">Probabilistic Peak: Why a Cut Passes Most of the Time and Occasionally Cracks the Cutter</h1>
<p><img src="probabilistic-peak-crack-img/dartboard-engagement.png" alt="Spindle-moment dartboard and the matching 3D engagement for one spindle revolution">
<em>Left — spindle-moment dartboard. The <code>(Mx, My)</code> moment-vector tip is drawn as a closed
locus over one spindle revolution, coloured by the axial moment <code>Mz</code>; the concentric rings
are moment magnitude (Nm). For most of the revolution the locus stays near the centre —
small flute–workpiece contact length, small moment. One narrow lobe stretches out to the
outer rings: the angle where the contact length spikes and produces the large force that
can crack the flute. Right — the 3D engagement at that high-load phase, showing the flute
deeply engaged with the workpiece.</em></p>
<h2 id="the-mechanism">The Mechanism</h2>
<p>The flute–workpiece contact length is small for most spindle angles and spikes only inside
one <strong>narrow angular window</strong>. The large force — and the crack risk — exists only inside
that window.</p>
<p>The cutter's flutes are <strong>discrete</strong>. Whether a cutting flute actually lands inside the
narrow high-contact window is a matter of flute phase, not a certainty:</p>
<ul>
<li><strong>High probability</strong> — the flutes fall in the wide low-contact region and step over the
window. The pass completes safely.</li>
<li><strong>Low probability</strong> — a flute lands inside the narrow window, takes the full contact
length, and sees the large force. The flute can crack.</li>
</ul>
<p>This is why a cut with a clear high-contact window still passes most of the time and only
occasionally breaks the cutter, and why nominally identical geometry can pass on one pass
and crack on another. It is the same effect documented under
<a href="cam-floating-point-drift.html#probabilistic-peak-dodging">Probabilistic Peak Dodging</a>.</p>
<h2 id="see-also">See Also</h2>
<ul>
<li><a href="cam-floating-point-drift.html">CAM Floating-Point Drift</a> — a concrete case of the same
probabilistic peak effect, triggered by sub-micron floor contact.</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>
Binary file not shown.

After

Width:  |  Height:  |  Size: 150 KiB

@@ -90,6 +90,8 @@
<p><a class="xref" href="../../api/Hi.Milling.SpindleCapability.html">SpindleCapability</a> <small>(API)</small> describes the energy, torque, power, and thermal envelope of a machine spindle. It is loaded as XML (<code>.SpindleCapability</code> files under <code>Resource/SpindleCapability/</code>) and lives on <a class="xref" href="../../api/Hi.Machining.MachiningEquipmentUtils.MachiningEquipment.html#Hi_Machining_MachiningEquipmentUtils_MachiningEquipment_SpindleCapability">SpindleCapability</a> <small>(API)</small> as part of the project equipment. This page explains what the model represents physically and how the per-step ratios on a machining step are derived.</p>
<p>For editing values interactively, see <a href="../../app-anatomy/mech/spindle-capability-page.html">Spindle Capability Page</a>. For empirical validation of the resulting power numbers against Fanuc ServoGuide, see <a href="spindle-power-evaluation.html">Spindle Power Evaluation</a>.</p>
<h2 id="boundary-curves-continuous-vs-instantaneous">Boundary curves: continuous vs instantaneous</h2>
<p><img src="spindle-capability-img/fanuc-at12-12000i.jpg" alt="Power and torque vs spindle speed for a FANUC aT12/12000i spindle"></p>
<p><em>A typical spindle datasheet chart (FANUC aT12/12000i, shipped as <code>FANUC-aT12-12000i.SpindleCapability</code>): torque (N-m) and power (kW) plotted against spindle speed. The <strong>S1 Cont.</strong> curves are the continuous boundary; the <strong>S3 60%</strong> curves are a short-duration rating. HiNC stores exactly these curves, keyed by workable duration.</em></p>
<p>The capability stores <strong>two dictionaries keyed by workable duration (in minutes)</strong>, mapping spindle speed to the maximum power or torque the spindle can deliver for that duration:</p>
<ul>
<li><a class="xref" href="../../api/Hi.Milling.SpindleCapability.html#Hi_Milling_SpindleCapability_WorkableDurationToSpindleSpeedPowerContoursDictionary_min_cycleDs_kW">WorkableDurationToSpindleSpeedPowerContoursDictionary_min_cycleDs_kW</a> <small>(API)</small></li>
@@ -36,6 +36,9 @@
<li>
<a href="cam-floating-point-drift.html" name="" title="CAM Floating-Point Drift">CAM Floating-Point Drift</a>
</li>
<li>
<a href="probabilistic-peak-crack.html" name="" title="Probabilistic Peak &amp; Cutter Crack">Probabilistic Peak &amp; Cutter Crack</a>
</li>
<li>
<a href="cpu-usage.html" name="" title="CPU Usage in Simulation">CPU Usage in Simulation</a>
</li>
@@ -1,2 +1,2 @@
{"items":[{"name":"Overview","href":"index.html","topicHref":"index.html"},{"name":"Milling Physics Coordinates","href":"milling-physics-coordinates.html","topicHref":"milling-physics-coordinates.html"},{"name":"Process Machinability","href":"machinability.html","topicHref":"machinability.html"},{"name":"Tool Life & Wear","href":"wear.html","topicHref":"wear.html"},{"name":"Cutter Adjustment Levers","href":"cutter-adjustment-levers.html","topicHref":"cutter-adjustment-levers.html"},{"name":"Relief Face Avoidance","href":"relief-face-avoidance.html","topicHref":"relief-face-avoidance.html"},{"name":"Radial Angle Measurement","href":"radial-angle-measurement.html","topicHref":"radial-angle-measurement.html"},{"name":"CAM Floating-Point Drift","href":"cam-floating-point-drift.html","topicHref":"cam-floating-point-drift.html"},{"name":"CPU Usage in Simulation","href":"cpu-usage.html","topicHref":"cpu-usage.html"},{"name":"Corner Feedrate Behavior","href":"corner-behavior.html","topicHref":"corner-behavior.html"},{"name":"Smart Holder Training","href":"smart-holder-training.html","topicHref":"smart-holder-training.html"},{"name":"Spindle Capability","href":"spindle-capability.html","topicHref":"spindle-capability.html"},{"name":"Spindle Power Evaluation","href":"spindle-power-evaluation.html","topicHref":"spindle-power-evaluation.html"},{"name":"NC Optimization Principles","href":"nc-optimization-principles.html","topicHref":"nc-optimization-principles.html"}]}
{"items":[{"name":"Overview","href":"index.html","topicHref":"index.html"},{"name":"Milling Physics Coordinates","href":"milling-physics-coordinates.html","topicHref":"milling-physics-coordinates.html"},{"name":"Process Machinability","href":"machinability.html","topicHref":"machinability.html"},{"name":"Tool Life & Wear","href":"wear.html","topicHref":"wear.html"},{"name":"Cutter Adjustment Levers","href":"cutter-adjustment-levers.html","topicHref":"cutter-adjustment-levers.html"},{"name":"Relief Face Avoidance","href":"relief-face-avoidance.html","topicHref":"relief-face-avoidance.html"},{"name":"Radial Angle Measurement","href":"radial-angle-measurement.html","topicHref":"radial-angle-measurement.html"},{"name":"CAM Floating-Point Drift","href":"cam-floating-point-drift.html","topicHref":"cam-floating-point-drift.html"},{"name":"Probabilistic Peak & Cutter Crack","href":"probabilistic-peak-crack.html","topicHref":"probabilistic-peak-crack.html"},{"name":"CPU Usage in Simulation","href":"cpu-usage.html","topicHref":"cpu-usage.html"},{"name":"Corner Feedrate Behavior","href":"corner-behavior.html","topicHref":"corner-behavior.html"},{"name":"Smart Holder Training","href":"smart-holder-training.html","topicHref":"smart-holder-training.html"},{"name":"Spindle Capability","href":"spindle-capability.html","topicHref":"spindle-capability.html"},{"name":"Spindle Power Evaluation","href":"spindle-power-evaluation.html","topicHref":"spindle-power-evaluation.html"},{"name":"NC Optimization Principles","href":"nc-optimization-principles.html","topicHref":"nc-optimization-principles.html"}]}