NC Optimization

Also refer to the script commands section Workflow: NC Optimization.

Optimization Objective

Optimization aims to make the physical quantities during machining as close to the target values as possible.

Since the optimization uses a conservative feed rate strategy, the physical quantities in the optimized NC code will be as close to equal to or less than the target values as possible.

Factors Determining the Optimized Feed Rate

The optimized feed rate is determined by:

Physical quantity constraints of individual steps: Feed rate limits calculated for each step based on target force, yielding stress, spindle torque, etc. For detailed descriptions of indicators such as yielding stress ratio and spindle torque ratio, refer to "Evaluating Process Machinability".
Inter-step smoothing: Interactions such as acceleration/deceleration limits and extended distances.

Differences in Simulation Results After Optimization

Simulation with modified feed rates produces different interpolation points than before, resulting in:

Different simulation mesh errors
Surface morphology changes at the surface roughness level

Therefore, the simulated physical quantities after optimization may not always be equal to or below the target values — they may also be slightly above.

The influence of interpolation point density on surface morphology is greater at rounded corners than on straight lines, so this effect may be more pronounced at corners.

Tip

For abnormally low optimized feed rates at corners, refer to Corner Feed Rate Optimization.

Velocity Smoothing

The smoothing range terminates at macro commands or line commands with unresolvable paths.

Velocity smoothing applies acceleration/deceleration limits based on the path length traversed by the current line command. Therefore, velocity smoothing is effective for re-interpolatable regions; however, for non-re-interpolatable regions, although acceleration/deceleration limits still apply, the excessively long path length of a single line may render them impractical in actual use.

Impact of Geometric Errors

Current NC optimization is based on an ideal geometric model. If the workpiece is a casting or has installation errors, a conservatively larger workpiece geometry should be configured in the system to prevent the system from misidentifying cutting regions as non-cutting regions, which could cause tool crashes.

Tool Breakage Solutions

Modify the toolpath to reduce cutting width/depth, or use HiNC's optimization feature to adjust feed rates, bringing the yielding stress ratio, max spindle torque ratio, and max spindle power ratio below 100%.

For detailed descriptions of these indicators and tool breakage criteria, refer to "Evaluating Process Machinability".

Tuning Peak Tolerance

Optimization defaults treat the 100 % line on every ratio as a hard ceiling. In practice some metrics tolerate routine excursions and others don't. The per-metric Opt*UtilizationFactor levers let the optimizer accept higher peaks where physically safe.

Metric	Factor (API)	When to raise
Yielding stress	OptYieldingUtilizationFactor	Per-instant. Safe to raise. If 150 % is routinely tolerated without breakage, set `1.5`. Controller corner smoothing and spindle inertia absorb a single-revolution overshoot.
Spindle torque	OptSpindleTorqueUtilizationFactor	Cumulative. Keep at 1. Sustained excursions stall the spindle: feed continues, rpm drops, feed-per-tooth grows, forces spike further.
Spindle power	OptSpindlePowerUtilizationFactor	Cumulative. Keep at 1. Same reason as torque.
Thermal yield	OptThermalYieldUtilizationFactor	Long-term. Can be raised modestly if the calibrated tool material is more thermally tolerant than the conservative defaults — see Thermal Plastic Deformation of Cutting Edge.

Rule of thumb: relax per-instant per-step metrics based on observed stable extremes; never relax cumulative metrics.

For a complementary feed-rate floor lever — useful when the NC cannot be modified to remove single-revolution peaks — see MinFeedPerTooth_mm (API) and When the NC Cannot Be Modified.

Thermal Edge Chipping Solutions

After addressing tool breakage issues, reduce the spindle speed to allow sufficient time for the cutting edge to dissipate heat.

Note that whether the coolant is properly directed at the cutting edge has a significant impact.

Tracking Physical Quantity Constraints of Individual Steps

Every optimization already writes the per-step log — one .IndependentStepAdjustment.log beside each optimized NC file that had steps to solve — so nothing has to be switched on to obtain it. What that log cannot answer on its own is which physical quantity limited an individual step, because smoothing carries neighbouring steps into the feed it records. Disable the smoothing settings before the run:

OptMaxAcceleration_mmds2 = double.PositiveInfinity;
OptFeedrateAssignmentRatio = 0;
OptExtendedPreDistance_mm = 0;
OptExtendedPostDistance_mm = 0;

After running the optimization, inspect the .IndependentStepAdjustment.log file to view the independent optimization calculation results for each step and identify which physical quantity limited the feed rate.

For detailed field descriptions of the log file, refer to the Optimization Logs section in the Workflow: NC Optimization workflow.

When a Step Cannot Be Solved

A step whose solve fails does not stop the optimization. That step keeps the feed rate the simulation ran it at instead of a solved one, and every other step is optimized as usual, so a completed optimization can contain steps no physical criterion ever set the feed of. Three records name them:

an Error message per failed step, carrying the step index, the NC file and line, and the underlying exception — the first twenty failures of a run, after which only the summary is kept;
one Warning at the end of the pass, giving the number of failed steps and the first of them;
a StepFailed row in that file's .IndependentStepAdjustment.log, in place of the step's usual per-criterion row.

What such a step does not keep is that feed all the way to the file. The stages after the solve treat it like any other step, constraining it against the extended segment and the acceleration limit, and where the step shares one feed word with the rest of its line, the value written is the lowest that line allowed. So the output NC marks nothing and the feed in it names nothing either: a failed step is indistinguishable in the file both from a step the optimizer had no reason to change and from one it had every reason to slow down. The messages are the only place that difference is stated, so read them before sending an optimized program to a machine.

Failures also do not shorten the pass. The per-step solve closes with exactly one row of its own in every run — Optimization Feedrate built. when it reached the end of the steps, Optimization Feed Process canceled. when Stop caught it first — and that row follows the failure summary rather than replacing it. The run then carries on through the stages after the solve. A pass that reported failures still produces optimized files, and neither of those two rows having appeared yet means the solve is still working, not that it gave up.

A run ended with Stop leaves the per-step log short. Its buffered tail is dropped rather than flushed, so the lines written since the last batch — batches go out at most once a second — never reach the file, and neither does any step line still held back waiting for a lower step index the stopped run never solved. A log that ends before the last step the run reached is the stop showing, not a gap in what the optimizer reports.

A NaN Feed Boundary Is Refused by Name

Each step's feed-per-tooth boundary is composed from the option's feed-rate limits and feed-per-tooth limits, the step's tooth-arc duration, and the cutter's own optimization limits. A boundary that comes out NaN is refused before the solver runs, and the message names the values it was given — MinFeedrate_mmdmin, MaxFeedrate_mmdmin, MinFeedPerTooth_mm, MaxFeedPerTooth_mm and the step's tooth-arc duration — because a NaN trial feed otherwise reaches the physics and is reported far from its cause. The usual source is a script writing NaN into the per-step option from a step event; see Script Commands.

Table of Contents