Table of Contents

Workflow: Milling Force Parameter Training

This workflow covers the end-to-end process of training milling force coefficients from sensor data, including data mapping, coefficient training, quality evaluation, and application of the trained parameters.

Milling coefficients are essential parameters for calculating milling forces. Training derives these coefficients from experimental sensor data (dynamometer or smart tool holder) mapped to simulated toolpaths.

flowchart TD
    Prereq["Prerequisites<br>(sensor data, project setup)"]
    Resolution["Configure resolution & enable physics"]
    Mapping["Configure data mapping"]
    Simulate["Run simulation with NC file"]
    Export["Export simulation data<br>(WriteShotFiles, WriteStepFiles)"]
    Map["Map sensor data to simulation"]
    Train["Train milling parameters"]
    Evaluate["Evaluate training quality"]
    Apply["Load trained parameters"]

    Prereq --> Resolution --> Mapping --> Simulate --> Export
    Simulate --> Map --> Train --> Evaluate --> Apply

1. Prerequisites

Tip

For the complete data-collection checklist behind a project, see Project Data Checklist.

Before training you need:

Item Description
HiNC project Machine tool, workpiece, fixture, tool house configured
NC file The NC program used during the physical cutting experiment
Sensor data CSV Time-stamped force/torque data from a dynamometer or smart tool holder
Controller data CSV (optional) Machine controller log with FileNo, LineNo, ActualTime for two-layer mapping
Important

Before training, the workpiece + fixture must be correctly placed relative to the work offset, otherwise the simulated engagement (and therefore the trained coefficients) is wrong. See Program Zero Alignment — particularly the high-fidelity caution that the G54 used must reflect the real machine offset, and the rough-resolution check for catching a wrong setup at the opening plunge.

Sensor Data File Format

The CSV must contain a header row with ActualTime and at least one force/torque channel:

Source Headers
Dynamometer Fx (or Workpiece.Fx), Fy, Fz
Smart tool holder Mx (or Holder.Mx), My, Mz
Accelerometer (optional) Ax, Ay, Az
ActualTime,CH1,CH2,Mx,My,Mz
18:23:54.703,-0.00398,-0.00034,-0.02923,0.10733,0.00409
18:23:54.704,-0.00194,0.00285,0.04155,-0.04457,0.00448
...
Tip

Keep the completed training project archived. When the HiNC training algorithm is updated, you can re-run training from the same project.


2. Configure Resolution and Enable Physics

Resolution

Use a finer resolution than normal operation for training accuracy:

MachiningResolution_mm = 0.0625; // half or less of production resolution
MachiningMotionResolution = FeedPerTooth;
Tip

Training resolution should be ≤ 0.5× the production resolution for better accuracy.

Enable Physics

EnablePhysics must be enabled for force calculation:

EnablePhysics = true;

Milling Force Cycle Division

MillingCycleDivisionNum is the number of angular divisions per spindle revolution used by the force evaluation. The default is 36, which is intended for normal simulation — force playback does not benefit from a finer division, and raising it only slows the physics down. Training is the exception: phase alignment and coefficient quality improve with a finer division, so set it in the training script:

MillingCycleDivisionNum = 180; // training only; default 36 is for normal simulation
Note

This must be set before the simulation run that TrainMillingPara consumes.

How much is enough — measured (2-flute D8, Al6061-T6, MachiningResolution_mm 0.03125, sensor series sampled at 0.1 ms):

MillingCycleDivisionNum R Fc error @ t=0.2 Fn error @ t=0.2 ploughing coefficients
36 (default) 91.5 % −6.7 % −8.8 % badly off (Kpc +40 %)
180 95.2 % −6.6 % −6.1 % Kpc +10 %
720 95.2 % −6.9 % −6.3 % Kpc +11 %

180 is the sweet spot: the default 36 is genuinely too coarse for training (the ploughing coefficients degrade badly), and 720 buys nothing while costing 4× the physics. Do not assume “larger is always better”.

Warning

The value is process-wide, not per-project: it is not saved into the .hincproj, and it survives ResetRuntime() and project switches. Two consequences: (a) a training script must always set it explicitly — a fresh service instance starts at 36; (b) after training, the same instance keeps the large value, so subsequent normal simulations run slower until you set it back (or restart the instance).


3. Configure Data Mapping

Depending on your data, choose one of the mapping strategies below.

3.1 Local Mapping (Anchor-Based)

For mapping sensor data to specific NC path segments:

Step A — Specify input data:

ClearTimeMappingData();
AddTimeDataByFile("lineA", "Mapping/sensor1.csv", "18:25:51.7100", "18:26:12.9910");
AddTimeDataByFile("lineB", "Mapping/sensor1.csv", "18:26:30.5750", "18:27:12.2880");

Step B — Specify NC paths (embedded in NC code comments):

X13. F20 ;@LineSelection("lineA", FirstTouch, ShiftTime_s(2), LineEnd, ShiftDistance_mm(-1));
X25. F10 ;@LineSelection("lineB", FirstTouch, null, LastTouch, null);

