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:
Angle Offset (AngleOffset)
A per-step variable representing the cutter rotation phase difference between measured and simulated data:
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
- Milling Physics Coordinates — coordinate system reference
- Sensor Mapping Workflow — detailed mapping workflow
- Workflow: Basic Machining Simulation — basic simulation setup
- Workflow: NC Optimization — optimization after training
- Step — step data reference
- Glossary: SessionShell Quick-Reference — SessionShell quick-reference
- Training with a Dynamometer (Example)
- Cascading Mapping (Example)