In July, Lockheed Martin set out its work on persistent identifiers: discreet digital tags that give a part’s individual features a unique, unchangeable identity, so that a hole and every specification associated with it can be tracked through design, machining, inspection and sustainment. Lockheed Martin partnered with Northrop Grumman, then extended the network to Sandvik Digital Manufacturing, Seco Tools, Mastercam, Verisurf, Metrologic DCS, Hexagon, Renishaw, InnovMetric, PTC, Siemens, Mazak and Datanomix, so that every tool in the value chain can publish and consume the same identifier.

Weeks earlier, Sandvik Coromant published results from the Dig4ReMan project with GKN Aerospace Engine Systems, Chalmers and the Fraunhofer-Chalmers Centre. That work applied STEP AP242 and AP238 to build a neutral, model-based language for geometry, product manufacturing information, machining instructions and tool data across the repair of damaged turbine blades. Mikael Hedlind’s framing was precise: the point was not really to repair parts, it was to prove that design, machining, simulation and inspection data can flow between organisations, because once everybody speaks the same language, collaboration gets faster and clearer.

Both are genuinely significant. Both invite a question.

None of this is new.

The standard is old enough to vote

ISO 10303-238 is not an emerging technology. The first edition arrived in 2007, the current edition dates from 2022, a further edition reached draft stage in May 2026, and the research literature reaches back further still. Suh published a shop-floor programming architecture for STEP-compliant CNC in 2003. Nguyen and Stark set out the system architecture differences for STEP-compliant control in 2009. Rauch’s group demonstrated over a decade ago how existing commercial controllers could be adapted to conform.

The validation work is equally old. In 2006, a joint Boeing and NIST effort published a portability validation of AP238 Conformance Class 1 for 5-axis machining, authored by Sid Venkatesh, David Odendahl, Xun Xu, John Michaloski, Fred Proctor and Thomas Kramer. Hardwick and Loffredo later documented lessons learned from implementing AP238 with four CAM vendors and two controls across two 5-axis machines of different axis configurations, interpreting a single AP238 file for both. In 2013 a roadmap for STEP-NC-enabled interoperable manufacturing was published with much the same cast, Odendahl among them.

Then there is a demonstration that deserves to be far better known than it is.

At IMTS 2014, Boeing built a baseline machining process for a titanium mould part and sent it to Sandvik Coromant and ISCAR to improve. A range of CAM systems were used. All communication happened in STEP-NC. The result was a single digital thread for the part, one STEP-NC description carrying all three process options alongside models for the part, rawpiece and tooling, cut daily on an Okuma control in the show hall via STEP Tools’ interface. The reported outcome was a 15 to 30 per cent improvement in machining time, and the stated reason was not a clever algorithm. It was that the digital thread made it much easier for Boeing to reach the tooling and process expertise sitting inside its suppliers.

Read that again. Collective intelligence, demonstrated on a machine tool, in public, twelve years ago. The tooling knowledge was the ingredient that made it work, and the thread was what made the knowledge reachable.

David Odendahl has been pushing this at Boeing for the better part of two decades. And yet, in subtractive manufacturing, the digital thread still has not reached technological maturity. Only a small number of machine tool OEMs have developed STEP-enabled technology at all. The overwhelming majority of metal in the world is still cut from ISO 6983 G-code, which carries coordinates, feeds, speeds and a tolerance band, and none of the contextual information that would tell a machine what the feature is or why it matters.

So before anyone gets excited about a new capability, the honest question is why it did not take, and what is actually different now.

Why it stalled

I have some skin in this. Several years ago, at the AMRC we investigated how to get contextual information via STEP-NC onto Siemens controllers, and we spoke at length with Boeing about it at the time. The obstacles we hit were almost entirely structural rather than technical.

The chicken and egg problem is real, and it is nobody’s fault. No manufacturer will restructure a programming workflow around a standard their controllers cannot consume. No controller builder will fund consumption of a standard nobody is sending them. Both positions are individually rational and jointly fatal. This is precisely why Rauch’s adaptation work and STEP Tools’ controller interfaces mattered so much, and also why they remained demonstrations.

The post-processor is not a defect. It is a business. The received story is that the post-processor is legacy friction to be engineered away. In practice it is where machine-specific knowledge lives, and where builders, integrators and CAM vendors differentiate. STEP-NC proposes to move that knowledge into a neutral file anyone can read. Asking an industry to standardise away its own differentiation is a commercial request wearing a technical costume. 

Interpretation was the hard technical problem, and it is the interesting one. The reason a Boeing and NIST team had to formally validate that tool centre programming was portable across two 5-axis machines is that portability is not automatic. Hand the same feature description to two controllers and you get two different cuts, because each interprets it through its own kinematics, drive limits and smoothing algorithms. G-code has the perverse virtue of failing predictably: it is machine-specific by construction, so nobody is surprised. A neutral file promises portability, and then the machine has the last word anyway.

It belongs to nobody. STEP-NC sits between CAD, CAM, controller, tooling and metrology. No single budget owns all five, so it lands in the gap between them, which is where good standards go to be admired.

Which makes the most interesting recent development in this space not a standards committee at all. In 2023 ModuleWorks stopped waiting and published MDES, the Manufacturing Data Exchange Specification, as a free and open format for describing manufacturing equipment: tool components, assemblies, fixtures, stocks, setups and how they mount in the machine, aligned with existing standards including ISO 13399. Autodesk and DN Solutions adopted it almost immediately, followed by PTC, SolidCAM, CHIRON, Cimsource and BobCAD-CAM. Yavuz Murtezaoglu’s stated reasoning was refreshingly commercial: everyone was paying to build and maintain custom bridges between systems, and a shared description removes that cost for all of them.

Two years of adoption against twenty is a result worth sitting with. It suggests the route through this problem may be a vendor with something to lose publishing an open specification and giving it away, rather than a committee producing a superior one and waiting to be adopted. Not because the engineering is better. Because somebody owned it.

What actually changed

Model-based definition stopped being an aspiration and became a procurement requirement. When primes tag features with persistent identifiers and expect the supply chain to consume them, carrying that richness downstream is no longer voluntary.

Everyone is building AI assistants on manufacturing data, and discovering the assistant is only as good as the structure underneath it. A copilot that can read a tolerance is worth considerably more than one that can read a coordinate.

