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.
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
GeneFC
Veteran
Posts: 5373
Joined: Sat Mar 19, 2016 3:36 pm
Location: Punta Gorda, FL

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

Post by GeneFC »

chrisb wrote: Tue Mar 13, 2018 2:49 pm When sliptonic adds an improvement to linux_cnc it is well updated in the FreeCAD Path subdirectory, but the changes will not affect the locally modified copy.
Thanks, I understand now.

However, I consider that limitation a feature, not a bug. Unexpected changes to a custom postprocessor could cause major problems for the user. At the very least the end user needs to have the ability to protect custom modifications.

A program crash because the custom postprocessor is no longer compatible with FC Path output is one thing; a physical tool crash on a workshop machine is quite another.

Gene
chrisb
Veteran
Posts: 53945
Joined: Tue Mar 17, 2015 9:14 am

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

Post by chrisb »

GeneFC wrote: Tue Mar 13, 2018 3:38 pm However, I consider that limitation a feature, not a bug. Unexpected changes to a custom postprocessor could cause major problems for the user. At the very least the end user needs to have the ability to protect custom modifications.

A program crash because the custom postprocessor is no longer compatible with FC Path output is one thing; a physical tool crash on a workshop machine is quite another.

Gene
You are right, that should be taken into account. Although any other error not depending on the postprocessor could lead to a crash as well.
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
polemidis
Posts: 36
Joined: Thu Feb 09, 2017 4:58 pm

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

Post by polemidis »

Gauthier wrote: Tue Mar 13, 2018 9:17 am Hi,

You need to place this file (grbl_post.py) in <FreeCAD_program_path>/Mod/Path/PathScripts/post, replacing the old one or rename it.

@++;
Gauthier
polemidis wrote: Tue Mar 13, 2018 12:08 am Can I have a hint plz on how to use the new post processor? Sorry I have no idea about python. Should I run it somehow, or can I replace the default grbl that freecad 0.17 has??
Thank you! Such an easy way. It looks like I was too lazy to find it out on my own! hahaa . Thanx!
Schmuick
Posts: 3
Joined: Sat Aug 25, 2018 10:26 am

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

Post by Schmuick »

Hi there,

there might be another bug when using this new GRBL post processor:
the raw g-code feed rate (mm/sec) is not converted to the machine feed rate (mm/min).
I have choosen "Metric small parts & CNC (mm, mm/min)" as pref in the general settings. For my drilling operation a vertical feed rate of 120 mm/min is displayed correctly in the raw g-code as F2.000000. If I choose linuxcnc as post processer this value exported as F120.000 which right, if I choose the current GRBL post processor I recieve F2.0.

Best regards
Schmuick
mlampert
Veteran
Posts: 1772
Joined: Fri Sep 16, 2016 9:28 pm

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

Post by mlampert »

Schmuick wrote: Sat Aug 25, 2018 10:49 am Hi there,

there might be another bug when using this new GRBL post processor:
the raw g-code feed rate (mm/sec) is not converted to the machine feed rate (mm/min).
I have choosen "Metric small parts & CNC (mm, mm/min)" as pref in the general settings. For my drilling operation a vertical feed rate of 120 mm/min is displayed correctly in the raw g-code as F2.000000. If I choose linuxcnc as post processer this value exported as F120.000 which right, if I choose the current GRBL post processor I recieve F2.0.

Best regards
Schmuick
this was fixed a few months ago, if you update you'll get a corrected version.
Schmuick
Posts: 3
Joined: Sat Aug 25, 2018 10:26 am

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

Post by Schmuick »

Hello mlampert,

I'm not quite sure which update you mean.
The most recent post of a GRBL post processor which I can find in this forum is here: https://forum.freecadweb.org/viewtopic. ... bl#p230218
With this I recieve the correct feed rate but it also introduces again the drill cycle G81!

Best regards
Schmuick
chrisb
Veteran
Posts: 53945
Joined: Tue Mar 17, 2015 9:14 am

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

Post by chrisb »

Schmuick wrote: Sun Aug 26, 2018 10:26 am I'm not quite sure which update you mean.
The most recent post of a GRBL post processor which I can find in this forum is here: https://forum.freecadweb.org/viewtopic. ... bl#p230218
In the linked topic mlampert has provided a pull request. In the menatime this is in master so you get it with the current 0.18 version, which can be downloaded here: https://github.com/FreeCAD/FreeCAD/rele ... g/0.18_pre.

These questions are one of the reasons why we like to see your FreeCAD info as described in the Help forum: http://forum.freecadweb.org/viewtopic.php?f=3&t=2264
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
Schmuick
Posts: 3
Joined: Sat Aug 25, 2018 10:26 am

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

Post by Schmuick »

OS: Windows 10
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.17.13528 (Git)
Build type: Release
Branch: releases/FreeCAD-0-17
Hash: 5c3f7bf8ec51e2c7187789f7edba71a7aa82a88b
Python version: 2.7.14
Qt version: 4.8.7
Coin version: 4.0.0a
OCC version: 7.2.0
Locale: German/Germany (de_DE)
Hello chrisb,

sorry I'm a newbie to the GitHub the way how changes are implemented.
But I think the changes that were suggested by the thread starter (Gauthier) are not integrated in the current version of the post-processor. In his post-processor I can find lines like

Code: Select all

parser.add_argument('--translate_drill', action='store_true', help='translate drill cycles G81, G82 & G83 in G0/G1 movements (default)')
parser.add_argument('--no-translate_drill', action='store_true', help='don\'t translate drill cycles G81, G82 & G83 in G0/G1 movements')
or

Code: Select all

           if TRANSLATE_DRILL_CYCLES:
                if command in ('G81', 'G82', 'G83'):
                    out += drill_translate(outstring, command, c.Parameters)
                    # Efface la ligne que l'on vient de translater
                    del(outstring[:])
                    outstring = []
I'm not able to find any lines and routines in the actual version of the grbl_post.py that are containing keywords like 'G81'. Neither in the preview version of 0.18 nor in the pull request.
But as I said, I'm not an expert in programming or in GitHub.

Best regards
Schmuick
chrisb
Veteran
Posts: 53945
Joined: Tue Mar 17, 2015 9:14 am

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

Post by chrisb »

I think mlampert talked about the feedrate issue being fixed, not the drill cycles.
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
User avatar
freman
Veteran
Posts: 2203
Joined: Tue Nov 27, 2018 10:30 pm

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

Post by freman »

Gauthier wrote: Sun Mar 04, 2018 10:56 am
For the moment, I'm working on a new version of GRBL working up to 5 axes on Mega 2560 with RAPMS 1.4, and a new interface for managing those 5 axes, so I do not have much time ... But I'm going to try anyway not to be too long on the post-processor.

@ ++;
Gauthier.
Yes generalising GRBL to 4 or 5 axes is where I eventually want to go once I have 3D cartesian hardware working to my needs. I already modded GRBL to have dual X ( ie two independently driven X motors ). The reason was I had one new 5mm pitch chinese ballscrew and one US made S/H unit with 5tpi. Very near but not the same. This mean a different scaling to keep them in sync.

Much could be done to improve GRBL readability but head honcho there seems to regard this a being too helpful to those copying the code to use in commercial products without respecting the licence. So obfuscated "open source" seems to be the model. I will be publishing some sed commands to make reading the code easier.

Keep us posted on 4th axis. This will be very useful.
Post Reply