deploy.

2026-09-13 19:45:24 +08:00
parent 397a7a8cc4
commit 2db889ad89
58 changed files with 3526 additions and 213 deletions
@@ -114,8 +114,29 @@ pieces now carry the positioning section forward like every other modal syntax.<
 program machined one tool length low. The read point now falls back to the generic tool-number-keyed
 height and emits <code>SiemensToolOffset--TcdpRowMissing</code>.</li>
 <li><strong>G43.4 with an unresolvable H word activated RTCP with a zero-length tool.</strong> It now reports
-<code>Comp-ToolHeight--001</code> as a warning and keeps processing the block. An absent H stays silent —
-re-activating G43.4 on the modal offset id is legitimate input.</li>
+<code>Comp-ToolHeight--001</code> as a warning and keeps processing the block. An omitted H is no longer a
+silent zero: it takes the equipped tool's own offset row first (HardNc parity), then a non-zero
+modal id, and only then warns <code>Comp-ToolHeight--NoToolForOmittedH</code> (plain G43) or
+<code>Comp-ToolHeight--NoToolForOmittedHRtcp</code> (G43.4). A vacant table row warns
+<code>Comp-ToolHeight--RowMissing</code> instead of compensating a zero length.</li>
+<li><strong><code>G43.4</code> survived <code>M02</code> / <code>M30</code> and a rotary-only <code>G53</code> still coupled through RTCP.</strong> A sequence
+that ended one program with <code>M02</code> and started the next with a rotary rapid — without a <code>G49</code> —
+kept tool-centre-point control on, pinned the tip, and dragged machine XYZ through the stock. On
+SoftNc the program-end block is a <strong>reset edge</strong>: tool-length compensation (G43 / G44 / G43.4,
+Siemens <code>TRAORI</code>, Heidenhain <code>M128</code>), tilt (G68 / G68.2 / CYCLE800 / <code>PLANE</code> / TRANS), G41/G42 and
+G81–G89 cancel on the <em>next</em> block, written as explicit cancel sections so modal carry cannot copy
+the previous state. The <code>M02</code> block itself still runs under the modal state it executed with, so a
+retract on the same line as <code>M30</code> still carries tool length. A rotary-only <code>G53</code> under active
+RTCP now holds the linear axes at the previous machine position and stays McLinear, which is what
+G53 does on a control (no compensation). <strong>HardNc still carries G43.4 across <code>M02</code></strong> — the two
+engines are deliberately divergent on that edge; 3.2's default is SoftNc. A tool change that
+leaves <code>G43.4 Hm</code> alive for a different tool warns
+<code>Comp-ToolHeight--RtcpOutlivesToolChange</code> on the change block.</li>
+<li><strong>Fanuc <code>G54.1 Pn</code> (also written <code>G54 Pn</code>) was not resolved.</strong> Additional work coordinate systems
+now resolve against the extended table; a selected row nobody has entered reports
+<code>Coord-WorkOffset--AdditionalZero</code> and runs on the machine origin. <code>G59.1</code>–<code>G59.9</code> have a
+provider on the ISO presets. See
+<a href="../../anatomy/general-setup/controller/program-data/work-coordinates.html">Work Coordinates</a>.</li>
 <li><strong>Heidenhain DIN/ISO arc centres.</strong> <code>I</code> / <code>J</code> / <code>K</code> are <strong>absolute</strong> circle centres on Heidenhain —
 the ISO face of the klartext <code>CC</code> pole — not start-to-centre offsets. Reading them incrementally
 turned arcs into near-full phantom circles. Fixed in all three engines: the HardNc reader
@@ -132,10 +153,19 @@ to the workpiece over the step duration. On XYZ moves, CL files and RTCP with th
 offset the two agree (the recomputation moves forces by at most about 1e-4 relative, from the
 <code>TimeSpan</code>-quantised step duration); they part under RTCP with a tool-length offset that does not
 describe the equipped tool, on rotary-axis-limited simultaneous five-axis blocks (the tip is slower
-than F, up to a few percent), and wherever the commanded value was stale. One such stale case is
-fixed alongside: a feed block that repeats the current position (<code>X.. Y.. Z.. F1600.</code> right after
-the same point at <code>F800.</code>) lost its F word, so every following block showed and cut at the old
-feed; its <code>ActFeedrate</code> now lands.</li>
+than F, up to a few percent), and wherever the commanded value was stale.</li>
+<li><strong>A feed block that does not move lost its F word.</strong> A block that repeats the current position
+(<code>X.. Y.. Z.. F1600.</code> right after the same point at <code>F800.</code>, a common CAM habit) returned on
+zero distance before emitting anything, so every following block showed and cut at the old
+feed. Its <code>ActFeedrate</code> now lands on a zero-length linear, arc or polar block alike. The same
+stale commanded value is one of the cases the tip-feedrate split above parts on.</li>
+<li><strong>A rotary-bearing act mixed tip travel with the commanded CL feed resolution.</strong> On a pure RTCP
+rapid swing the CL point stands still, the commanded feed is ~0, and dividing the equipped tool's
+tip sweep by that resolution saturated the step count (the play appeared to hang on one line). A
+rotary-bearing act now splits by posture change (each rotary-axis delta over the rotary
+resolution) and by spindle cycles when the spindle turns — never by tip travel over the CL-feed
+resolution. Step counts of existing five-axis projects therefore shift on non-RTCP rotary
+blocks; XYZ-only programs are unaffected.</li>
 <li><strong>A <code>K0</code> word on a HardNc G02/G03 saturated the turn count.</strong> Under the default G17 plane a
 written-but-zero plane-normal word divided the axial travel by zero, the additional-turn count
 saturated to <code>int.MaxValue</code>, and one arc block became a spiral act of roughly 302 simulated years —