Machining time estimates are junk

[mill-art]

So I have been through the knowledge guides and all the previous threads I could find and thought I would bring this up one more time. 

The time estimation is just plain garbage.  It is inconsistent and always underestimating machining time compared to what it actually takes.  I am running small parts so my largest cam file is 150k.  I got the times from right clicking the setup and clicking machining times.  I then input my tool change time which I intentionally make it double the 1.4 secs my machine is capable of and then I input half of my rapids feed (this is done to compensate in the event I run at half rapids).  So by all right when running my job with full rapids it should take less time than what fusion is saying.  So I decided to look into simulation time as well as setup sheet time and they are all over the place. The programs are fully loading in my control so there is no lag time loading as has been suggested by your staff in other posts on this.   Actually everything I have read from the fusion staff so far has been more trying to point the blame at everyone else rather than figuring out why your calculations are inconsistent within the program.  Example.  Right clicking setup1 under setups - selecting machining time = 0:01:54, Simulation time = 0:02:49, Setup sheet time = 0:02:29...  How is anyone supposed to accurately bid a job where they don't lose money when your projections are all over the place. I don't expect it to be 100% but it certainly should be better than 60%

[Anonymous]

@Richard.stubley That's actually a really awesome response. Some cool stuff to know and I love the idea of 'cutting' those parts to get a better idea of what the feed scale should be. 

Makes total sense given that this part I am cutting has some pretty elaborate tool pathing with a lot of short cuts (so ratio of cut time versus tool move, accelerate time, decelerate time, etc. is pretty high) so those factors adding up would make sense why its so far off. 

Really appreciate the info. Thank you!

[Richard.stubley]

Hi @Anonymous,

Glad to know it helped, its really interesting calculations behind the scenes.

Its probably something you could look at with excel and start making your own database for recommendations for your feed scale.

You could rate you part in size 1-5 and complexity 1-5. Then collect predicted vs actual times and hone the feedscale for your machine.

[josh.sapp]

I have been doing this recently for better costing estimates on our milled parts. Our current project has had a Feed Scale of around 45%.

[adrien.lucca]

Hi,

I have the exact same problem, but way way worse than the examples on the previous posts. My part estimated about 15 minutes takes 3 hours to machine, which makes the estimation by Fusion 360 absolutely nonsensical. It's a pity because it makes it impossible to plan the production, especially when the workshop needs to close at a given time to avoid noise in the night (for the neighbours).

I attached the Gcode file, you'll see what the estimates are, real running time on a Shapeoko XXL with an 800Watt water-cooled spindle at 24K RPM is almost 3 hours

[Richard.stubley]

Hi @adrien.lucca,

Can you attach the Fusion project please. I'll take a look and see if I have any suggestions. 

[Richard.stubley]

@adrien.lucca,

I've just has a look at the NC code an your federate is set to 19200mm/min. From doing a bit of googling it looks like the max feedrate is more along the lines of 5000mm/min. 

So Fusion is calculating the estimated time from 19200mm/min but your machine is actually running at 5000mm/min.

This will probably be where a large amount of the error is coming from.

[adrien.lucca]

Thanks a lot! Indeed I didn't see before that the speed of the Shapeoko is limited to 5000mm/min by defaut! Should be it. I'll check again with that value instead and come back if the problem still exists..

[mill-art]

So it’s been a while since I even turned on my mill but since I am finally getting my brother functional again here is more detail.  It looks like it ignores tool changes. For example brothers are the fastest out there yet it add rinse for those. It also seems to oregano when cuts in a way that isn’t efficient for example if I had two cuts with a 1/2 and on with a 1/8. Common sense and efficiency would say to use the 1/2 till all cuts are done before moving to the 1/8 unless there was some real reason.  That doesn’t happen. It also doesn’t use my rapids settings or tool change settings and I have configured plus it uses its own default feed/speed for a toor rather than using your custom values.   Also this is pulling the time from the overall estimator and not just an operation estimators. lol 

[adrien.lucca]

Hi,

thought it would be nice to give some update here. Since I use 5000mm/min max the time estimations are pretty accurate, actually sometimes the machines even goes a bit faster than what Fusion estimates, that's great, thanks for the simple observation!

[adrien.lucca]

oops sorry my mistake, the estimates given by my controler software are accurate but not Fusion's, for example I get a total of 2H46min + 1H44 for the attached file (CONFIG FINAL)

For privacy reasons, please erase the file from the forum after downloading it

[zebraautodesk]

I also find the time estimates in Fusion's simulation to be way off. It's so far off that it's definitely not just a case of different acceleration times or a controller's ability to keep up.

My experience has been that's it's always off by 2-10x the estimate with 3d toolpaths. This is the case regardless if the toolpath is simple or complex, if it's a single operation or 10, fast or slow, long or short. 

It's not a case of a limited top-speed either as it happens on slower cutting operations just the same.

2d toolpaths are different (still not great but a smaller gap between estimate and actual).

As the inaccuracy is inconsistent I am not able to make assumptions like "a one hour estimate in Fusion means six hours actual". A one hour estimate takes anywhere from two to seven hours.

• My machine is definitely able to reach the speeds I specify as I can cut with it manually at over 12,000mm / min but rarely set toolpaths more than 6000mm / min.

I think the error is in the Gcode because it looks, to my eye, that it never cuts anywhere close to the speed I set it at in Fusion.

Because of this, I was hoping there was some user error (i.e. something I set wrong) that I could correct. 

Are there any settings that limit the feed speeds (that are not taken into account by the simulation time estimates)?

[bylerje]

Any chance that this will some day be implemented, where you could air cut a series of parts and get an idea of real world acceleration/deceleration times and fusion would take that into account with the time estimate?  With my current machine, I just assume it's going to take 2x what is predicted, and for particularly complex parts assume another scale factor on top of that.

I definitely helped myself out by learning to adjust tool paths for a minimum number of points, especially along curves, as my machine's processing seems to be limited by the number of lines of code it can handle in a given period of time.  something in the controller won't let it get up to speed when doing complex shapes that are not made up of relatively large simple arcs and line segments.