[MERGED] Approximate/rough guess of milling time
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Be nice to others! Respect the FreeCAD code of conduct!
- Pauvres_honteux
- Posts: 728
- Joined: Sun Feb 16, 2014 12:05 am
- Location: Far side of the moon
[MERGED] Approximate/rough guess of milling time
Hi, I guess this one is for @sliptonic.
Any chance of getting a button for "Approximate/rough guess of milling/process time" in the future?
The goal would be to get a round number of the economic feasibility of the object one made. You know, sometimes one gets carried away by technical awesomeness and loose track on how expensive things become if one proceeds in the current direction of engineering development...
Any chance of getting a button for "Approximate/rough guess of milling/process time" in the future?
The goal would be to get a round number of the economic feasibility of the object one made. You know, sometimes one gets carried away by technical awesomeness and loose track on how expensive things become if one proceeds in the current direction of engineering development...
Re: Approximate/rough guess of milling time
That’s interesting. I simulate in gwizard to get that.Pauvres_honteux wrote: ↑Sun Feb 11, 2018 10:23 am Hi, I guess this one is for @sliptonic.
Any chance of getting a button for "Approximate/rough guess of milling/process time" in the future?
The goal would be to get a round number of the economic feasibility of the object one made. You know, sometimes one gets carried away by technical awesomeness and loose track on how expensive things become if one proceeds in the current direction of engineering development...
But, it’s relatively straightforward. Each line of GCode has a feed rate and effectively describes a distance travelled. It seems like a natural fit for the Simulator, or to direct provide as feedback on Op or job output... it doesn’t really need a button then.
Re: Approximate/rough guess of milling time
Hi,
for calculating the milling time you need additional to the feedrate the accelaration of the machine. Only if you have a path with a lot of long G1 movements you can calculate with the feedrate only.
for calculating the milling time you need additional to the feedrate the accelaration of the machine. Only if you have a path with a lot of long G1 movements you can calculate with the feedrate only.
Gruß Herbert
- Pauvres_honteux
- Posts: 728
- Joined: Sun Feb 16, 2014 12:05 am
- Location: Far side of the moon
Re: Approximate/rough guess of milling time
Hmm, just getting the summed up traveled length would give something to further calculate on.
But an automagic button would of course be a few notches higher on the wish list.
But an automagic button would of course be a few notches higher on the wish list.
Re: Approximate/rough guess of milling time
I meant--but didn't say--including feed rates for rapids. This should be pretty close if accounting for typical move fast from x to y, then fast down to just above cut, then at vertical feed in, then lateral moves....
- sliptonic
- Veteran
- Posts: 3460
- Joined: Tue Oct 25, 2011 10:46 pm
- Location: Columbia, Missouri
- Contact:
Re: Approximate/rough guess of milling time
As herbk noted, accurate calculation is very difficult or impossible. The actual acceleration is machine dependent and unknown. The trajectory planner of the machine controller can do additional refinements and optimization that affect run-time. Some of these optimizations can be quite dramatic. LinuxCNC runtimes for pure G1 paths improved a lot when they upgraded the planner a couple years ago.
Even so, an estimate within a few % would be really useful. In LinuxCNC (Axis) you can open the File-> properties dialog and see a run-time estimate that I've found to be pretty accurate. Perhaps that could could be studied.
I've added a Mantis feature ticket tagged for 0.18. Monitor it if you want to be notified of updates
Even so, an estimate within a few % would be really useful. In LinuxCNC (Axis) you can open the File-> properties dialog and see a run-time estimate that I've found to be pretty accurate. Perhaps that could could be studied.
I've added a Mantis feature ticket tagged for 0.18. Monitor it if you want to be notified of updates
Re: Approximate/rough guess of milling time
yes, of course including rapids.
This "pretty close" depents of the part's shape. If there are a lot of direction changes, speed up and down takes more effect.This should be pretty close if accounting for typical move fast from x to y, then fast down to just above cut, then at vertical feed in, then lateral moves....
Gruß Herbert
- Pauvres_honteux
- Posts: 728
- Joined: Sun Feb 16, 2014 12:05 am
- Location: Far side of the moon
Re: Approximate/rough guess of milling time
Super! Thanks for your interest in this supportive function!sliptonic wrote: ↑Sun Feb 11, 2018 3:19 pm
I've added a Mantis feature ticket tagged for 0.18. Monitor it if you want to be notified of updates
I've set they eye of Argus on it.
Re: Approximate/rough guess of milling time
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
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
- sliptonic
- Veteran
- Posts: 3460
- Joined: Tue Oct 25, 2011 10:46 pm
- Location: Columbia, Missouri
- Contact:
Re: Approximate/rough guess of milling time
Anyone want to take a stab at coding this up in a macro so we can get some comparisons to linuxcnc and camotics for benchmark?