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.