2012/4/21 Jon Elson <[email protected]>: > > The real problem I see is that RATIONAL G-code that was correctly written to > perform a particular operation cannot be executed as fast as the machine and > drives COULD allow it to go, due to the stop on next block requirement.
I agree. What I see the big issue for solving this in trajectory planner or whatever _inside_ LinuxCNC is that I do not see, how to determine by some hard facts, what is the best way to determine the lookup amount. Certain number of lines or a certain travel distance? Ok, when the method is chosen, how to determine, what is the optimum value? That is why I am in favor of adding a separate filter, which would take the code and rephrase it to what is really in there - either arcs or splines/nurbs. In this case the file would be processed, when loaded (I have not really understood, when it would be processed in the first variant - also on loading or on the fly, when it is executed), so it definitely would not affect realtime performance, because the file would not be executed at that time. I think that waiting 10-20 seconds for the PC to recalculate the path and find, what curves would fit the existing profile, defined by tiny G1s. Viesturs ------------------------------------------------------------------------------ For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