And, bluntly, consolidation. In 2014 that IMTS demonstration required Boeing, Okuma, Sandvik Coromant, ISCAR and STEP Tools to align. Today a very large portion of that chain, CAD, CAM, post-processors, cutting tools and metrology, sits inside a handful of groups rather than dozens of companies. The coordination problem that stalled STEP-NC adoption for twenty years has become, in places, an internal roadmap question rather than an industry negotiation.

It’s all about context

The digital thread has become genuinely good at carrying three kinds of information down to the machine tool.

Identity is which feature this is. That is what a persistent identifier contributes, and it is the newest of the three.

Intent is what the designer requires of that feature. The tolerance, the finish, the datum scheme, the reason it matters.

Context is everything a machine needs to know in order to act on the first two: the machining type, the toolpath geometry, the tool and the rawpiece, and what a stated tolerance actually means for this operation rather than in the abstract. This is the layer STEP-NC was built to carry and the layer G-code structurally cannot. Strip context out and a tolerance is just a number in a header.

MDES is worth looking at again here, because it is the clearest evidence that the industry has recognised the context gap and is actively closing it. It describes the equipment side in detail: what tool is in which holder, in which fixture, mounted where, against which stock. That is real context and it removes real setup error. And it stops exactly where every description of a machine stops. It tells you precisely what is on the machine. It does not tell you what the machine will do.

Get all three onto the shop floor and a feature arrives tagged, toleranced and fully described in its own terms. That is a real achievement, and it is what twenty years of standards work bought.

What none of the three can tell you is behaviour. Nothing upstream of the controller knows what that particular machine will actually do when handed that particular feature.

And the reason is important, because it explains why two decades of excellent file format work never closed this gap. Identity, intent and context are all properties of the part. They can be written down, which is exactly why a standard can carry them. Behaviour is a property of the machine. It is not information about the part at all, so no file can hold it. It has to be computed, per machine, before the cut.

A part program is a sequence of coordinates and a commanded feedrate. It is not a statement of what will happen. The numerical control kernel interpolates that sequence into axial reference trajectories subject to drive limits, jerk and acceleration settings, smoothing configuration and the blending tolerance active at that moment. CAM models none of this. It integrates length over commanded feedrate and reports a number, and on real aerospace features the gap between that number and the machine is routinely measured in minutes rather than seconds.

So you can pass a feature-level tolerance from design to controller with perfect fidelity and still have no idea, at the point of programming, what it will cost or whether the machine can hold it. Continuity of identity, without continuity of physics. And a closed loop needs both, because measurement tells you what happened, and you cannot close a loop without knowing what should have happened. That is a forward model, and it has to run before the cut.

Using the richness already in the standard

We have been advocates of the benefits of STEP-NC for many years. Our CTO and I published research at HSM 2025 in Metz with Burak Sencer of Oregon State: Digital thread enabled time optimal trajectory generation for machining toolpaths.

It proposes no new standard. It uses the richness already sitting in the one we have. A STEP-NC polyline command is enriched with an explicit instruction to the interpolator, alongside the feature’s own geometric tolerance, straightness on an external profile, say, or cylindricity on a suitable three-dimensional feature. In other words, the contextual layer is used for what it was designed for: telling the machine not just where to go, but what kind of cut this is and how much room it has. Trajectory generation is then posed as a constrained optimisation in which every individual cutter line carries its own tolerance and its own objective. Position tolerance becomes a convex region around each nominal cutter line, rather than a single global setting buried in a cycle definition.

Benchmarked on-machine against a Hermle C52 with a Siemens 840D SL, the method delivered cycle time reductions of up to 14.4 per cent, with every trial landing within 0.1 per cent of the specified tool centre point tolerance.

To be clear about what that number is and is not: the 2014 demonstration’s 15 to 30 per cent came from human experts reworking a process once they could see it. This 14.4 per cent comes from the interpolation stage alone, on an unchanged process, using information the standard was already capable of carrying. The two are additive, not competing.

Tolerance is not a constraint on productivity. It is the lever. And because it can be set per cutter line, it can be spent where the drawing allows and held where it does not. On the same trochoidal path we also swapped the secondary objective between minimum time, minimum acceleration and minimum jerk, which is to say the same feature can be asked for the fastest cut, the smoothest cut or the lowest-energy cut, and the answer genuinely differs.

That is what altering specific points in a toolpath actually means once machine behaviour sits inside the model. Not a global smoothing slider. Feature-by-feature control, driven by the tolerance the designer specified, which is exactly the information a persistent identifier or an AP242 model already carries down the thread.

So, are we ready?

Twenty years of standards work has gone into getting the right information to the machine, and it worked. Identity, intent and context now travel the full length of the thread, which is more than anyone could say five years ago.

None of it tells you what will happen. A persistent identifier can carry precisely which tolerance applies to which feature, through every system in the chain, and still not tell you if the feature will pass or whether the machine standing on the floor can hold it. A common language lets the supply chain describe a feature exactly. It does not let anyone predict its conformance. Behaviour stops at the controller, because behaviour was never in the file.

The people who saw all of this in 2003 were not wrong. They were early, and they were short of several pieces. I think finally all the pieces are coming together. 

About the author. Dr Rob Ward is CEO and Co-Founder of DigitalCNC, a University of Sheffield AMRC spinout building deterministic, physics-based machining prediction inside CAM.

Sources and further reading

• Lockheed Martin, “Enabling a New Level of Precision in a Model-Based Enterprise”, July 2026
• Sandvik Coromant and the Dig4ReMan project, reported in Zerspanungstechnik.de, July 2026
• STEP Tools, “CAM Data Exchange on the Digital Thread using STEP-NC Demonstrated at IMTS 2014”
• S. Venkatesh, D. Odendahl, X. Xu, J. Michaloski, F. Proctor and T. Kramer, “Validating Portability of STEP-NC Tool Center Programming”, ASME IDETC/CIE, 2006
• M. Hardwick et al., “A Roadmap for STEP-NC-Enabled Interoperable Manufacturing”, International Journal of Advanced Manufacturing Technology 68, 2013
• D. Wilkinson, B. Sencer and R. Ward, “Digital thread enabled time optimal trajectory generation for machining toolpaths”, MM Science Journal, Special Issue HSM 2025, Metz, October 2025. DOI 10.17973/MMSJ.2025_11_2025140

