Hmm this seems just right. But I think the feedrate should be taken into acount and then used some normalized value.
So if we Have G1 move 10mm long with F10 that should be equal to G1 move 100mm long with F100. And if we precalculate total length(normalized) we can in runtime predict time to end (or percentage). With this the estimated time can be precise even if speed override is used. This should work until some probe cycle is involved. Canned cycles isn't problematic and subs too.. (just need to execute it) But Probe cycle and some other ones can be problematic. Slavko. Viesturs Lācis pravi: > Well, just as it was said in the previous discussion, even without > functions, subroutines etc this approach sucks, because You can have > one line of G1 move for 0.5 mm and second line with G1 move of 3000 > mm. They will be treated equally in this approach, while there is > difference of thousand of times, how long it actually takes to execute > both of them. > I think that distance traveled vs total distance to go is more precise > approach. Actually that is what I would like to use, but that is not > that high priority for me to start investigating that. > > /vie > > 2010/8/27 Ries van Twisk <e...@rvt.dds.nl>: ------------------------------------------------------------------------------ Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
