Recomputing a Finished Strip

A played strip stores, per step, the cutter–workpiece engagement the geometry produced. That engagement is the expensive half of a simulation and it does not depend on any physics input: a cutting parameter, a material, a coating layer, an ambient temperature, a spindle capability, a flute offset angle or a setup angle changes the numbers derived from the engagement, not the engagement itself. So a strip that is already on screen can be re-derived in place against the inputs as they are now — no reset, no replay, and the step indices, marks and selections the run left behind all stay where they are.

RecomputeStepPhysics is that operation. It is the answer to “what would this run have looked like with the other grade of carbide”, asked after the run rather than before it.

What a Recompute Costs, by What Changed

The scope is detected, not declared: the inputs recorded when each step was played are compared with the inputs now, and the comparison decides how deep the work goes.

An input edited during a play reaches the steps still to come only at a boundary — a tool's Setup Angle on its Clamping node at the next tool change or the next play start, a material or cutting parameter replaced on the workpiece (another file loaded, another object assigned) at the next play start, or at a recompute made while the play is paused unless the recompute is refused; until then the running play keeps computing with the value it started with. A value written inside the workpiece's material or cutting parameter object is the exception: the run holds those very objects, so the steps take a material value from the next step on, and a cutting parameter value from the next tool change, play start or recompute made while the play is paused (unless the recompute is refused). The strip can therefore carry more than one value of the same input, so the comparison is made against every value the steps were played with since the last completed recompute, not only the latest: whatever any step was computed with differently from now is recomputed. The workpiece's material and cutting parameter are recorded at every play start and every tool change, not at every step: a value written inside them and written back before the next of those or a recompute leaves no trace. An NC optimization run after the play on the SoftNc pipeline, the default, does not wait for a recompute: the forces it computes while solving the feeds take the tool and the values inside the cutting parameter as they are when it starts. On the deprecating HardNc optimization path an edit of the tool or of a value inside the cutting parameter made after the play reaches the optimization only from the next play start or a recompute that is not refused. On either path the stored results the optimization reads keep the played values until a recompute, and a cutting parameter replaced since the play reaches the whole optimization only from the next play start or a recompute that is not refused.

