2012/4/20 Kenneth Lerman <[email protected]>: > > Let's consider the alternatives: > 1 -- Change the CAM system so that it generates better code. Since there > are multiple CAM systems over which we have little control, this us not > feasible.
Yupp, unless somebody has might and resources to develop one... > 2 -- Modify LinuxCNC so that it can follow a gcode path within a > specified tolerance at a higher, more consistent rate. Already in place with G64 Px command > 3 -- Provide a filter (whether integrated with LinuxCNC or completely > separate) that convert bad paths to good paths using a specified tolerance. > > Given a standalone LinuxCNC compatible parser, I suggest that #3, would > provide a basis for experimentation and development that could later be > more closely integrated into Linux CNC. I also agree that separate filter would be better. Because the problem is solely in the g-code, so the filter to sort out the code is needed. With proper code the existing LinuxCNC can completely handle the job. 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
