Accurate time in sheetcam job report?

I’m trying to figure out how to get an accurate cut time from the sheetcam job report. I typically only use the sq inches/cut inches/pierces aspect. However, I’ve had a couple of customer-supplied-material jobs, which were a straight hourly rate. I used the sheetcam job report to estimate job times and it was WAAAY off. The jobs took ~40% longer than sheetcam estimated.

I played with pierce times in the job reports but it didn’t seem to change the results. I thought it would take (Pierce time x # of pierces) + (rapid distance x rapid rate) + (cut distance x cut ipm), but it doesn’t seem to be calculating correctly.

Will changing cut speeds in cut rules affect the calculation? When cutting a layer (say, holes) at 60% tool speed, is that reduction/slowdown figured in?

Has anyone found a way to get accurate times from the job report?

I find the times to be pretty accurate on a milling machine, less than 5 percent of the actual cycle time. Maybe your rapid setting is too slow?

Rapids are 500ipm, which is recommended by manufacturer (Bulltear / Star Lab).

I ran the simulation at 10k FRO. Time was given as 59 minutes (job took almost exactly an hour in reality).

5k FRO shows 51 min, 1k FRO shows 44 minutes. So, the closer to 100% feed rate in the simulation, the farther the divergence from actual cycle time.

Perhaps it has to do with the plasma process, vs mill (pierce times, feed rate slowdowns for small features, etc).

Strange. It does not matter how fast I run the simulation. The calculated cycle time is the same.

Simulation and the job report are separate. Both assume the machine is capable of infinite acceleration. When milling, the machine spends relatively little time accelerating or decelerating. However when plasma cutting the machine spends a significant amount of time runing slower than the commanded feed rate. Simulating the machine dynamics for an accurate time estimation is quite difficult.

The difference in estimated times at different feed rates in simulation is down to the way simulation works. It breaks the tool path down into small chunks. The more FRO you use the bigger these chunks are. This can cause a variation in the estimated time though I am a little surprised you get that much variation.