deploy.

App/wwwroot/HiAPI-docsite/workflows/force-training.html

@@ -367,7 +367,7 @@ refining further showed no benefit.</p>
 <pre><code class="lang-csharp">WriteStepFiles(&quot;Output/[NcName].step.csv&quot;);
 WriteShotFiles(&quot;Output/[NcName].shot.csv&quot;, 0.1); // 2nd arg = sampling period in ms
 </code></pre>
-<p>The shot file contains time-resolved force columns: <code>Tool.Fx/Fy/Fz</code>, <code>Workpiece.Fx/Fy/Fz</code>, <code>Spindle.Mx/My/Mz</code>.</p>
+<p>The shot file opens with <code>FileNo</code>, <code>LineNo</code>, <code>Time</code> and the mission's M-codes, then carries the time-resolved force columns: <code>Tool.Fx/Fy/Fz</code>, <code>Workpiece.Fx/Fy/Fz</code>, <code>Holder.Mx/My/Mz</code> — the same holder spelling the reader writes, not the obsolete <code>Spindle.M*</code>. A play driven from a controller CSV appends <code>ActualDateTime</code>; an NC-simulated play has no controller instant to stamp and omits that column.</p>
 <h3 id="-the-shot-sampling-period-is-the-dominant-accuracy-lever">⚠ The shot sampling period is the dominant accuracy lever</h3>
 <p>The second argument of <a class="xref" href="../api/Hi.MachiningProcs.SessionShell.html#Hi_MachiningProcs_SessionShell_WriteShotFiles_">WriteShotFiles</a> is the sampling period in <strong>milliseconds</strong>, and when a simulated shot file is fed back into training it — not the angular division count, not the machining resolution — sets the accuracy ceiling. Each row is interpolated from the per-division force waveform, so the information per revolution is <code>min(MillingCycleDivisionNum, samples per revolution)</code>, where</p>
 <pre><code>samples per revolution = 60000 / (rpm × samplingPeriod_ms)