CAM Said 1:05. The Machine Said 6:27. 

How DigitalCNC caught a five-minute-per-pocket error on an unproven aluminium bulkhead rib, before any metal was cut. 

A new STEP file drops into the folder. A large aluminium bulkhead rib — bespoke, with no past program data or cutting history to lean on. Somewhere in it sits a 60 mm-deep, thin-walled roughing pocket headed for a gantry mill with an 80 kW HSK-63 spindle rated to 30,000 rpm. Plenty of power, but torque falls away hard above 18,000 rpm, and that is the constraint that decides which roughing strategy is actually available to you.

When aluminium roughing fails on an HSK-63 spindle at high surface speeds, it rarely wears out the insert or end mill gently. Built-up edge packs the flutes, welds material back onto the cutter, and causes catastrophic cutter fracture. On a high-speed spindle cartridge, that fracture takes out the toolholder, workpiece, and spindle bearings in milliseconds.

On an unproven part, finding the fastest safe toolpath strategy normally requires air-cutting, riding the feed override knob, or burning a test billet. This is how that decision moved entirely off the shop floor and onto the desk during a single afternoon.

Defining Feedrate Efficiency

Before examining the numbers, one term needs defining – efficiency. When DigitalCNC measures efficiency, it calculates the percentage of cycle time spent at or above 80% of the programmed feedrate.

A low efficiency percentage points to a path where the CNC controller spends the cut decelerating: throttling back for high-density G-code points, managing corner look-ahead limits, or struggling with servo acceleration, never reaching the feedrate commanded in the CAM program. 

The part: a large aluminium bulkhead rib, with the 60 mm-deep thin-walled roughing pocket under review.

The Initial Toolpath Selection

The tooling data offered two viable strategies at similar theoretical metal removal rates (MRR):

• A three-flute traditional offset approach using low axial depth of cut (ap) and high radial engagement (ae).
• A four-flute dynamic trochoidal approach using low ae and full axial depth (ap) at a lower torque load.

The trochoidal option looked like the safer bet, and on tool life grounds it was: 2 mm radial engagement, no corner spikes, and none of the sudden torque demand that snaps a long-reach cutter in a 60 mm pocket.

The CAM cycle time estimate reinforced that choice. The dynamic path posted at 1:05 against 0:50 for the traditional offset area-mill path — a 15-second difference per pocket. On a high-RPM spindle and an unproven part, choosing the dynamic path was a sound engineering call based on the data available at the desk.

The Actual Machine Response

Running the posted G-code through a kinematic model of the specific machine (accounting for controller parameters such as look-ahead, acceleration/deceleration limits, and machining tolerance) fundamentally changed the output.

DigitalCNC calculated the actual run time for the dynamic path at 6:27 with an efficiency rating of 24%.

Kinematic analysis of the dynamic path. Red segments indicate where actual feedrate drops below 80% of programmed feed. 

Point spacing on that trochoidal path averaged 0.4 mm. At a commanded feedrate of 6,000 mm/min, the CNC control must process 250 blocks per second. Look-ahead effects and kinematic constraints throttled the feedrate: the control could not process the point-dense stream and plan the direction changes within tolerance while still holding the commanded feed. The controller spent 76% of the motion cycle slowing down through the interpolated toolpath.  

Feedrate (solid blue) plotted against commanded feed (dashed ceiling) over time. 

CAM software assumes linear movement at full programmed feed. On complex point-dense paths, that assumption can introduce a 20–40% error window. In which case, block-processing bottlenecks can turn the conservative toolpath into the slowest option on the machine.

Optimisation Cycle

Using the kinematic model to re-simulate changes instantly on the programmers laptop allowed for targeted path adjustments before posting code to the floor:

1. Ramp Geometry: Replacing the tight helical entry with a form ramp matching the pocket geometry maintained drive motion and reduced entry cycle time, bringing overall time from 6:27 down to 4:50.
2. Post Processor Arcs: Analysing feed dips in the entry revealed the post processor was emitting tiny 3D linear segments instead of arc commands. Forcing true G02/G03 arc output cleaned up the execution stream, dropping time to 4:41.
3. Control Tolerance: Opening the high-speed machining tolerance from 25 µm to 60 µm on this roughing operation allowed the look-ahead algorithm to smooth vector transitions, bringing time down to 4:19.

Re-simulated dynamic strategy following ramp geometry, arc output, and tolerance changes. 

Feedrate plot with dynamic strategy following ramp geometry, arc output, and tolerance changes. 

These three edits saved 2 minutes and 8 seconds on a single pocket. Across a structural rib with dozens of internal cavities, that minor adjustment scales rapidly: turning minutes into hours of recovered machine time on every part, and compound savings into hundreds of thousands of pounds across the entire programme.

Analysing the Offset Path

The traditional offset path presented a different constraint. Out of the box, it posted at an actual execution time of 1:31 at 42% efficiency. However, the feedrate and chip load analysis highlighted a severe mechanical risk.

At internal corners, maximum chip thickness dropped under 12 µm, below the edge radius of the cutter. At that point, the tool stops shearing metal and starts ploughing, creating extreme friction, and likely induced chatter right before the tool engages the heavy radial wedge in the corner. 

Original offset toolpath showing chip thickness collapse at sharp directional turns. 

Feedrate plot showing feedrate collapse at sharp directional turns

The toolpath was corrected through CAM parameters:

• High-speed profile and offset tolerances to round the corners, balancing rounding against stock left for the next operation (dialled from a deviation tolerance value of 5 down to 3). Note that even though an extra lap was addeedaround the pocket, the cycle time is still maintained due to the improved acceleration performance (1:26 over the original 1:31).

• Arc-fit rounding on the linking (out-of-cut) moves, killing the right-angle repositions that jar the guideways and leave dwells.

• Platform tolerance opened to 60 µm.

Efficiency improved from 42% to 80%. Total run time changed negligibly (1:31 to 1:33) despite adding corner-rounding motion loops. Crucially, chip load was maintained above the 15 µm minimum threshold throughout the entire cutting pass, eliminating the rubbing action that leads to edge breakdown.

Corrected offset path with continuous corner radii and sustained minimum chip thickness. 

