The time a CAM system reports is usually path length ÷ feedrate, which assumes the machine runs at the programmed feed from start to finish. A real machine cannot: it slows at every corner, centripetal acceleration limits the feed on small arcs, and on short blocks the controller cannot read as fast as the machine can move.
Same path, two ways of counting. The gap is time the machine really spends.
How big the gap gets depends on the shape of the program. A roughing program made of a few long straight moves barely differs. A finishing program with 0.05 mm segments differs a lot: there, reading one block takes the controller longer than moving through it, and the bottleneck shifts from the feedrate to the controller.
The Dense finishing sample on the estimate page is that kind of program, and its header shows how to check the arithmetic. G61 vs G64 runs the same path at the same feedrate with only the smoothing mode changed, and the times differ.
The engine runs the program again, solving the velocity profile block by block.
Every stage carries source coordinates, so each diagnostic points back to a line in your program.
What the motion planning stage covers:
G61
exact stop and G64 continuous cutting.G43.4 and G68.2 are supported.
Macros (#100, WHILE, G65) are actually
evaluated. In a family program the path is computed rather than written in the file,
so a tool that skips macros sees a few dozen lines where there may be hundreds of
holes.
You can see all of it: a per-tool breakdown, what limited each segment (the feedrate, a corner, an arc, acceleration, or block processing time), and a 3D path coloured by that reason — click a segment to jump to the NC line. Paste an existing estimate (CAM, a simulator, or a machinist's judgement) and you get the difference item by item. Reports download as printable HTML for a work order.
NC programs, machine files and STL models are processed in your browser and never sent anywhere. The engine is a WebAssembly module; once it loads, the whole computation happens locally.
The content security policy on the estimate page and the machine file page is
connect-src 'self', enforced by the browser.
You can verify it: open the network tab in your developer tools and press estimate — no request goes out. Or disconnect from the network and run it again. The per-page list of outbound connections is under Auditability.
The only things that send data are the feedback and contact forms. Both are separate pages, neither has a file upload field, and you can read exactly what will be sent before sending it.
Cycle time error comes from three main places: machine parameters (acceleration capability, how fast the control processes blocks), shop-floor conditions (feed override, real tool change and waiting times), and variation in the program itself. Machine parameters are the one you can narrow down in advance, so that is where we put the effort.
Every report states which level of parameters it used:
| Level | Where the parameters come from | How to get there |
|---|---|---|
| T0 | Assumed values from a configuration template, inferred from a machine class | The default. Nothing to set up |
| T1 | The control's parameter file, or a probe reading | Enter them on the machine file page, or read them out with the P1 probe program |
| T2 | Dynamic parameters fitted from measured behaviour | The P2 dynamic probe (in development) |
The default is T0, where the number means "a machine of this class would be about this". To move up a level, build a machine file — every field is annotated with its Fanuc parameter number, and filling in the values you know brings the result closer to your machine.
We do not guarantee the accuracy of the estimate. It is an estimate, and it is good for comparing options, finding where the time goes, and spotting programs that differ sharply from your existing figures. Before it becomes the sole basis for a quote or an acceptance, check it against your own machine.
How the model is validated: public measured data (such as machining records from real machines on the NIST manufacturing research testbed) is reconciled against the engine's estimates segment by segment — cutting, rapid traverse and non-cutting time compared separately, so a deviation points to the part of the model it came from. The process repeats as new machine data arrives, and measured times sent in by users feed into the same reconciliation.
The scope is motion behaviour and cycle time; it does not include collision checking or material removal simulation. If a program uses a command the engine does not support, the report says so in its diagnostics.
No dates — the order shifts with circumstances and with feedback.
If the estimate is far from your measured cycle time, that data point is the most valuable thing you can send us — sending one is four fields, no NC program needed. For anything else use Contact (anonymous is fine) or contact@nccyclesense.com.