Anchor options: LineBegin, LineEnd, FirstTouch, LastTouch. Offset options: null, ShiftTime_s(<seconds>), ShiftDistance_mm(<mm>).

3.2 Two-Layer Chained Mapping (Controller + Sensor)

When you have both controller data and sensor data:

PlayNcFile("NC/machining.nc");
MapSingleByCsvFile("Data/controller.csv");  // maps FileNo/LineNo → ActualTime
MapSeriesByCsvFile("Data/sensor.csv");     // ActualTime → sensor series
Note

Why two-layer mapping? Running the NC through the system interpreter produces more accurate simulation paths than direct CSV playback. The controller data bridges simulation steps to real time via FileNo/LineNo, and the sensor data bridges real time to force/torque readings.

⚠ Train on the steady part of the cut — it is the largest single lever

MapSeriesByCsvFile pairs each step with a window of sensor samples. The window is anchored at the step's end time and runs forward for one cycle period, so the samples a step is fitted against are the ones its neighbours produced, never its own.

While the cut is steady, that costs nothing. A neighbouring step cutting the same arc at the same chip load produces, at a given rotation angle, the same force this step would have produced, so the borrowed samples are extra data rather than extra error. The pairing turns into a systematic bias only where the cutter–workpiece engagement changes across the window — cutter entry, pass exit, corners, depth changes.

Measured on the D8 2-flute Al6061-T6 case (one source file at a 1 ms sampling period; only the training set and the CycleSamplingMode window vary):

training set window Fc error @ t=0.2 Fn error @ t=0.2 R
whole path (1076 cutting steps) SpindleCycle (default) −9.3 % −9.9 % 94.3 %
whole path FluteCycle −7.1 % −8.1 % 95.7 %
steady part only (~800 steps) SpindleCycle (default) −3.3 % −2.3 % 98.5 %
steady part only (~800 steps) FluteCycle −3.2 % −2.4 % 98.6 %

Two things to read off it. First, restricting training to the steady part is worth more than any other setting — here it more than halved the error, and did so at the coarsest sampling period. Second, once the transient is gone the window choice stops mattering (0.06 percentage points between the two modes, versus 2.2 on the whole path): FluteCycle's advantage on the whole path was only ever a shorter exposure to the entry and exit ramps. Keep the SpindleCycle default and its larger sample count.

In this case the transient was 272 of the 1076 cutting steps: the entry ramp, where the radial engagement builds from 0.09 mm to the nominal 2 mm, and the pass exit, where it climbs to 5 mm as the cutter runs off the far corner. Select the training section by requiring the engagement to be constant — CuttingWidth_mm and CuttingDepth_mm steady across neighbouring steps — rather than by eyeballing the toolpath.

Note

Gaps in the sensor data are handled. A step whose pairing window contains no measured row — an acquisition dropout, or rows removed to keep the steady section only — is excluded from the mapping, and a single Map-ShotGap--StepsSkipped warning reports how many steps were skipped. A window-edge row is only interpolated when the rows bracketing the edge span at most two spindle revolutions; rows farther apart sit across a gap, and no value is fabricated from them. Watch for that warning after mapping measured data: a large count means the acquisition and the play do not overlap the way you think they do.

Warning

MachiningResolution_mm must not be too coarse for training: at 1/16 of the cutter diameter and coarser (D8 case: 0.0625 and 0.125), usable samples dropped by half and the phase pairing degraded badly — at 0.0625 it failed to recognise one of the six cutting passes outright, and coefficients came out wildly wrong (Fc −12 % to −33 %). Around 1/256 of the diameter (0.03125 here) the result saturates; refining further showed no benefit.


4. Run Simulation

PlayNcFile("NC/file1.nc");
Warning

During training, do not:

  • Adjust workpiece, tool, or controller resolution settings
  • Use the NC player reset button (close the project instead)
  • Save the project (system training configuration may overwrite tool resolution settings)

5. Export Simulation Data

Export step data and waveform data for analysis:

WriteStepFiles("Output/[NcName].step.csv");
WriteShotFiles("Output/[NcName].shot.csv", 0.1); // 2nd arg = sampling period in ms

The shot file contains time-resolved force columns: Tool.Fx/Fy/Fz, Workpiece.Fx/Fy/Fz, Spindle.Mx/My/Mz.

⚠ The shot sampling period is the dominant accuracy lever

The second argument of WriteShotFiles is the sampling period in milliseconds, 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 min(MillingCycleDivisionNum, samples per revolution), where

samples per revolution = 60000 / (rpm × samplingPeriod_ms)

Measured on the same case (2-flute D8, Al6061-T6, MachiningResolution_mm 0.03125, S1270 → one revolution = 47.2 ms):

sampling period samples / rev R Fc error @ t=0.2 Fn error @ t=0.2
1 ms 47 94.2 % −9.3 % −9.9 %
0.1 ms 472 95.2 % −6.6 % −6.1 %

