I think we should have some better time estimates for toolpaths

[lakedepthmaps]

Hey! So saving time is really important to me and I do love how when we tweak toolpath settings it gives an estimate of how long itll take. (When I upload the gcode into my router though the estimate on my routers side is quite a bit different than Fusions)

Now, the real issue is that I've noticed that the estimates are just flat out inaccurate. On my router's side (I'm aware this isn't a fusion issue) the program I use tells me what % done the file I am. But I also noticed that the % doesn't budge when doing rapids, retracts, plunges, etc. Essentially any time the router is moving and not cutting, it's not changing the % completed. It only moves when material is actively being removed.

Is it possible that Fusion's calculations work in a similar way? I was playing with 3d adaptive toolpaths and selected the 'Both Ways' function. I know the difference between the two directions, and I do like how you can set the feed speed different when doing climb vs conventional. But I noticed that the time estimate didn't change or only changed by a few seconds. I always assumed this was because retracting and doing a rapid do the next point and dropping back down was just faster or the time saved was so negligable that it only added up to a few seconds. But I did an experiment on a toolpath that said it would take 2:19 to complete with just going one way with small rapid retracts. I timed the actual simulation at whatever speed I had my simulation set at and it took :35 for the simulation to play. Then I selected Both ways and the program said it'd only save me 5 seconds or so on the 2:19. But the simulation played in :25. So clearly there's some sort of miscommunication on time passing during retracts and rapids. 

I tested it on an actual piece just in case the simulation speed varies, and I got similar results on real material. So I find that makes it extremely hard to judge what saves time and what is and isn't worth it. I had similar thoughts on Minimum staydown distance and whatnot and always just kept it low because I was under the impression that it had diminishing returns and at a certain point instead of moving down low it'd be worth it to take the time to retract and rapid and plunge back down and start the next 'line.' Logically that's true but I wonder if the point of diminishing returns is actually a lot further than we think and we're wasting a lot of time that isn't showing up on Fusion's estimates.

[engineguy]

@lakedepthmaps 

Depending on the toolpaths used then yes some wil have good time saving results as you have already noted, quite often rapiding from point A to point B can often be much faster than going fro A to B using a number of small "Transition" moves that the user will have set usually to a lower feedrate than the actual cutting feedrate so it is a balance, often see people saying that they don`t want to be rapiding long distances but how would the machine get to the new position, if it is set up to "stay down" and work it`s way across then it will probably take much longer, then there is also the way that different softwares handle these, I tested a couple and by altering various parameters (Cornering etc) I was able to change a machining time from a time that was only 3 seconds away from the Fusion time to a huge 2min 20 seconds longer time, so if your CNC software is pretty close to the Fusion values then I reckon you are OK 🙂 🙂

Hope some of that made sense 🙂