drilling order, what the peck .

Here's the place for discussion related to CAM/CNC and the development of the Path module.
User avatar
freman
Posts: 855
Joined: Tue Nov 27, 2018 10:30 pm

Re: drilling order, what the peck .

Postby freman » Fri Jun 14, 2019 10:39 am

Thanks for the effort on fixing this.
Why is the G8* translation not the default. GRBL does NOT support these GCODEs . Did I mis-understand?

Does git-hub master build correctly now ? Yesterday it failed when opening Path work bench.

I just deleted my local copy of PathScripts/Post and got a clear copy with:
git reset --hard origin/master

I still seem to get the old versions with grbl_G81_post having execute permissions for all.

:?

EDIT. OK, not sure what was going on with versions. I deleted the tree, got fresh copy and only see the new grbl file. However xxx permissions, is that intentional?
User avatar
Gauthier
Posts: 74
Joined: Fri Jul 04, 2014 10:00 am
Location: Audenge, France

Re: drilling order, what the peck .

Postby Gauthier » Fri Jun 14, 2019 12:38 pm

freman wrote:
Fri Jun 14, 2019 10:39 am
Why is the G8* translation not the default. GRBL does NOT support these GCODEs . Did I mis-understand?
This was discussed in the push request conversation (https://github.com/FreeCAD/FreeCAD/pull/2255) :
mlampert on github wrote:grbl requires a g-code feeder and any g-code feeder dealing with grbl knows about its limitations. In other words, anybody already using grbl has configured their g-code feeder properly and however they did that works for them (I use bCNC and never had a problem with drill cycles).

Now if we change the default behaviour we change the behaviour for everybody who's already using grbl. grbl by itself is useless, it's the combination of grbl with a feeder that makes it work which is what we have to consider here.
I was not agree with the first sentence, but the second made me change my mind, I think it's not a good thing to change behavior of post processor for the aleready existing models who used the old post processor.
EDIT. OK, not sure what was going on with versions. I deleted the tree, got fresh copy and only see the new grbl file. However xxx permissions, is that intentional?
It was not intentional, this is come from the debugging process where I run the post processor directly from the Unix shell... But that's not very important ;)

@++;
Gauthier.
User avatar
freman
Posts: 855
Joined: Tue Nov 27, 2018 10:30 pm

Re: drilling order, what the peck .

Postby freman » Fri Jun 14, 2019 1:19 pm

It is not the job of the GCODE sender to start changing the GCODE, that is the job of the GCODE creator.

I use UGS which faithfully does its job and sends the G8* codes in my file to the Gcode interpreter: GRBL.

Rather perverse logic going on there but I agree that backwards compatibility is important. Sadly this means it will never be right and any GRBL user will have to discover the hard way that you need to add a special optional argument just to get the machine to work. Is this really any clearer than the two versions there was before ( which was confusing in itself ).

Well, I guess we're stuck with that now. Thanks for providing this fix for the drilling codes.

EDIT:
Thinking about it, the backwards argument does not hold water. If someone has a post processor included in their Gcode sender to parse the G80s, this would not be incompatible with post_grbl getting there first. I simply would not have to do the job any more. No breakage. :)