At 1 ms the waveform is sampled only ~47×/rev, and raising MillingCycleDivisionNum from 180 to 720 changes nothing because the extra grid points are pure interpolation of the same data. Pick the sampling period first: for training on simulated data use a period at or below the division period (60000 / (rpm × MillingCycleDivisionNum) ms); when comparing against a real measurement, match the sampling period to the physical DAQ rate, otherwise the two sides carry different information densities and the comparison is biased.

Note

A fine period makes large files — the case above went from 13 MB at 1 ms to 128 MB at 0.1 ms for a 6-cut program. Budget disk accordingly, and do not commit such files to a repository.

For coordinate system explanations, see Milling Physics Coordinates.


6. Train Milling Parameters

TrainMillingPara (New Training)

TrainMillingPara trains new coefficients independently of any existing workpiece parameters.

TrainMillingPara(Fx|Fy|Fz, "StainlessSteel.mp");

ReTrainMillingPara (Calibration)

ReTrainMillingPara calibrates existing coefficients (10% original weight, 90% new sample weight).

ReTrainMillingPara(Fz|Mx|My|Mz, "StainlessSteel.mp");

Sample Flag Requirements

Command Minimum Data Types Feed Per Tooth Requirement
TrainMillingPara Fx\|Fy\|Fz (dynamometer) or Fz\|Mx\|My\|Mz (smart tool holder) At least one sample with different feed per tooth
ReTrainMillingPara No restriction No restriction
Warning

Using only Mx|My|Mz without Fz loses one degree of freedom (torque = r × F loses the r-direction), making coefficient training unreliable. Always include Fz when using torque data.

Training Conditions

  • Samples should have stable, repeatable waveforms for at least two spindle revolutions
  • Under unstable conditions, plowing coefficients tend to be over-estimated
  • Any NC path shape (slot milling, side milling, any tool shape) is acceptable when samples are stable

7. Evaluate Training Quality

After training, the system reports three quality metrics:

Correlation Coefficient (R)

A single value for the overall result. Ranges from 0 to 1; for new tools, expect 0.95–0.999.

Training Error Ratio (TrainingErrRatio)

A per-step variable registered automatically after training. Lower values indicate better step-level quality:

\[ \text{TrainingErrRatio} = \sqrt{\frac{\sum_{i} e_i^2}{\sqrt{\sum_{i} y_i^2 \cdot \sum_{i} \hat{y}_i^2}}} \]

Angle Offset (AngleOffset)

A per-step variable representing the cutter rotation phase difference between measured and simulated data:

\[ \theta_{offset} = \frac{2\pi \cdot i_{min}}{N_{div}} \]
Tip

If AngleOffset varies significantly across segments in the same training batch, the spindle may have experienced speed changes, data gaps, or the system could not accurately analyze the samples.


8. Load Trained Parameters

After training, load the new coefficients into the workpiece:

LoadCuttingParaByFile("StainlessSteel.mp");
Warning

If the training output file path is the same as the tool's existing cutting parameter file, reload the project after training to ensure the new parameters take effect.


XML Configuration (GUI Workflow)

When using the GUI-based training workflow, configure the .hincproj file:

<MillingParaGridTrainingDestinationFile>MillingPara/trainedPara.mp</MillingParaGridTrainingDestinationFile>

<MillingParaTraining>
  <IsMzEnabled>false</IsMzEnabled>
  <ForceOutlierRatio>2</ForceOutlierRatio>
  <LeadParaTemplate>
    <RakeFaceCuttingParaMap>
      <FluteFormNum>1</FluteFormNum>
      <NAngleDivisionNum>0</NAngleDivisionNum>
      <EcAngleDivisionNum>0</EcAngleDivisionNum>
    </RakeFaceCuttingParaMap>
  </LeadParaTemplate>
  <ResultParaTemplate>
    <RakeFaceCuttingParaMap>
      <FluteFormNum>1</FluteFormNum>
      <NAngleDivisionNum>0</NAngleDivisionNum>
      <EcAngleDivisionNum>0</EcAngleDivisionNum>
    </RakeFaceCuttingParaMap>
  </ResultParaTemplate>
</MillingParaTraining>

Set IsMzEnabled to true if mapped data contains axial spindle torque from a smart tool holder.


Complete Script Example

MachiningResolution_mm = 0.0625;
EnablePhysics = true;
MillingCycleDivisionNum = 180; // training only; default 36 suits normal simulation, 720 buys nothing

ClearTimeMappingData();
AddTimeDataByFile("lineA", "Mapping/sensor1.csv", "18:25:51.7100", "18:26:12.9910");
AddTimeDataByFile("lineB", "Mapping/sensor1.csv", "18:26:30.5750", "18:27:12.2880");

PlayNcFile("NC/file1.nc");

TrainMillingPara(Fx|Fy|Fz, "MillingPara/trained.mp");
LoadCuttingParaByFile("MillingPara/trained.mp");

WriteStepFiles("Output/[NcName].step.csv");
WriteShotFiles("Output/[NcName].shot.csv", 0.1);

See Also