Feedrate plot with corrected offset path, continuous corner radii and sustained minimum chip thickness. 

Comparing the Unmodified Paths

The baseline CAM estimates placed the dynamic path at 1:05 and the offset path at 0:50 — a 15-second delta.

When run through the machine controller physics model, the actual times were 6:27 for dynamic and 1:31 for offset. The engineering rationale behind choosing dynamic was sound, but the CAM software lacked visibility into controller limits. The real-world difference between those choices was nearly five minutes per pocket.

Full Component Results

Applying these verified path strategies across the complete bulkhead program brought the overall machining efficiency to 85%.  No air-cuts were performed, no test scrap was produced, and no tooling was lost evaluating corner loads. 

Complete bulkhead rib toolpath optimised to 85% overall machine efficiency.  

What the Estimate Could Not See

Nothing in the original decision was wrong. Two strategies, similar theoretical MRR, one with clearly better tool life at 2 mm radial engagement in a 60 mm pocket. Every input available at the desk pointed at the trochoidal path.

What was missing was the machine. A CAM estimate is geometry divided by feedrate. It has no view of block throughput, look-ahead depth, drive acceleration, or the tolerance band the control is actually working to. On a point-dense path those omissions are not a rounding error. They inverted the answer.

Two strategies. One CAM cycle time reading fifteen seconds apart. Nearly five minutes apart on the machine. The whole call turned on a gap no CAM estimate could show, and it was closed in five clicks before anything reached the floor. No billet, no override knob, no afternoon of nerves.

That is one pocket. This rib has dozens.

The question is no longer which strategy looks fastest. It is whether the machine agrees.

Every CNC program contains two kinds of motion. There is motion that moves the part forward: cutting, finishing, roughing, profiling, drilling and trimming material into shape. Then there is motion that connects the useful work together: retracting, clearing clamps, moving between features, approaching the next cut and positioning safely from one area to another. Both are necessary, but they are not the same.

A machine can look busy while doing very little to the part. It can move quickly, sound productive, and still spend a surprising amount of the cycle travelling through air. That is why the split between rapid motion and feed motion is worth measuring.

The metric is simple: how much of the cycle is spent in rapid traverse compared with how much is spent in feed motion? In G-code terms, this is the difference between rapid moves such as G0 and feed moves such as G1, G2 or G3. In practical terms, it is the difference between repositioning the machine and progressing the part.

Rapid motion is not waste in the careless sense. Rapids exist because moving between cuts at cutting feed would be worse, and a good program needs safe linking moves, clearance moves and repositioning moves. But rapid motion is still overhead. It is time the machine spends getting ready to cut, moving away from a cut, or travelling to the next cut. It may be necessary, but it does not directly improve the part.

That is the point of the ratio. It gives a programmer, operator or production lead a way to see how much of the cycle is cutting work and how much is connecting tissue. Cycle time tells you what the program costs. The rapid-to-feed split starts to tell you why.

Why This Number Is Easy to Miss

The information is already sitting inside the program. Every motion block declares what kind of move it is, the controller knows whether it is in rapid or feed, and the NC file already contains the raw material needed to separate one from the other. No extra sensor is needed to start asking the question. No spindle load monitoring, no machine connectivity and no new hardware bolted to the side of the control.

At the simplest level, the program can be parsed and the motion blocks separated by mode. How many rapid moves are there? How many feed moves? How much distance is covered in each mode? That first view is useful, but it is not the whole truth.

A distance-based view can be misleading because rapid moves are normally much faster than cutting moves. A long rapid may cover a lot of distance but take very little time, while a short finishing move may cover almost no distance but take much longer. Distance alone can therefore make rapids look worse than they are and make slow feed motion look better than it is. Block count has the same problem. A program may contain many short feed blocks on a freeform surface, or many short rapids between features, so counting blocks tells you something about program structure but not about the real cost.

Still, this first view is useful for spotting obvious problems. If a program contains hundreds of retracts to a high safe plane, or constant repositioning between scattered features, the structure will show up quickly. It may not give you the final answer, but it tells you where to look.

Measuring It More Honestly

The next level is time. Instead of counting blocks or measuring distance, each move can be converted into an estimated time, with feed moves timed using the programmed feed rate and rapid moves timed using the machine’s rapid traverse rate. That is closer to reality, and it is how a lot of cycle time estimating already works. But there are two big catches.

The first is rapid motion. A machine does not instantly reach its maximum rapid rate. On short rapid moves, the axis may spend most of the move accelerating and decelerating, and it may never get anywhere near the rapid rate printed in the machine specification. That means lots of short rapids can cost far more time than the numbers suggest. The expensive part is not always the distance; it is the repeated stop-start motion.

The second catch is feed motion. The machine does not always hold the programmed feed rate. Through dense geometry, tight changes of direction, small segments or five-axis movement, the controller may slow the machine down to stay within acceleration, jerk and axis limits. To the operator, this is familiar: the program says one feed, the control shows another. The machine is not disobeying the code; it is executing the code within the limits of the machine. This is the same behaviour that sits behind look-ahead and controller smoothing. The controller plans velocity across the geometry it can see, and where the geometry demands more than the machine can deliver, the controller resolves the conflict in favour of the machine. The programmed feed rate is a ceiling, not a promise.

So a time estimate based only on programmed feeds and headline rapid rates describes a machine that does not really exist. It assumes every rapid reaches full speed, every feed move holds programmed feed and every transition costs nothing. Real machines do not work like that.

The most honest rapid-to-feed ratio comes from execution-level timing: what the machine actually does with the program. That means real achieved feed rates, real acceleration behaviour, real transition time and real controller decisions. That information can be found in two places. One is after the job has run, by measuring what happened on the machine. The other is before the job runs, by simulating the program against the real kinematics of the specific machine and controller. The first method costs production time before the lesson is learned. The second gives the programmer and operator a better picture before the spindle turns.

The Blind Spot: Feed Motion Is Not Always Cutting

There is one more important point. Rapid versus feed is useful, but it is not the complete picture, because not every feed move is an in-cut move. Programs often contain feed moves where the tool is cutting air. Lead-ins, lead-outs, safety links, positioning moves output at feed, approach moves, and passes through material that has already been removed can all happen in feed mode.

