Back Plot Cycle Times Vs Reality

[Don K]

I am a long time Mastercam user and currently using X5.

I have always relied on the cycle time under info tab in the backplot for accuracy for quoting purposes.

Today for the first time I discovered a 3:30 cycle time differential between the back plot cycle time in Mastercam to a stop watch cycle time on our Haas VF3 machining center.

Then uploaded the G code from the Haas and compared all of the speeds and feeds to that found in the parameters in Mastercam. All are identical. Our first thought was that the operator must have slowed some feedrates.

This was not the case. This paticular machine has had some service work recently.

Is it possibly that the machine isnt really performing at the programmed feed rates?

 

Again I did just compare a cycle time from another one of our machines to that in Mastercam and it was within 20 seconds of the Machine stop watch time.

[Leigh @ Kodiak]

The biggest problems with the time in backplot is it is not accurate at estimating rapid times. Although I believe there is somewhere in the machine def. that you can alter to get the times more accurate, Mastercam will still not account for the doglegging of the rapid motion. Also I do not think it factors in machine accel and decel in calculating the times. If your program has a large number of direction changes, or a lot of rapid motion, that would definitely contribute to the time differences you are seeing.

[Justin Beebe at Folsom Tool]

Don,

 

Mastercam will give you a more accurate times if you set up your machine definitions accurately. For your Haas machine have you defined how long it takes to change tools and what the maximum rapid traverse rate is for the machine.

[Saultspics]

Are you using peck drill? Mastercam back plot times are not accurate with drill cycles.

 

 

[K2csq7]

accel/decel rates are not compensated for within Mcam...

[Don K]

Just so everyone knows.

The 3:30 cycle time is longer than what the Mastercam backplot time is.

I've been using Mastercam since 1995 and never seen this much of a time differential.

I believe our operator took the cycle time solely from the timer on the Haas.

 

On Monday morning I will be using a stop watch like I had done in the past.

I have attached a copy of the program for your viewing pleasure.

 

How would I find out what the accel/decel times are?

I know in the past our programmers used to slow feedrates going into and coming out of arc moves with G code programming.

There are none of these in this particular program.

 

I do know the machine automatically accels and decels when changing directions. I guess then I need to figure what that time is and then get it added to the machine definitions in Mastercam.

[Don K]

And once again I would like to thank everyone for their input.

[Roger Peterson]

To be honest your never going to get it perfect. Via setup sheets you can scale the cycle time to reflect an average deviation percentage to get you fairly close. I shoot for being within 3% on average. There are just too many variables that affect the run time.

 

For example, a program ran on a haas had a backplot time of ~5:00, run time of ~7:30. Add a G187 for "roughing" and the run time drops to ~6:00. So even the same code, on the same machine can be drastically different.

 

 

come up with as consistent a process as possible, track setup sheet run time compared to actual and then edit the setup sheet to reflect the average deviation.

 

 

 

 

hope this helps,

[gms1]

I've been using Mastercam since 1995 and never seen this much of a time differential.

 

That is absolutely amazing. Since 1994 it's never been right... ever for me. Mastercam doesn't take into account acceleration/deceleration of each machine and not to mention some toolpaths do not time out right (like peck). Until we get full blown machine kinematics (not that I would necessarily want that), it will always be kinda close but not accurate. I use it all the time just to give me an approximate time but I wouldn't use it for quoting purposes.

 

You would get way better cycle times out of something like vericut that can do chip to chip and accel/decel simulation.

[Don K]

Don,

 

Mastercam will give you a more accurate times if you set up your machine definitions accurately. For your Haas machine have you defined how long it takes to change tools and what the maximum rapid traverse rate is for the machine.

 

 

Where do I do this?

[Don K]

To be honest your never going to get it perfect. Via setup sheets you can scale the cycle time to reflect an average deviation percentage to get you fairly close. I shoot for being within 3% on average. There are just too many variables that affect the run time.

 

For example, a program ran on a haas had a backplot time of ~5:00, run time of ~7:30. Add a G187 for "roughing" and the run time drops to ~6:00. So even the same code, on the same machine can be drastically different.

 

 

come up with as consistent a process as possible, track setup sheet run time compared to actual and then edit the setup sheet to reflect the average deviation.

 

 

 

 

hope this helps,

 

 

How do you go about scaling the cycle times on the set up sheet?

[Fred @ Slate Industries]

NX and PowerMill are in another time zone also my friend....

 

The closest thing to the actual time was the Mighty Hurco controller

After scanning my G code from MC a 2 hour run was within 11 second's actual.

 

The Haas cycle time was faster then it predicted ? A Bonus

Because I was able to go home earlier then I thought !!

 

Qouting a Job / run with MC or other CAM is Sketchy to say the least.

"I qouted that at a half hour each"!!!!

They took 55 minutes each and there were 300 of them.

Until you actually run your 5th good one through all the operations...you were guessing.

 

Guilty here myself x 1000

[Don K]

