Four cycle times for the same part

Which four cycle times does one operation have?

Take a milling operation on a block of 6082 aluminium, two setups, a batch of 25. The cost engineer estimates the cycle time from the process plan. Later the programmer reads a time from the header of the NC program, a simulation produces a third figure, and the machine control records when the program started and stopped. All four are called cycle time.

They come from four sources, with four owners and four kinds of uncertainty, and they rarely agree. That is not down to the cost engineer or the programmer; it follows from what each source does and does not take into account. The trouble starts when the four land in one field and nobody can tell which one is in it.

Setup and programming are not part of it: they are one-off times per batch, spread over the pieces. Cycle time counts per piece. What that does to the unit price is worked through in why a small batch costs so much per part.

How do you calculate a cycle time from the process plan?

At quote stage there is no CAM project yet. For each operation a theoretical cutting time follows from cutting speed, feed per tooth, depth of cut and width of cut (Vc, fz, ap and ae), as the tool supplier's tables give them. The machine caps both spindle speed and feed.

For milling, spindle speed is n = Vc × 1000 / (π × Dcap) in rpm, with Vc in m/min and Dcap the cutting diameter at depth of cut in mm. Table feed is vf = fz × z × n in mm/min, with z the effective number of teeth. Cutting time is Tc = lm / vf in minutes, lm being the machined length. For turning, n uses the machined diameter Dm and cutting time is Tc = lm / (fn × n), with fn the feed per revolution.

That cutting time is only the time spent in the material. Time per piece adds rapids and tool changes, plus loading, unloading, probing and in-process measuring where they recur on every piece. Loading by hand happens outside the program, so it is neither in the NC program header nor in the control's program run time. Add it separately.

Add those up and you have the physical half. The shop-specific half is not in it yet: the actual machine, the condition of the tooling and the programmer's style. So an estimated time should carry a band, taken from the historical deviation for that family of parts. A time without a band is false precision.

How big is the gap between CAM time and actual time?

The second time sits in the header of the NC program. The CAM package or the postprocessor writes it when the program is posted, worked out from distance travelled and programmed feed. That sum assumes the machine holds the programmed feed everywhere.

It does not. Ward, Sencer, Jones and Ozturk (2021) modelled how the control plans its feed and set the result against measured times and against the times from a commercial CAM package. In corners and on short segments the control slows down, and by how much depends on the path tolerance set in the program. The CAM figure works from distance travelled and ideal feed, so it does not move when that tolerance changes.

On their aerostructure part, the CAM time came in 36 to 62 per cent below the measured cycle time, and the tighter the tolerance, the wider the gap. On a trochoidal pocket the measured time more than doubled when the tolerance went from 50 to 10 µm. A CAM time is only usable once you know which way it leans and by how much on your own machines.

Which cycle time goes into the quote?

At the first quote, the estimated time with its band; after programming and simulation, the simulated time. The bare CAM time does not belong there. The simulated time carries no band any more, only a fixed allowance for the first piece and the tool changes.

Which of the two quote moments is final follows from a shop rule: the order value, whether the part is new, and how far estimated and simulated times have drifted apart on this kind of work before. If the simulated price then differs by more than the agreed margin from a quote already sent, the price to the customer stands and the difference is recorded internally.

Put the CAM time in the quote anyway and, in the example below, you are 100 minutes of machine time short at 25 pieces. At an hourly rate of €120 that is €200 on one operation, and across a quantity break of 10, 25 and 50 pieces the gap grows with every piece.

When is a measured cycle time usable?

Actual cycle time only exists once production runs. Many controls record when the program started and stopped, the program run time; a stopwatch at the machine or an hour booked in the ERP does the same with less precision. ‘About an hour and a half’ on a job card is not a measurement.

Measured is not yet representative. A broken drill, a stoppage, an operator stepping in or an unusually long setup all end up in the clocked or booked time. Subduxion therefore separates three kinds of deviation: representative process variation, an explained exception and an unexplained anomaly. Anyone who wants a measured time to improve the next estimate first records the conditions it was produced under.

One order that runs long is one event. If three consecutive orders on the same part show the same milling overrun, that is a signal, and you correct the standard for that operation only, not the estimate for the whole part.

One field hides what post-calculation is looking for

Post-calculation compares per operation, not on the order total; otherwise an operation that was too generous and one that was too tight cancel each other out. A worked example is in estimated and actual hours per operation. It only works when both sides carry their provenance.

An ERP stores what was booked, not which time set the price. When one cycle-time field holds an estimate one day, a CAM header the next and sometimes a clocked time, the estimate cannot be checked: you compare a guess with a measurement and draw a conclusion from it. The quality depends on the real origin, not on the source system: estimated, from CAM, simulated or measured.

Take the worked example above. If the 8-minute CAM time went into the quote and the control measures 12, that one operation costs €200 of margin at 25 pieces. One field cannot show afterwards whether the estimate was too tight or the wrong figure was in it, and the next quote for that part repeats the mistake.

So every quote should carry the status of its cycle-time basis. At Subduxion an interval only carries the coverage the measurement gives it, never a round number that sounds better.

Four times, four labels

Subduxion keeps the four times apart: estimated, from CAM, simulated and measured. They are never merged into one figure, even where that would look tidier on a quote. An estimate keeps its band, a CAM time its known lean, a simulation its fixed allowance and a measurement the conditions it was produced under.

Blake calculates the estimated time first. The next step is the CAM-derived and the simulated time alongside that estimate, each with its own label. Calibration on actual hours follows, and it will narrow the band per family of parts. What is not coming is a field in which the four collapse into one.