Viesturs Lācis wrote: > 2012/4/21 Jon Elson <[email protected]>: > >> Stuart Stevenson wrote: >> >>> Would a read ahead of 1000 lines be more time consuming than the NURB >>> calculation? >>> >> A modest NURBS surface could be scanned pretty quickly to find the sharp >> edges, >> if any. 1000 block lookahead may not be necessary, even 100 block would >> probably >> suffice in most machines. >> > Not sure. I have seen arcs consisting of tiny G1 moves that are really > tiny - around 0,01 mm. 100 lines would be 1 mm. > OK, there are rational toolpaths with short segments, and then there are IRrational ones that have WAY too many short segments. LinuxCNC already has a filter mode (G64) to deal with this kind of insanity. But, I don't think it is LinuxCNC's responsibility to fix badly created G-code. You can always craft some kind of G-code that is highly pathological but yet conforms to the language spec. > I did little calcs - moving with 100 mm/s (6000 mm/min) and with > acceleration of 1000 mm/s^2 (0,1G) it will take 5 mm to fully stop. > 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.
Jon ------------------------------------------------------------------------------ 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