NX and PowerMill are in another time zone also my friend....

 

The closest thing to the actual time was the Mighty Hurco controller

After scanning my G code from MC a 2 hour run was within 11 second's actual.

 

The Haas cycle time was faster then it predicted ? A Bonus

Because I was able to go home earlier then I thought !!

 

Qouting a Job / run with MC or other CAM is Sketchy to say the least.

"I qouted that at a half hour each"!!!!

They took 55 minutes each and there were 300 of them.

Until you actually run your 5th good one through all the operations...you were guessing.

 

Guilty here myself x 1000

 

I've been thinking this since the day I started this thread.

This is 2011 for pete's sake and we cant get a cad system that will allow you to plug in your accel/decel, and peck drilling times from your machine into any cad system to produce accurate cycle times and produce spot on quotes that will allow us all to compete more effectively?

Something is definitely wrong with this picture.

[Don K]

NX and PowerMill are in another time zone also my friend....

 

The closest thing to the actual time was the Mighty Hurco controller

After scanning my G code from MC a 2 hour run was within 11 second's actual.

 

The Haas cycle time was faster then it predicted ? A Bonus

Because I was able to go home earlier then I thought !!

 

Qouting a Job / run with MC or other CAM is Sketchy to say the least.

"I qouted that at a half hour each"!!!!

They took 55 minutes each and there were 300 of them.

Until you actually run your 5th good one through all the operations...you were guessing.

 

Guilty here myself x 1000

 

By the way... The Haas cycle time is 30% slower than the Mastercam cycle time. So now I am not meeting my quoted price. Pretty tough to do business that way. Which makes it pretty tough to stay in business.

[Don K]

Where do I do this?

 

I did manage to find where to change the tool change time but I've found nothing that will allow me to enter accel/decel times that affects the backplot cycle time.

[Singh Abhi]

I am using MasterCam 2017. Earlier it used to give approximately accurate machining time but now It won't give me time. For machining  a 16 mm bore 12 mm deep Aluminium with feed rate 1200 and Spindle at 2000 cut being 0.1mm. It shows 1 minute time in backplot as well as in Verify (Simulator) but actually it takes around 3 minutes to machine. All the parameters mentioned are in metric  I remember Updating MasterCam  few months ago. And also it takes a lot of time to open the Application.  

 

Any suggestion will be appreciated.

Thanks in advance.

[SlaveCam]

I have also been asked to estimate cycle time using Mastercam for quotation purposes. What's your experience with 2019 backplot time estimator?

[gcode]

One thing that can help is to be sure the Home definition is correct in your Machine Def, even if you don't use it.

Also make sure your Max rapid setting is accurate

If you have your Home set 200" out and the default 1000 ipm rapid set, back plot uses these values in cycle time calculations

and bad data coming in = bad times coming out

 

[AMCNitro]

My backplot times are way off when there's a lot of drilling.  MC is not good at estimating rapids.  Its no big deal really.

[SlaveCam]

Does anyone know where this extra second comes from? (Doesn't seem to be related to home position, because changing it in the op has no effect)

[SlaveCam]

On 9/20/2019 at 5:38 PM, AMCNitro said:

My backplot times are way off when there's a lot of drilling.  MC is not good at estimating rapids.  Its no big deal really.

This seems to be bugged in 2019 (why am I not surprised?). It doesn't seem to take clearance into account, no matter what I put there the rapid feed time stays the same. Or is this by design?? (edit: apparently not, because rapid feed travel length seems to work properly with clearance)

[Matthew Hajicek - Singularity]

NCPlot is great for cycle time estimations, among other things.

[SlaveCam]

On 9/22/2019 at 10:44 PM, Matthew Hajicek™ - Conventus said:

NCPlot is great for cycle time estimations, among other things.

Does it support G83 (peck drilling) and can I enter peck clearance as well? How about pallet rotations and tool changes? Thanks.

It is getting a bit frustrating spending days programming for quotation only and then NOT get accurate estimations.

 

On 9/22/2019 at 4:18 PM, SlaveCam said:

Does anyone know where this extra second comes from? (Doesn't seem to be related to home position, because changing it in the op has no effect)

Replying to myself: the extra second came from toolchanger component in machine definition.

[JParis]

I don't know about anyone else but there is no way I am basing a quote on a CAM program.....there are just too many variables outside of the CAM system....and there is no way I am going through an entire process of programming just to get a quote...maybe a path or 2 if something looks tricky but that's it.

 

JM2C YMMV

[Matthew Hajicek - Singularity]

3 hours ago, SlaveCam said:

Does it support G83 (peck drilling) and can I enter peck clearance as well? How about pallet rotations and tool changes? Thanks.

I would recommend downloading the free trial and testing.

2 hours ago, JParis said:

I don't know about anyone else but there is no way I am basing a quote on a CAM program.....there are just too many variables outside of the CAM system....

Yup.  I was all excited that I got this bone plate programmed to a 1h 15m cycle time, and on the actual machine it took 1h 55m.