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. The exception is a step held up by a lower feed limit: a limit wins over the targets, so that step runs above them — see Bounding the Slow-Down of a Proven Program.

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.
Feed limits: The option's feed rate and feed-per-tooth bounds, the cutter's own limits and, when it is switched on, the source-feedrate floor. A lower limit wins over the physical quantity constraints, and over a maximum below it.

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

The optimizer holds each ratio in the table below at or under a target: the ratio's utilization factor, the reciprocal of its safety factor. A safety factor of 1.5 therefore targets about 67 % of the ratio's 100 % line, and a safety factor of 0, which reads as a utilization factor of infinity, adds no target. By default — the initial values of NcOptOption(API), which a session starts from, and of a freshly created cutter's optimization limit — the yielding stress, spindle torque and spindle power ratios are held under their 100 % line, and the thermal yield ratio is not held at all. In practice some metrics tolerate routine excursions and others don't. Raising a metric's utilization factor lets the optimizer accept higher peaks of it where physically safe.

Metric	Factor (API)	Default target	When to change
Yielding stress	YieldingUtilizationFactor on the cutter, OptYieldingUtilizationFactor on the session	1/3, about 33 %, from the cutter's safety factor of 3; the session's is 0	Per-instant. Safe to raise, on the cutter. If 150 % is routinely tolerated without breakage, set the cutter's factor to `1.5`. Controller corner smoothing and spindle inertia absorb a single-revolution overshoot.
Spindle torque	OptSpindleTorqueUtilizationFactor	1/1.5, about 67 %, from a safety factor of 1.5	Cumulative. Do not raise. Sustained excursions stall the spindle: feed continues, rpm drops, feed-per-tooth grows, forces spike further.
Spindle power	OptSpindlePowerUtilizationFactor	1/1.5, about 67 %, from a safety factor of 1.5	Cumulative. Do not raise. Same reason as torque.
Thermal yield	OptThermalYieldUtilizationFactor	None: the safety factor is 0	Long-term. A positive, finite factor makes it a target. Under a toolmaker's recommended conditions the ratio usually reads above 100 % until the tool material's thermal properties are calibrated, and a target under that reading slows those steps — see Thermal Plastic Deformation of Cutting Edge.

The yielding target is the one the session does not set alone. The cutter's optimization limit, MillingCutterOptLimit(API), carries a yielding safety factor of its own, YieldingSafetyFactor(API): 3 unless the cutter carries another. The larger of the cutter's and the session's applies, so the session's factor can lower the yielding target below the cutter's but not raise it above, and the yielding stress ratio drops out of the optimization only when both are 0.

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.

Bounding the Slow-Down of a Proven Program

A program that already runs in production is usually optimized to spare the tool, and its cycle time is already planned around. EnableSourceFeedrateFloor (API) floors every step's optimized feed rate at SourceFeedrateFloorRatio (API) of the feed rate the source program commanded on that step. The bound is relative to each step's own feed, which the absolute MinFeedrate_mmdmin (API) and MinFeedPerTooth_mm (API) cannot express.

The share trades tool life against cycle time:

Share	What the optimizer may do	Tool	Cycle time
Below 100 % (80 % by default)	Slow a peak-load step down to the share; speed any step up	The lowered peaks are the tool-life gain	May grow, but no step runs slower than the share of its source feed
100 %	Only speed steps up	No step is relieved, so there is no tool-life gain	Does not grow

Cycle time here is the ideal-feed time of Machining Time Estimation. Both bounds hold to within FeedrateAssignmentRatio (API), 1 % by default: a line whose new feed differs from the feed written before it by no more than that ratio keeps the earlier feed rather than stating its own.

Like every lower limit, the floor wins over the force and safety targets. A step it holds up runs above the load a target asked for, and the run says so once, with the warning NcOpt-Feed--SourceFloorOverTarget counting those steps per target — preferred force, yielding, thermal yield, spindle torque, spindle power and custom criteria. On every step where the floor lies above the other lower limits, the per-step log states it as FrtBySourceFeedrateFloor_mm, and a criterion equal to it is one the floor held up; see Optimization Logs.

The floor acts only while feed rate optimization is on, and only on the SoftNc runner, the default. A stretch with no cutting within the extended distances, which the optimizer sends at the option's rapid feed, is floored the same way. The switch is off by default, and a project file that does not carry it reads it as off.

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 — at most twenty of them in a run, after which only the summary is kept;
one Warning at the end of the per-step solve, before its closing row (only the source-feedrate floor's warning, when it fires, comes between them), 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. After Optimization Feedrate built. the run carries on through the stages after the solve, so a pass that reported failures still produces optimized files; after Optimization Feed Process canceled. it ends on optimization canceled. and Total 0 files optimized. Neither of those two rows having appeared yet means the solve is still working, not that it gave up.

A Stop during the per-step solve 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 source-feedrate floor when it is on, 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. The source-feedrate share is not part of that refusal: a share that does not give a positive, finite floor sets no floor on the step.

Table of Contents