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 a time column and at least one force/torque channel. Each channel accepts more than one spelling, so a file written for an older release still reads:

Source Headers
Time ActualTime, or ActualDateTime for the absolute instant. TimeTag and Time are read for compatibility with older files.
Dynamometer Fx or Workpiece.Fx (same for y, z)
Smart tool holder Mx or Holder.Mx (same for y, z). Spindle.Mx is an obsolete spelling, read but not written.
Accelerometer (optional) Ax, Ay, Az — one spelling only 
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 opens with FileNo, LineNo, Time and the mission's M-codes, then carries the time-resolved force columns: Tool.Fx/Fy/Fz, Workpiece.Fx/Fy/Fz, Holder.Mx/My/Mz — the same holder spelling the reader writes, not the obsolete Spindle.M*. A play driven from a controller CSV appends ActualDateTime; an NC-simulated play has no controller instant to stamp and omits that column.

⚠ 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.

The feed-per-tooth entry above is what the command refuses to run without, not what a usable training needs. One sample at a different feed satisfies it; separating the shear coefficients from the ploughing ones takes a range of chip loads across the passes.

Training Conditions

  • Samples should have stable, repeatable waveforms for at least two spindle revolutions
  • Under unstable conditions, plowing coefficients tend to be over-estimated
  • Stable samples are necessary and not sufficient. Whether the coefficients can be recovered from a cut set at all is decided by what that set spans, not by how clean it is: a set with one helix angle leaves a combination of the shear coefficients exactly unobservable, and a set with a narrow feed-per-tooth range cannot separate shear from ploughing. Design the set before cutting — see Designing a Training Cut Set

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.

R measures waveform agreement after phase alignment, and does not rank the coefficients that produced it. A cut set that leaves a coefficient combination unobservable still reports R above 0.95, over shear values orders of magnitude too large; and between two runs on the same data, the one whose coefficients are closest to the truth can be the one with the lower R, because an exact step-to-shot pairing window scores lower than a window wide enough to smear the waveform. Read R as a floor the data has to clear, then judge the run by the force it reproduces over time. What the set can determine at all is fixed before cutting — see Designing a Training Cut Set.

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