This is where the simple rapid-to-feed split can flatter a program. A cycle may show a high feed-motion percentage, but some of that feed time may still be non-cutting time. The machine is moving slowly, but the tool is not doing useful work. That is the most expensive kind of air cutting: not rapid, not productive, just slow.

So the deeper metric is not only rapid versus feed. It is in-cut versus not-in-cut. Knowing the difference requires more than reading the code, because the code does not say where the material is. A feed move through air and a feed move through stock look identical in the program. Separating them means knowing the state of the stock at every point in the cycle, which is why this deeper split is harder to reach than the first one.

The rapid-to-feed ratio is the accessible first approximation. It is easy to understand and easy to start measuring. But the blind spot should be known from the start: some feed time is productive, and some feed time is just overhead wearing a better disguise.

Where the Time Usually Hides

Once you start looking for non-cutting time, certain areas show up again and again.

The first is retract strategy. Many programs retract to a safe plane after every feature, every pass or every reposition. That is often the conservative default, especially in templates built to avoid crashes across a wide range of setups. The problem is that every retract looks harmless on its own: one move up, one move across, one move down. But across a mature production program, those moves can happen hundreds of times, and together they can become one of the largest recoverable blocks of time in the cycle.

Minimum-retract linking can help where the part, fixture, clamps and tool length make it safe, and the key word is safe. A saved linking move is never worth a damaged cutter or a scrapped billet. But when a lower linking height is safe, the rapid-to-feed ratio gives you a way to measure the effect before and after. It turns “this feels better” into “this removed measurable overhead.”

The second hiding place is short rapid moves. Operators often notice long rapids because they are visible: the machine moves across the envelope and everyone can see it. But the expensive rapids are often the small ones. A program with many short hops may never let the machine reach full rapid speed, and each hop carries an acceleration and deceleration penalty. The machine is constantly starting, stopping, checking position and changing mode. That dead time does not always stand out when watching the program run, but it adds up.

The third area is mode transitions. Moving from rapid to feed, feed to rapid, or one controlled state to another can introduce small delays. Depending on the controller settings, exact-stop behaviour, tolerance mode and machine configuration, the machine may pause, settle or verify position before continuing. Each event is tiny, but a full program may contain thousands of them. This is why the instinct should not simply be to shorten the rapid distance. The better instinct is often to reduce unnecessary transitions.

The fourth area is sequencing. The order in which features are machined affects how much repositioning is needed, and two programs can cut the same features with the same tools and still have very different amounts of linking motion. Tool grouping matters too. Doing all sensible work for a tool before changing it can reduce tool change and repositioning overhead, and ordering features so the machine does not bounce around the part unnecessarily can reduce connecting moves. The ratio makes those choices measurable instead of habitual.

The fifth area is CAM strategy. Two toolpaths can produce the same surface and still carry very different amounts of overhead. One strategy may cut continuously with clean linking, while another constantly retracts, repositions and re-enters. On the screen, both may look acceptable. At the machine, one may carry a much larger non-cutting load. That is why strategy comparisons should not only look at stepover, feed, spindle speed and surface finish. They should also look at how much time the machine spends between useful cuts.

The Ratio Is Comparative, Not Universal

There is no perfect rapid-to-feed target. A roughing operation with many islands, clamps or deep pockets will naturally need more retracts than a continuous finishing pass. A five-axis trimming operation will behave differently from a drilling cycle, and a large aerospace structure will not have the same motion profile as a small prismatic bracket. So the number should not be used as a universal score.

Its strength is comparison. Compare two versions of the same program, two strategies for the same feature, the first posted version with the revised version, or last batch with this batch. When the geometry is broadly the same, changes in the ratio tell you something useful: whether the program has become more efficient, or whether time has simply moved around.

That is where the metric becomes practical. It helps answer questions operators and programmers already ask. Why did this cycle run longer than expected? Did the revised linking strategy actually save anything? Are we losing time in cutting, in air, or between cuts? Is the machine slow because the process is heavy, or because the program keeps sending it on errands? That last one matters more than people like to admit.

Why Operations Should Care Too

For operators, this ratio explains what is happening at the machine. For production and operations teams, it explains something bigger: how much capacity is already hiding inside the machines they own.

Spindle-on time is a common measure, but it is blunt. A machine can have the spindle running while cutting metal, trimming composite, moving through air, feeding into a lead-in, or repositioning safely above the job, and from a utilisation report those minutes may all look the same. They are not the same. The in-cut share of cycle time is a more honest process-level measure. It shows how much of the cycle is actually advancing the part and how much is overhead required to connect that work together.

That matters because capacity conversations often jump straight to capital expenditure. We need another machine. Maybe. But the first question should be: what are the current programs leaving on the table? If a facility can identify that a meaningful share of cycle time is non-cutting motion, some of that time may be recoverable through programming changes alone. Not all of it, because safe clearance, fixturing, tool changes and machine limits still exist. But some of it. And recovering time from existing programs is very different from buying another machine, hiring another shift, or accepting longer lead times.

The ratio also helps with quoting and process transfer. A decomposed cycle time is easier to defend than a single number, and if a quote is challenged, it helps to know whether the time sits in cutting, linking, tool changes, air moves or machine-limited motion. The same applies when work moves between machines. If a program is transferred and the cycle changes, the split helps explain why. Did the new machine lose time in rapid moves? Did the controller slow down in feed? Did the rotary axes become the bottleneck? Did transitions behave differently? A single cycle time cannot answer those questions. A decomposed cycle can. It gives programmers, operators and operations leads a shared number instead of three different opinions about the same lost minutes.

How Programs Should Be Evaluated

Cycle time is the number everyone tracks. The problem is that cycle time on its own is hard to improve, because it tells you the total cost of the program but not where the cost lives. The rapid-to-feed ratio starts the decomposition. The in-cut versus not-in-cut split completes it. Together, they turn cycle time from a single lump of minutes into something that can be understood and improved.

If a cycle runs over estimate, the question becomes clearer. Was the extra time in cutting? Was it in air cutting? Was it in rapid positioning or short transitions? Was it caused by the controller slowing through dense geometry, or by retract strategy, sequencing and toolpath structure? Those are useful questions because they point to action.

