I use LinuxCNC exclusively, and I find that the acceleration impact on milling time is small. As sliptonic noted above, the trajectory planner does a good job of minimizing starts and stops. Even for a lot of short G1 moves the tool never really slows down or speeds up very much, unless there are a lot of short reversals.
The details are quite controllable by the G64 Px.xxx code. Unless the operator insists on a full stop at the exact end point of each gcode command, the acceleration does not play an important role in the run time.
I think initially that a simple add-up of the each path length multiplied by its feed rate would be quite useful.
I often use Camotics as a simulator. It calculates a run time that is not quite as good as the run time forecast by LinuxCNC, but it is quite informative.
By the way, the LinuxCNC calculation does not use acceleration either. From a recent copy of the documentation:
• Properties - The sum of the rapid and feed moves. Does not factor in acceleration, blending or path mode so time reported will
never be less than the actual run time.
If you are doing some other operation besides milling, and/or using a different control system then the results could be quite different. YMMV.
Gene
