Job Report Est. Cut time Error

[David_Lelen01]

Hey Les,

Could you take a look at this for me? The estimated cut time for out waterjet machine in the job report has been way off of actual cut time. I finally just did the math and divided the total cut distance indicated on the report by the feed rate and the time came up 1h32min short. Then when i activated the path rules (which slows the feed rate) the estimate got even worse to 1h56min short.

The waterjet profile is the only one that seems to have this issue. The Laser profile and Plasma seem to calculate perfectly.

Attached is a job file, dxf, report template, and toolset. Can you see anything wrong?

Thanks

[Les Newell]

Cut distance includes the pierce plunge and cut time includes pierce delay. I just ran the report on your job:
Total cut distance 19632mm
you have 26 pierce plunges of 102.8mm = 2672.8mm
time doing pierce moves 2672.8 / 3048 = 0.88 min
distance actually cutting = 19632-2672.8 = 16959.2mm
Time actually cutting = 16959.2 / 27.94 = 606.98 min
Pierce delay = 26 pierces * 0.5min = 13 min
total 0.88 + 606.98 + 13 = 620.86

The job report shows a total of 623 min so I might have made some rounding errors but I'm not far off.

[David_Lelen01]

I agree with your math, that all makes sense. I was not aware it factored in the plunge distance as well. But still it took 12hr 8min to cut this part. I suppose it must be a machine issue, maybe its not moving at the specified feed rate. But the cut quality is on par with the feed rate compared to other machines.

This still does not explain how the time gets shorter when the path rules are active and the path rules slows down the feed rate. Should the time not get longer??

[djreiswig]

The report has no way of knowing the physics of your machine. I highly doubt your machine is capable of cutting at full speed continuously. The difference in the times is probably attributed to the machine slowing down to hold to the cut path, as well as accelerating and decelerating during rapids. It might not seem like much, but in a 10 hour time span it adds up.
I don't use the reports very much, so I'm not sure what is up with the path rules.

[David_Lelen01]

I hate to come back to this since maybe not a lot of people use the reports, but we would like to use it a lot for estimating large jobs.

The path rules definitely have an error in the calculation, as they reduce the cut time instead of add to it. There is a big error somewhere in the rapid distance calculation or i am just plain out missing something critical.

I made a test file of a rectangle with a ton of small circles so i could easily determine the cut distance by hand. Set all offsets to none, leadin and leadout to none, overcut to zero. Ignoring all machine physics such as accelerations, pauses, etc. Including tool pierce time, plunge distance. The times are still off from hand calculations.

Forgive my handwriting, but attached are the files to review. I may still be missing something for the cut time, but there is obviously a problem with the way the path rules are handled and i feel certain for the rapid distance as well.

Thank you for your time.

Respectfully,

David McCullough

[Les Newell]

I found an issue with the feed overrides. I was multiplying rather than dividing so the override was going the wrong way. I'll fix it in the next release.

[David_Lelen01]

Thank you so much for looking into that Les. I really appreciate it. Could that also explain the what seems to be unrealistic values for the rapid distance as well?

[Les Newell]

No, it just affects the cut time estimate.

[David_Lelen01]

I also noticed it looks like the pierce delay is not added into the cut time. Is it perhaps added into the total job time instead? I cant tell that from my hand calcs since the rapid distance is so far off.

[motoguy]

I hate to come back to this since maybe not a lot of people use the reports, but we would like to use it a lot for estimating large jobs.

I use the reports for pricing as well. The reports in the "stable" Windows version of SC were junk...way, way off. However, the reports in Linux seem to be right on the money (for plasma). I was told that the Dev Windows version uses the same report as the Linux version, so I started using the Dev version. Reports in it seem to be very accurate as well.

[David_Lelen01]

Reports in it seem to be very accurate as well.

I have always used the development version in windows since I need some of the features in it for our machines to work correctly. Until recently i have always agreed with what you said, the reports have seemed to be very accurate, with the exception of out waterjet. I thought for a long time it must be something i was doing wrong since the laser and plasma seemed to be accurate. It was only recently when i put a long running job on our laser and found that the times were way off and started digging into it deeper.

10% difference in estimated vs actual time is seemingly irrelevant when you run 15-30 minute jobs, but when you throw a 12hr job on there it becomes much more of a big deal.