The estimator DOES just use distance & feedrate, not acceleration. This is effective for estimating 2D cuts but junk for 3D carving, which hinges primarily on acceleration.
There is no one effective "factor". I have 3D carvings which took 4x longer than estimated, others 6x. If it is only a gentle slope then the factor could be 1x, all for the same profile. When tuning a machine, you can reduce the axis max velocity in order to increase the max acceleration, and this can in fact make the machine run faster. Note an arbitrary multiplier factor would be useless for tuning, as you need to know the actual effect of the parameter changes. But the feature I proposed- an ETA timer- I don't see how to do it, because the required info isn't on the interface that I can find. Specifically "total line count from the G-code" and "current line number in the G-code". The concept would fail for sure on G-code bearing subroutines but that's not a feature of any of the 3d carving I'm doing. The ETA-by-line-count would be inaccurate on 2D cutting, even without subroutines, because there's no telling how long a vector is. A curved cut can be 10 or 1000 lines but only take a second or two, while a single straight line can be a long cutting time. Danny On 10/1/2016 8:39 AM, Todd Zuercher wrote: > I suppose you might be able to make something like that. > > But I think I have a good idea for improving the run time estimator. Right > now how does it work, does it just use the feed rates X distance to be > traveled? What if it took that and added to it a factor(derived from the > machines acceleration rate) X the number of lines in the file. > > ----- Original Message ----- > From: [email protected] > To: "Enhanced Machine Controller (EMC)" <[email protected]> > Sent: Friday, September 30, 2016 11:30:51 PM > Subject: [Emc-users] Estimated time remaining > > I am doing 3D carving, where the Properties analysis is regrettably useless > for coming up with time estimates due to not taking into account the > acceleration aspect of trajectory planning. > > I did install the cycle timer pvcp and it does certainly help. > > But one thing I noticed- these carvings are "mostly" consistent in how much > time they're taking per-line. It would be accurate enough to be helpful to > calculate: > > Time Remaining=(total # of gcode lines/gcode lines done so far)*cycletime so > far > > Is there any way to do that? All I can see is access to "time". > > Danny > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > Emc-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-users > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > Emc-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-users > ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