An environment input is not frozen that way: the play reads the ambient temperature, the coolant condition and the spindle capability on every step, so an edit reaches the steps that follow — the heat parameters and the dry-run power the spindle temperature takes for the current spindle speed included: a step issued after the edit takes them afresh from the capability of the moment instead of keeping those of the speed, while a step already in the pipeline keeps those and the ambient temperature it was issued with, and reads the capability's other values, the coolant's fields and the wear switch live. The session records the environment of every step, as the step is issued and again once its sequential physics is computed, so an input changed during a play and set back before the next play leaves its trace (an edit made and undone within one step's sequential computation aside): a recompute that finds any recorded value other than the current one reruns the chain from step 0.

What changed	What runs again	What it costs
Cutting parameter, flute geometry, flute offset or setup angle	The force kernel, on the touched steps	Milling-force licence steps, and the stored forces are rewritten
Cutter flute or shank material, a coating layer, the observation height, the integral mode, an insert cutter's insert thickness and insert mass, the exposed height, the inner and upper beam, a typed shank mass	The briefs, rebuilt from the stored forces	No force kernel, no licence steps
Workpiece material	The briefs, and the sequential chain from step 0	The thermal step reads the workpiece material on every step, air moves included
Environment, wider here than the tree's Environment branch — ambient temperature, coolant condition, the spindle capability, the initial spindle temperature, the wear switch	The sequential chain only, from step 0	No force kernel, no brief rebuild, no licence steps; the thermal step runs again on every step of the strip, also when only the spindle capability changed

Three consequences worth stating plainly:

Changing a material, a beam or an insert input does not move the force and moment charts. The forces were measured against the engagement and are kept; what such a change moves is temperature, wear, the yield-stress ratio, tip deflection and friction power. Look for the difference in the Color Index Time Chart's thermal quantities, not in Fx / Fy / Fz.
The sequential chain restarts at the changed tool's mount step, not at its first cutting step — the air moves approaching the cut carry the thermal state into it.
An edited spindle capability moves the spindle temperature and the two accumulated spindle energies. Those three are stored on each step as the program plays. The spindle meter power, the input power and the four spindle torque and power ratios read the capability whenever they are shown, so they follow an edit at once; the spindle working temperature ratio divides the stored temperature by the capability's working range, so it is right again only after the recompute. The recompute brings the stored three in line with the capability as it is now.

When a Replay Is Required Instead

Some changes invalidate the stored engagement itself, and the recompute refuses rather than producing a plausible wrong answer. StepPhysics-Recompute--NeedsReplay says so, and nothing is touched; the program must be replayed after ResetRuntime.

The cutter's shaper profile changed. A different envelope cuts a different volume.
The deflection transform is on and an input that moves the forces or the tip deflection changed — the cutting parameter, the flute geometry, a flute offset or setup angle, or a cutter input of the second row of the table above. The toolpath itself is then a function of the deflection, so the stored engagement no longer describes the cut. The tool-id form counts as such a change: with the transform on it always answers --NeedsReplay. A change of the workpiece material or of the environment alone, a spindle capability edit included, is still recomputed in place.
A touched step carries no stored engagement, because it was played with physics off.
No play-time inputs on record speak for a tool's steps (--InputsUnknown) — the session was begun after they were played, or the tool was never mounted through a tool change and the tool house has been given a tool of its number since. Nothing proves the stored engagements still describe that cutter. A session begun without a runtime reset — EndSession then BeginSession, from a script, over HTTP or from a C# host — keeps the steps the session before it played, and what it records as it plays speaks for its own steps alone: the steps it found stay unproven however much it plays, and --NeedsReplay names them. Reset the runtime, then replay.

The steps made under a tool number the tool house has no tool for, on which nothing of the cutting was computed, are left out instead — unless the session found them on the strip when it began, which, as above, need a runtime reset and a replay. The project's own tool, which HiNC counts as tool 0 until a tool change replaces it (with no tool 0 in the tool house, the usual case), and a tool a script or the API put in the spindle while the number in effect is one the tool house lacks, lend their steps no cutting force, cutter temperature or wear (the play says Step-Tool--NotInHouse), so there is nothing on them to recompute or to vouch for. The recompute answers for the other tools, and the sequential chain still runs those steps' spindle half: a strip of such steps alone answers --NoChange, or reruns the chain when the environment or the workpiece material changed; with the deflection transform on, a changed cutting parameter still answers --NeedsReplay. A tool the tool house held when its steps were played and has lost since is not left out: its steps need a replay. A tool a script or the API puts in the spindle after a change to a tool-house tool runs under that tool's number: its steps take that tool's values and are recomputed with it.

Distinct from that, --Refused names a failed precondition and also changes nothing: physics disabled, no steps, no cutting parameter for a change that needs the force kernel, or a milling-force licence with fewer steps left than the recompute would consume (--LicenceSteps reports both counts).

Running It

From a mission script or the console

RecomputeStepPhysics();     // let the change detection pick the scope
RecomputeStepPhysics(2);    // the force kernel on tool 2's steps only, whatever changed

The tool-id form is an explicit request: it restricts the force kernel and the brief rebuild to that tool's steps and reruns the force kernel on them even when the detection would have found nothing to do. The sequential chain is not restricted: it starts at that tool's mount step and passes every step after it, whatever its tool — at least through that tool's last cutting step, then on until its values meet the stored ones — and it runs from step 0 to the end when the environment or the workpiece material changed. What the tool-id form did not rebuild stays on record: another tool's edit, and a cutting parameter or workpiece material edit, are still found by the next no-argument recompute — which for a cutting parameter or workpiece material edit recomputes every tool's steps, the tool-id form's own tool included. Use it to force a rebuild you know is needed; use the no-argument form otherwise.

From the web application

The Recompute button on the Program row, beside Refresh. It is the one mutating action on an otherwise read-only branch, because it changes nothing but the run's own results. The button appears only while the Show Physics Options preference is on, and the footer carries the chunk progress the engine reports — about twenty updates per recompute.

Over HTTP

POST /api/SessionShell/RecomputeStepPhysics (optional toolId query parameter). The request blocks until the recompute has ended and answers with the run's messages inline; success is reported only for a completed recompute or a confirmed no-change. With nothing played since the last reset the route answers 409 — play first.

How It Shares the Player

The recompute runs on the player thread, so it never runs concurrently with a play.

Player idle. It runs as a one-shot. The status badge shows Running while it computes; Pause parks it at a chunk boundary and Stop cancels it there.
A mission running or paused on the player. It is queued for the play's next pace point and runs chunk by chunk, holding the play there until it has finished. Pause and Resume apply to it exactly as they do to the play, and a paused play is resumed for the recompute and paused again afterwards. A play that does not reach a pace point in time has the request withdrawn (--Busy; the wait is RecomputePacePointTimeout, 30 s by default).
An NC program being played on the session by another thread — a host's direct play request, which has the player idle while the strip still grows — is refused with --Busy. So is a second recompute while one is in flight.

A cancel keeps what it wrote: the reported step range carries the new values and the rest keeps the previous ones, and --Canceled says so. Run the recompute again to finish: it starts over from where the chain starts for the change — the steps already rewritten are computed again, through the force kernel where the change needs it, which consumes its licence steps again — and does not take the cancelled run's boundary as converged. The inputs the cancelled run wrote with stay on record beside the earlier ones, so an input set back to its earlier value afterwards is still recomputed.

A recompute ended by an error after it wrote — the step store or the message channel failing inside a chunk, or the player's own pace point failing between two chunks — keeps what it wrote the same way. The chunks it had committed carry the new values and the rest keeps the previous ones; --Fault names the error and, ahead of it, --FaultKeptRange names the replaced range; the inputs it wrote with stay on record beside the earlier ones; and StepPhysicsRecomputed reports the range, as after a cancel. The request answers Canceled over that range — not a success, over HTTP as in the application — and nothing is rolled back. Run the recompute again to finish: it starts over from where the chain starts for the change, exactly as after a cancel. An error before the first chunk was written changes nothing and answers Refused. The direct call from a mission script or the console throws the error instead of answering — without the two messages — after the same bookkeeping: the range kept and reported, the inputs on record.

Reading the Result

--Done reports the step range whose results were replaced, how many steps went through the force kernel, how many briefs were rebuilt without it, and how many steps of the sequential chain were recomputed. --NoChange means no physics input differs from what the steps were last computed with — by the play, or by a recompute since — and nothing was touched. With a tool id the message is --NoChangeForTool and speaks of that tool alone: the tool has no step to recompute, and the environment and the workpiece material are as recorded. A tool id no step carries, whether the tool house has it or not, gets the same answer, not --InputsUnknown, and so does the tool id of steps left out as above: no stored engagement of that tool needs vouching for. The other tools' steps were not looked at; the no-argument form answers for them.

Four warnings are worth acting on rather than dismissing:

--ThermalSkipped — a tool in the recomputed range has no runnable thermal model (missing material curves, a non-milling cutter, no workpiece material, a material whose thermal constants are not given, or no coolant condition). Its temperature and wear keep their previous values while everything else is recomputed, so the chart mixes old and new for that tool.
--LuggageMissing / --StepsMissing — steps in the range with no stored luggage row or no machining step; the chain passes through them on zero contact, or on the previous step's motion.
--StepFaulted — steps that threw during the recompute keep their previous values. The message names the first one and its reason. The run still counts as completed, so running the recompute again answers --NoChange; to retry those steps, use the tool-id form for their tool, or replay.
--ChainWarning — the chain could not use an input as it stands on some steps and went on without it; the message says which. A spindle capability edit can bring this warning for five reasons, under four messages. Three leave steps without spindle limits, the last two under one message: the capability has no continuous power or torque contour (the message reads Continuous condition not set in Spindle Capability.), one of the contours the limits are read from — the continuous and the shortest-duration ones — has no points, or one of those two power contours has none on a step's side of the gear shift speed. On those steps the spindle temperature stays at the previous step's value and the spindle torque and power ratios of the steps that cut read NaN; where the contour without points is the longest-duration power contour, the steps on which the spindle turns have no meter power either and add nothing to the meter energy. With a contour without points, or without points on a step's side of the gear shift speed, a play takes those steps the same way — no spindle limits, the spindle temperature carried over, one step warning (Spindle-Limits--Unreadable) on the first step of a run of such steps — so a recompute of such a play leaves the chain as it found it, and the --ChainWarning follows an edit made after the play. The fourth reason keeps the limits and takes the heat model alone: the capability leaves nothing to derive it from at a step's spindle speed — the continuous or the shortest-duration power contour holds no power above zero on that speed's side of the gear shift speed, the energy efficiency is 0 or 1, the working temperature upper boundary is not above room temperature, or the shortest workable duration is 0 — and the spindle temperature is carried over on those steps, in a play as well, which says so in a step warning. With contours that start at speed 0 and no power, a gear shift speed of 0 does that to every step at speed 0. Correct the contours, the gear shift speed, the efficiency, the working temperature or the workable duration, and recompute again. The fifth keeps the heat model and says that its pace is not the capability's: the shortest-duration power contour holds no more power than the continuous one, or the capability has no finite-duration power contour, so the spindle temperature is computed but how fast it rises and falls does not come from the capability, and with the continuous contours alone it does not change; a play says the same in a step warning (Spindle-HeatCapacity--Underived). One more message under this id is about no input's value but its timing: an environment input edited while the recompute ran — at a chunk boundary where a Pause parked it, or from another client — reaches the chain from the next step it computes, so the steps before that step carry the earlier environment and the steps from it on the later one, both on record; the message says so, and the recompute run again brings every step to the environment of the moment.

Table of Contents