- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report
@mill-art wrote:
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%
Do you have an example file we could play with? I just tried a simple 2D Adaptive op and I got 1:21 for machining time and 1:26 from simulation. The difference is not huge but it seems like they should be the same.
What machine are you using? It's possible that the machine is not running as fast as you think. I know on my Haas if I don't have the HSM option turned on (it increases the size of the lookahead buffer) it will take longer to get through code that has a lot of small line moves. This is because the control doesn't read the code fast enough to be able to keep up with the motion, so it has to slow down and wait until the next code is available. At lower feed rates it's not generally an issue but at high feed rates it can be significant. Note that this has nothing to do with drip feeding. This happens with programs stored in the control.
Another thing that Fusion has no concept about it acceleration and deceleration time. As far as I know Fusion assumes that your machine axes run at full feed rate for the entire feed distance, which is not true in real life. On fast industrial sized machines the difference may be insignificant, but on slower hobby sized machines it could be a big difference.
Of course it's also possible that there is a problem with Fusion too. So if you have an example file, people could try it on different machines and post what they get.
C|
Fusion