GRBL new post processor with drill cycles G81..G83

Here's the place for discussion related to CAM/CNC and the development of the Path module.
chrisb
Posts: 19589
Joined: Tue Mar 17, 2015 9:14 am

Re: GRBL new post processor with drill cycles G81..G83

Postby chrisb » Tue Jun 18, 2019 8:22 am

Hi and welcome to the forum!
The postprocessors are distributed with FreeCAD, you may have to wait a couple of days until it is contained in the daily version.

You select it like the other post processors in the job's output tab.
User avatar
freman
Posts: 746
Joined: Tue Nov 27, 2018 10:30 pm

Re: GRBL new post processor with drill cycles G81..G83

Postby freman » Sat Oct 12, 2019 9:59 am

Hi,

For other reasons I just had to drop back to a clean build from 25th August. I pulled a clean freecad-source , built it and I did not get drilling cycles translated.

I checked the source and find.

Code: Select all

TRANSLATE_DRILL_CYCLES = False
I can't recall if this was discussed explicitly before but it seems an odd default.

GRBL does not recognise drilling cycles and will just ignore G83 and friends. What is the point of having a grbl post-processor which does not produce valid GRBL code?

The whole point of this excellent improvement is to provide a feature which is turned off. That seems very strange.
User avatar
Wsk8
Posts: 48
Joined: Fri Dec 07, 2018 6:24 pm

Re: GRBL new post processor with drill cycles G81..G83

Postby Wsk8 » Sat Oct 12, 2019 10:42 am

Since grbl doesn't understand drilling cycles, they are left out. But the post processor can translate them (as additional feature) to linear movements, if you provide the arguments in the setup.

mfg
User avatar
freman
Posts: 746
Joined: Tue Nov 27, 2018 10:30 pm

Re: GRBL new post processor with drill cycles G81..G83

Postby freman » Sat Oct 12, 2019 10:53 am

No, they are not left out they are left in.

This post processor produces output which the target does not support. This obliges anyone using it to know this little secret and dig around and apply a hack just to make it work.

That seems rather perverse logic unless there is an important reason to do it this way.
User avatar
Wsk8
Posts: 48
Joined: Fri Dec 07, 2018 6:24 pm

Re: GRBL new post processor with drill cycles G81..G83

Postby Wsk8 » Sat Oct 12, 2019 11:02 am

Then this behaviour was changed with the merge of the post processors. But you just need to add the translate drill cycles argument to the setup.

mfg
User avatar
freman
Posts: 746
Joined: Tue Nov 27, 2018 10:30 pm

Re: GRBL new post processor with drill cycles G81..G83

Postby freman » Sat Oct 12, 2019 12:05 pm

I just changed the default to "True" in the source. The point is : what is the reason for this seeming aberrant config.

Anyone picking up FreeCAD and using with GRBL will not know about the main feature which this post-processor upgrade was designed to provide and will wonder why it produces gcode that will not run on the target it is supposed to serve.
User avatar
Gauthier
Posts: 73
Joined: Fri Jul 04, 2014 10:00 am
Location: Audenge, France

Re: GRBL new post processor with drill cycles G81..G83

Postby Gauthier » Mon Oct 14, 2019 10:48 pm

Hi,
This default value for option was discussed on the pull request conversation : https://github.com/FreeCAD/FreeCAD/pull/2255
@++;
Gauthier.
User avatar
freman
Posts: 746
Joined: Tue Nov 27, 2018 10:30 pm

Re: GRBL new post processor with drill cycles G81..G83

Postby freman » Tue Oct 15, 2019 6:45 am

Thanks, seems Sliptonic was of the same opinion as I am on this.
if we replace the default grbl post processor then the default should be
TRANSLATE_DRILL_CYCLES = False
changing existing behaviour is generally not a good idea.
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).
While I am big fan of maintaining b/w compat, that is a false logic. If users are currently relying on their gcode sender to post-process drilling cycles and grbl gets there first, there will be no drilling cycles for the sender to process. This will not be a problem and will not be discruptive.

A gcode sender should be focused on communicating with the Gcode interpreter, not doing post-processing, IMO.

Anyway, that boat has sailed now, so I don't suppose there's much sense in reopening the issue.

Thanks for the link.
User avatar
Gauthier
Posts: 73
Joined: Fri Jul 04, 2014 10:00 am
Location: Audenge, France

Re: GRBL new post processor with drill cycles G81..G83

Postby Gauthier » Sat Oct 26, 2019 5:14 pm

Hi @freman,
I agree with you for all your args, but that was not the majority of those who participated in the discussion. So I think like you that there's not much sense in reopening the issue.
However, I think a good solution might be to add a post processor preferences and options panel, which would allow the user to have his own default values.
Unfortunately, I'm not competent enough in FreeCAD graphic interface development to implement it now.
Perhaps I will do it later when I will undestand how to do it.
@++;
Gauthier.
mlampert
Posts: 1379
Joined: Fri Sep 16, 2016 9:28 pm

Re: GRBL new post processor with drill cycles G81..G83

Postby mlampert » Sat Oct 26, 2019 6:11 pm

Out of curiosity I checked the history and it seems those preferences had their 3rd anniversary 3 days ago - they were added 2016-10-23 :D