Producing that decomposition honestly requires knowing what the machine actually does with the program, since both rapid and feed timing are set by the machine and controller rather than by the values written in the code. At DigitalCNC, this is part of the problem we work on: modelling how a specific machine and controller will execute an NC program before it runs, so the programmer can see the real motion split before machine hours are spent.

Every programmer has watched a machine glide through a long reposition and felt the program was efficient because it looked busy. But being busy is not the same as being productive. The ratio replaces the feeling with a number. The machine has always known how much of the cycle was cutting. Now the programmer does too.

Most CNC operators have seen it happen. The program says one feed rate, and the machine runs something else.

You are watching the feed display through a finishing pass. The code looks fine, the programmed feed is steady, and the toolpath is clean. Then, as the cutter moves through a tight area, across a freeform surface, or into a region with lots of small direction changes, the machine quietly backs off. No alarm, no obvious mistake, no dramatic event. Just a feed rate that refuses to hold.

That behaviour is not random, and it is not the machine being cautious in some vague way. It is the controller doing one of its most important jobs: looking ahead in the program and deciding how fast the machine can actually move without exceeding its physical limits. That function is called look-ahead.

What the Controller Knows That CAM Does Not

CAM creates a toolpath from geometry. It outputs positions and feed rates, and in the program those feed rates can look simple: move from here to here at this speed. The machine has a harder job.

Every axis has mass. The table, spindle, head, rotary axes, ballscrews, motors and driven components cannot change speed or direction instantly. Any change in direction demands acceleration, and any fast change in acceleration creates jerk. Both are limited by the drives, the machine structure and the parameters set by the machine builder.

So while CAM may output a feed rate, the controller has to ask a different question: can the machine physically reach and maintain that feed rate through the motion that is coming next? That is why the programmed feed rate is not a promise. It is a limit. The controller can run up to that value where the motion allows it, but it will slow down where the geometry, axis limits or smoothing settings require it.

Look-ahead is the function that makes this possible. Instead of reading one line of code, moving, then reacting to the next line, the controller reads ahead through upcoming blocks. It studies the next section of motion and calculates a velocity profile that keeps the machine inside its acceleration and jerk limits.

Without look-ahead, the controller would have to treat every block transition as a possible stop. That would make complex finishing painfully slow and often unusable. With look-ahead, the controller can blend motion, maintain smoother feed and avoid unnecessary stopping. But there is a catch: the controller can only plan what it can see.

When the Toolpath Outruns the Planner

The controller’s look-ahead window is finite. It can only plan across the blocks it has read, stored and processed. If the program is made of long, simple moves, each block covers a useful amount of physical distance and the controller can see a reasonable distance ahead of the tool.

But finishing programs are often not like that. On freeform surfaces, especially in aerospace work, the toolpath may be made from thousands of tiny linear moves. Each line of code may cover only a very short distance. The controller may still be looking ahead the same number of blocks, but those blocks now represent a much shorter distance on the part.

That matters because the machine needs distance to slow down. If the controller cannot see far enough ahead to know what is coming, it cannot safely commit to a high feed rate. It has to protect the machine, the part and the process. So it slows down. The controller never commits to a speed it cannot safely brake from within the distance it can see. That single planning rule explains most of the feed behaviour this article describes.

This is one reason two programs that look almost identical in CAM can behave differently on the machine. The same surface might be posted twice with different point tolerances. Both programs may be geometrically close enough to look acceptable, but one contains many more short moves than the other. To the operator, the difference shows up as machine behaviour. One program flows. The other hesitates, pulses or sits below the commanded feed in complex areas. The geometry may be nearly the same. The block density is not. The controller feels the difference immediately.

This becomes more obvious in simultaneous five-axis work. Every block can contain rotary axis positions as well as X, Y and Z positions, so the controller is not only planning where the tool tip goes; it is also planning how the rotary axes move to keep the tool at the required orientation.

Rotary axes are often the limiting factor. A small change in tool angle at the cutter can require a much larger rotary move at the machine. When that happens over a short linear distance, the controller may reduce the feed rate even though the linear axes seem capable of going faster. That is why five-axis finishing can show feed drops earlier and more often than similar-looking three-axis work.

The symptom is familiar: the feed rate holds below programmed feed through complex regions, cycle time runs longer than expected, and there is nothing obvious in the G-code that explains why. The explanation is usually not one line of bad code. It is the controller managing dense geometry, limited look-ahead distance and machine dynamics.

Why the Same Program Behaves Differently on Different Machines

Look-ahead is not identical from one controller to another. The G-code may travel from machine to machine, but the way it is executed does not. Every controller family has its own way of reading ahead, smoothing motion, applying tolerance and calculating velocity through direction changes. That is why a proven program on one machine is not automatically proven on another.

For example, Heidenhain, Siemens and Fanuc controllers all have functions that help manage high-speed contouring and smoothing, but they do not all work in the same way. On a Heidenhain TNC640, CYCL DEF 32 TOLERANCE allows the controller to deviate within a defined tolerance to produce smoother and faster motion. On a Siemens 840D, functions such as G642 and the compressor functions perform a comparable role by smoothing block transitions and handling sequences of short linear moves within a tolerance band. On Fanuc controls, AICC provides high-speed contour control capability for smoother execution of complex paths.

To an operator, these may all look like smoothing or high-speed mode. But they are not the same feature with different names. They use different planning strategies, they treat tolerance differently, and they can produce different feed rates, different acceleration behaviour and different surface results from the same NC program.

This matters in any facility where work moves between machines for capacity reasons. A job may be shifted from one machine to another because the spindle is free, the envelope fits, or the schedule demands it. The program loads, the setup is correct, the tool is right. But the machine does not move the same way.

The part may still be good. Or it may show new witness marks. Cycle time may change, tool wear may change, and the operator may have to adjust feed override, smoothing settings or prove-out strategy because the transferred process is no longer the same process. The program moved. The behaviour did not come with it.

How Feed Drops Become Surface Problems

A feed drop is not just a number on the screen. When the machine slows down but spindle speed stays the same, the feed per tooth falls. At first, that may sound harmless: slower feed, safer cut. But cutting tools do not work that simply.

A cutting edge needs enough chip load to shear material cleanly. If feed per tooth becomes too low, the edge can start rubbing or ploughing instead of cutting properly. That changes heat, pressure and surface condition at the tool edge. The edge is no longer forming a chip; it is pressing and smearing material below the level where clean shearing can begin.

