Machining time estimates are junk
I mostly have experience with Haas machines and have never had any issues with machining time prediction.
Machining time is almost the same as predicted time.
Ivan Stanojevic
That is correct simulations take default rapids and not the user specified specified values. Machining time uses what I had input however it isn't calculating all the time in a cycle. For my earlier example a part I just did fusion calculated under setup - machining time (this is where you right click the setup op under cam and click on machining time.) 1 minute 54 seconds, simulation calculated 2 minutes 49 seconds, Setup sheet calculated 2 minutes 29 seconds. Actual cycle time 2 minutes 39 seconds. Difference between Actual machine cycle time and what the setup - machining time (right clicking the cam setup and selecting machining time) is a little over 27%. Admittedly the setup sheet in this case is close to actual time. The machine is a Brother Speedio s500x1. Rapids are as follows:
| Rapid traverse rate (XYZ-area) [m/min (inch/min)] | 50 x 50 x 56 (1,969 x 1,969 x 2,205) |
Tool change times are as follows:
| Tool change time*5 | Tool To Tool [sec.] | 0.8 |
| Chip To Chip [sec.] | 1.4 | |
| Cut To Cut [sec.] | 1.2 |
I am running the g100 code which allows for the spindle to clear and a g55 which allows a table to move to the next tool entry point automatically during tool change.
Unfortunately I can't share customer files or I would gladly do so. But I do have a theory: Not all tool paths are being fully calculated into the figure to give you the whole cycle time. like say non engaged/non rapid movements to include helical ramps and green lined movements etc.
What gets me is that why have an option on the setup to get machining time that calculates different than a setup sheet generated from the same cam setup? Also My day job is as a Systems Engineer where primary role is application integration into the customer environment and I am the site systems SME for the contract. The relevancy here being I have heard many a dev say there was nothing wrong with the code etc when there in fact was. I'm not saying that is the case here but if you are getting three different times and two of them are supposed to be based off of user params for rapids and tool changes then clearly there is SOMETHING different. That could be the designed output and if so it should be notated differently either in the on screen description or the product documentation. Either way a review of the code/documentation/description is in order to verify.
While in this case the difference between the setup sheet and actual (I omitted the setup - machining time window here) was 10 seconds after 6 parts that is a minute, 60 an hour, 500 part runs is a little over 8 hours I am robbing myself in labor alone on a customer job. So forgive me if I came/come across a bit harsh on this as I am not trying to be I just don't like essentially burning money 
I will say that I am now going to use the setup sheet vs the setup-machining time as it is far more accurate. In the end I just want to make the best estimates I can so that neither myself or my customer feel like one of us is over/under paid.
****edit - I ran that part setup again on a leftover piece of stock. The 10 seconds difference shows up under non cutting time on my cycle timer from the control. Thought it was worth mentioning. Will update on this other part I am running now.****
Hi all,
At the moment the machining time relies of some hard coded values to estimate rapid feed and tool change time. Depending on what you simulate the number of tool changes will vary and the tool change time may or may not take effect. Furthermore, I don't consider the acceleration and block processing speed of the CNC so that would also give some difference from the actual machining time. The particular cutting strategy used will have quite a different impact on this also.
We will add settings in the user interface in the future so we can control these numbers and get closer to your machining time.
The default Setup Sheet has its own values but you could customize it to use numbers that are closer to your CNC. See the properties 'rapidFeed' and 'toolChangeTime' if you generate the setup sheet via the post processor command.
It will take some time before we will expose these settings directly in the user interface as this ties into other features that we need and have planned.
René Fonseca
Software Architect
Rene is no longer with Autodesk, sorry about that.
@M>oolWorks can you send me your file? I don't often see that much of a disparity between estimated and actual times.
Mail to: seth dot madore at autodesk dot com. Reference this thread so I know what topic it's associated with
Seth Madore
Customer Advocacy Manager - Manufacturing
Hi, there are a few factors here contributing to this.
The easy one is tool change time, personally I record this as a rapid move across the full travel of the machine plus tool change time. Have you adjusted the default to your machines tool change time?
The next one is more tricky. Its to do with acceleration and deceleration.
Take milling a square with 90degree corners.
The machine cannot start from 0mm/min to 1000mm/min, Fusion currently does not account for this.
Next is when we hit the first corner, the machine cannot go from 1000mm/min in one direction directly to another, you would shear something, or at least not do your ball screw much good. So machines have something called a "jerk" limit. Again we dont know what this is, as its different for all machines.
In addition to this if the machine had to slow down to 100mm/min to do the 90degree turn, the deceleration has to be taken into account, as well then as the acceleration back upto the cutting feed.
In short we simulate the perfect scenario but this is unfortunately not what actually happens. You can add a value in the "feed Scale" to adjust the calculation, I use 85% on our HAAS VF2 YSS as a guide but this decreases the more complex the part is.
I was involved in some really experimental work earlier this year where we were looing at this problem. The idea being you would air cut a series of imaginary parts, plumb the actual machine time back into Fusion and then we would know what your "feed scale" should be. But this was just a WHAT IF project and we haven't done much with it yet.
I know this is not a solution by any means, but I always think understanding why the values are given don't match at least helps.
Richard Stubley
Product Manager - Fusion Mechanical Design