On Wed, Nov 16, 2016 at 08:15:42AM -0600, dragon wrote: > Below is a link to an email thread where Ben Potter submitted a patch > set to implement g71 into the interpreter in 2012. It was never accepted. > > https://sourceforge.net/p/emc/mailman/emc-users/thread/000601cd831d%24bc81b600%2435852200%24%40org/#msg29723177 > > Andy Pugh has updated the patch set to apply to the 2.8 branch (big > thanks Andy!)... > > https://github.com/LinuxCNC/linuxcnc/tree/BenPotter/G71 > > I would really appreciate some feedback as to what needs done for this > to get accepted. I don't want to spend a bunch of time on it if it isn't > going to go anywhere. It would be great if it can be used as a starting > point to finally get the lathe roughing cycles implemented. > > Thanks, > Todd
Hi Todd, it was good to meet you at fest and I'm glad you're still interested in this. It looks like Ben's work is a terrific starting point, and I am super excited and I want to help you however I can. I did a basic review and added some comments to https://github.com/LinuxCNC/linuxcnc/commit/0da9a50f30bb575d557b6617fa0fb0b228216f43 Here are my thoughts about what it would take to make this mergeable, in approximate order of my own feeling about importance, from necessary to wishful: Verify by eyeball the output for a variety of paths and fixup accordingly Verify that non-type-1 paths always give an appropriate error message (and not bogus motion). I think I found an error check that was wrong (I added a comment), so I think this is not well-tested yet. Verify that you can't easily break the algorithm without getting suitable error messages, such as by doing things like changing units in the middle of the profile definition, switching between radius and diameter modes, mixing IK and R arcs, using R arcs with negative radius, N words out of order, block delete, requesting multiturn arcs, requesting depths that are negative or bigger than the path, etc etc. and convince yourself it always either gives a good path or gives a coherent error Add documentation for the cycle, how to use it, its limitations Add a single sai-based runtest that roughs a path that's carefully chosen to exercise as much of the geometric code as possible (somewhere around here in my list is where I would consider the above to be the minimum necessary for merging into master) Add sai-based runtests that trigger the error conditions when you do things that aren't handled Rework the patch so it uses an O sub instead of N words to demarcate the cycle's path, as you and I both seem to think is a good idea (the fact that Ben found that a fully-compatible implementation is hard or impossible because of our UVW axes is another push in the direction of making our own sane/coherent-within-ngc implementation, I believe). I think this is especially important if the roughing cycle doesn't work with cutter comp, since you will often want to then turn on comp afterward and run the path one more time Rework the patch so roughing can be run directly with cutter compensation on Again, thanks for working on this, and let me know how to help you. Chris ------------------------------------------------------------------------------ _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