In materials that work harden, this can become a bigger problem. The tool rubs or ploughs through one section, leaving the next part of the cut in a worse condition. The following pass then has to cut material that has already been affected.

This is how controller behaviour can turn into inspection findings. The operator may see local finish changes around tight direction changes, witness marks where the tool spent longer in contact with the surface, polishing or rubbing marks in areas where the programmed feed looked fine, tool wear that does not match the expected cutting data, and cycle time that keeps drifting away from the CAM estimate as surface complexity increases.

These problems can feel mysterious because the program does not show an obvious feed change. The CAM setup may look right, the tool list may be right and the setup sheet may be right. But the machine did not cut the surface at the feed rate everyone assumed.

The important point is that these areas are usually repeatable. The machine slows in the same places every time, because those locations are determined by the toolpath, block density, controller settings and machine kinematics. That means the problem is not random. It is predictable, but only if the execution behaviour is visible before the job reaches the machine.

The Usual Workarounds, and Why They Only Go So Far

Experienced operators and programmers already work around this. They loosen point tolerance to reduce the number of tiny moves. They reduce feed rates in complex areas so the difference between programmed and actual feed is smaller. They use arc fitting or smoothing at the post to give the controller cleaner geometry. They run proving cuts to find out where the machine hesitates, marks or behaves differently from the CAM estimate.

These are all rational decisions. Nobody doing real production work waits for perfect theory while a machine is burning hours. If a surface is risky, people do what works. But each workaround has a limit.

Loosening tolerance can reduce block density, but it also changes the relationship between the toolpath and the intended form, and that trade-off depends on the part, the controller and the machine. Lowering the programmed feed can make the process more stable, but it often gives away cycle time across a whole region when the real problem only exists in certain areas. Post-side smoothing can help the controller process the path more efficiently, but it still does not show the operator or programmer exactly what the machine will do with that smoothed path. Proving cuts work, but they use machine time, material, tooling and inspection effort to discover behaviour that was already built into the combination of program, controller and machine.

That is the real issue. Most workarounds compensate for controller behaviour without making that behaviour visible. They reduce risk, but they do not fully explain the process.

How Programs Should Be Evaluated

A toolpath checked only as geometry is only half checked. The machine does not cut geometry alone. It cuts geometry through a controller, through drives, through axis limits, through smoothing settings, through rotary motion, and through the physical limits of the machine structure. That means cycle time estimates, feed rate assumptions and surface finish expectations all depend on controller execution. If that execution is not visible, then the estimate is partly an assumption.

This gap between programmed intent and controller execution is the problem we work on at DigitalCNC: modelling how a specific machine and controller will execute an NC program before it runs. The output is the kinematic picture operators and programmers usually only get after the part has already been cut, including the feed rate the machine will actually achieve at each point on the toolpath.

Because if you have ever loosened a tolerance, lowered a feed across a surface you did not quite trust, adjusted smoothing, watched the feed display through a finishing pass, or run a proving cut just to find out where the machine would slow down, you were dealing with look-ahead. You were compensating for a controller decision you could not see.

The NC program was never the whole story. The real question is what the controller does with it.

There is a titanium pylon bracket waiting to be programmed. An 860mm Ti-6Al-4V forging, destined for a large horizontal machining centre. It is the kind of part where the stock is expensive, the lead time is long, and the first cut is effectively the only cut. Get it wrong, and the cost is not an hour of rework. It is a scrapped forging and a schedule that slips.

This is the part on the programmer’s screen this morning. Here is how the day goes when DigitalCNC sits alongside the CAM system.

The program that looks finished

By mid morning, the toolpaths are done. Rib top roughing, two levels of roughing, finishing passes on the open faces and the narrow features. In CAM it all looks right: the strategies are sound, the engagement is controlled, the simulation runs clean and the part comes out to shape. On any normal day this is where the program is posted, taken to the machine, and proven out, with the programmer standing at the control, listening to the cut, watching for stutter and dwell, making changes on the floor while the spindle runs and stock is consumed.

Instead, the posted program goes through DigitalCNC first. It does not connect to the machine and it does not read anything off the floor. It runs the posted code through a model of this specific machine and controller, how the look-ahead reads the program, how the axes accelerate and decelerate, where the kinematics constrain the motion, and predicts how that machine will actually drive the toolpath. At the desk, before any metal is touched.

A word on the one number that recurs below. Efficiency here is not a marketing figure. It is how much of the commanded motion the machine will actually realise: the ratio of the feed the machine can hold to the feed the program asks for, along the path. Ninety per cent means the machine delivers nine tenths of what the toolpath assumes. The gap is time the programmer is paying for and cannot see in CAM.

Decision one: the corner the machine cannot turn

The first thing the analysis surfaces is the rib top roughing. The program commands 2,200 mm/min. The prediction shows that through the corners the machine will only ever deliver 500. The toolpath could not show this, because the toolpath does not know the machine. It would have been the first thing the programmer heard on the floor: the feed dropping away, the cut labouring through every corner.

Now it is a number on the screen instead of a sound on the machine. The fix is made in CAM: allow 5mm of corner rounding where the geometry permits, and the commanded feed returns to where the programmer intended it. One change, made upstream, on evidence rather than instinct.

Decision two: the finishing pass that was quietly underperforming

Next is the first finishing pass, running at 82 per cent: the machine is only achieving 20% of commanded feedrate. The analysis shows why. Chip thickness is collapsing at ramp in and ramp out, and on titanium that is the worst place for it, the regime where the tool starts rubbing rather than cutting. The time domain plot shows exactly where along the path it happens.

The programmer opens the tolerance from 25 to 80 microns in the regions where the geometry allows it, and re-analyses. Efficiency comes back to 89 per cent. What matters is not only the recovered time. It is that the decision to relax tolerance was made knowing precisely where it was safe and what it would buy, rather than applied as a blanket guess and discovered on a CMM days later.

Decision three: turning a guess into a defensible number

The second level of roughing sits at 90 per cent. Good, and the analysis shows the one thing holding it back: a 5,000 mm/min repositioning feed the programmer had entered as a reasonable estimate. The machine can only deliver 3,000 to 3,500.

