GRBL new post processor with drill cycles G81..G83

[chrisb]

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.

[freman]

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.

[Wsk8]

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

[freman]

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.

[Wsk8]

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

[freman]

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.

[Gauthier]

Hi,
This default value for option was discussed on the pull request conversation : https://github.com/FreeCAD/FreeCAD/pull/2255
@++;
Gauthier.

[freman]

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.

[Gauthier]

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]

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