Evening all - I've been on IRC the past couple of days getting back up to speed on this. I'm replying to a whole bunch of e-mails inline. Sorry for the length of this.
Also, big thanks to Todd for opening this one back up. > From: Chris Radek [mailto:[email protected]] > > 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%24 > > bc81b600%2435852200%24%40org/#msg29723177 > > For information - the patch mentioned in that message was not the final patch I submitted. I've hand merged the final 2012 patch into my github and put a pull request in. > > 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 > 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/0da9a50f30bb575d557b6617fa0fb0b2 28216f43 > > 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 Absolutely, I know that some areas are weak and are likely to break, there are some improvements in the second patch, but a lot more to do. My personal feeling is that I'd like to see solid Type 1 support in and tested before we confuse people with type 2 and anti-gouging > Add documentation for the cycle, how to use it, its limitations Oh yes! > 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 I'd consider all of these as part of the minimum - at least for the common errors. Andy Pugh wrote: > One thing I think I spotted looking at it in a Sim is that the X retract prior to the Z retract seems to be in the wrong direction. > Other than that, it seems like it would at least work. Bug in patch 1, should be fixed in latest commit. > There are two demo files in the ngc directory (G71test1, G71test2) showing internal and external profiles. > The demos always run the profile too, rather than just the roughing pass. I am not sure if that is meant to happen. Intended behaviour - if I or K is specified the cycle runs a pre-finishing pass. This allows a consistent finishing thickness for the G70 pass. To get the behaviour I think you were expecting remove both I and K. > Putting an M1 between the G71 call and the block (to see if it was just running the block after the G71) was inconclusive. it ended up running part of the overall profile three times. Most odd. Interesting, I'll test - not sure why this one is happening. John Thornton wrote: > If your needing testers I can attempt to test this on my Hardinge CHNC. > All I have to do is to remember to download it in the morning during free time... > > JT Much appreciated - I'd personally wait till we've checked for a few more edge cases in sim. If you have any examples of files that you think would be awkward, feel free to throw them at it/me/us. Ben ------------------------------------------------------------------------------ _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