That repositioning feed was a guess, the kind every programmer makes a dozen times a day because there is no better number to hand. Now it is replaced with what the machine will actually achieve. The guess becomes a figure the programmer can defend: to a customer, to an estimator, to themselves.

Decision four: protecting the tool on the cut that matters most

The hardest one is the finishing pass on the narrow features, at 32 per cent, hard against the acceleration limit of the platform. The obvious lever, relaxing tolerance further, is the wrong one here. It would put the tool tip at risk on a slender, vulnerable cut, late in the part, after hours of metal have already been removed. A tool failure or a defect there does not cost a pass. It costs the forging. So the decision goes the other way: bring the surface speed down on this final cut, where a mistake is most expensive and least recoverable, and protect the part the whole day has been building toward.

Not every problem has the same answer. The analysis gives the programmer the information to choose the right lever for each one, instead of applying the same fix everywhere and hoping.

The error you only catch by reading the code

There is one more, and it has nothing to do with feeds or tolerances. While the analysis runs, it flags feed call errors in the posted NC. Not in the toolpath, which was correct, but in the code the post produced from it. These are the errors that survive everything upstream, because the simulation ran the toolpath and the part came out to shape, and the fault is sitting in the posted output where nobody looks until someone reads the file line by line, or until the machine does something unexpected with an expensive forging clamped in it. Here they are caught and corrected before the program leaves the desk. It is the least glamorous part of the day and, on a part like this, quietly one of the most valuable.

The program that reaches the machine validated

By the end of the day the bracket has not been near the spindle, and that is the point. Every problem that would have been found on the machine has been found in CAM. Every fix that would have cost a prove out iteration has been made at the desk: the corner feed, the chip thinning, the repositioning feed, the acceleration limit, the posting errors, all resolved before the first cut.

When the program does reach the machine, the machine confirms it rather than discovers its faults. The forging is cut once, validated against the real machine rather than an assumed one.

What changed

Look at what the programmer did differently. They did not work harder or know more than they did yesterday. They made the same decisions they always make, on feed, tolerance, strategy and surface speed. The difference is that they made them against the real behaviour of the target machine instead of an idealised model, and they made them upstream, where a change costs minutes rather than metal.

That is the day. Same programmer, same part, same levers. A different place to find the problems, a different kind of confidence in the program that goes to the machine, and a forging that is cut once, and cut right.

In our latest release, we have focused on the parts of the software that determine whether the analysis you ran this morning still reflects the part you are cutting this afternoon. Compliance-grade traceability, robustness on very large programs, and a more accurate representation of the machines. This article walks through each change, what it means in practice, and where the operational impact sits.

Audit Logs and ITAR-Compliant Traceability

The headline change in this release is the traceability module. Every modification to a CAM program, every simulation run, every interaction with a toolpath inside DigitalCNC is now recorded against a timestamp and a user. The log is held in a tamperproof database. Backend data cannot be modified after the fact, which is the record-keeping condition that supports compliance with the International Traffic in Arms Regulations (ITAR).

The log is searchable. You can filter by individual, by event type, and by date range. If a program was altered between Tuesday morning and Wednesday afternoon, you can see who altered it, what they altered, and when. Modifications made inside the CAM environment and inside DigitalCNC are both captured.

What this means as a user

Programmers working on controlled parts no longer have to maintain a parallel paper trail to satisfy compliance when working with our software. The trail is generated automatically and cannot be edited after the event. For teams working on defence and aerospace programmes, this removes a category of administrative work that has nothing to do with making parts.

Business impact

ITAR compliance is a gating requirement for a significant proportion of aerospace and defence work. Manufacturers that can demonstrate a tamperproof audit trail at the program level can take on programmes that would otherwise be closed to them. For larger primes, the same feature provides a defensible position during internal audit and customer audits.

Toolpath Robustness and Large Program Handling

Several changes in this release address how the application behaves when analysing very large CAM programs. Memory handling, toolpath sampling, and progress reporting have all been improved.

What this means as a user

Anyone who has tried to analyse a five-axis finishing program on a complex aerofoil or impeller blade inside any simulation environment knows the failure mode. The application either runs out of headroom, returns a result that smooths over the very transitions you need to see, or sits for several minutes without indicating progress. This release addresses all three. Large programs now run to completion, fine geometry on dense surfaces is resolved rather than smoothed over, and progress is reported throughout the calculation.

Business impact
The parts where this matters most are the parts where the cost of a scrap is highest. Aerospace structural components, turbine hardware, and medical implants are typically the largest and the most geometrically dense programs produced in any facility. Being able to analyse them reliably before they reach the machine reduces first-off iteration, which is where cycle time on a new component is actually lost.

Machine Library Expansion

The sample machine library has been expanded in this release. The notable addition is the Heckert HEC 1800, a horizontal machining centre widely used for aerospace-grade titanium work.

What this means as a user

A wider range of machines can now be uploaded to DigitalCNC, including those equipped with SINUMERIK 840D and Heidenhain TNC640 controllers. These are two of the most widely deployed controllers in aerospace and high value machining, which extends accurate analysis to a larger portion of the assets that are usually run.

Business impact
Cycle time accuracy is the variable that feeds quoting, capacity planning, and job scheduling. A prediction that is consistently within a few percent of actual run time across all machine and controller combinations means quotes can be tightened and machine loading can be planned with confidence. This is most relevant to manufacturers that have multiple machining centres with various controller configurations.

Feedback and Suggestions Portal

The feedback portal launches officially with this release. Suggestions and observations submitted through the portal route directly to the development team inbox.

What this means as a user
Behaviour that does not match what you see on the machine, requests for support of a specific controller, observations about how the analysis handles a particular operation type. All of these have a direct route to the people who can act on them. The route is shorter than email.

Business impact

For a tool whose accuracy depends on matching real machine behaviour, a short, direct channel from the people programming parts to the people building the software is itself a feature. Controller gaps, operation-specific edge cases, and behaviour that does not match the machine all surface faster, which lets the development roadmap track what shops actually hit rather than what is assumed.

Licensing Portal

The licensing portal has been updated. Users can now view their entitlements directly and download the current build from the same interface.

What this means as a user

When a new build is released, the path from notification to running version is shorter. Entitlements are visible without raising a support ticket.