gCode documentation for post-processor developers

Here's the place for discussion related to CAM/CNC and the development of the Path module.
renne
Posts: 16
Joined: Wed Sep 18, 2019 7:22 am

gCode documentation for post-processor developers

Postby renne » Wed Jan 22, 2020 1:05 pm

Hi,

it is necessay to have a complete list of all gCodes used by FreeCAD to develop post-processors for specific Computer-Numeric-Controls.

Is anyone out there who has an overview about the gCodes used by FreeCAD and can add it to the Wiki?
m0n5t3r
Posts: 97
Joined: Fri Feb 03, 2017 2:55 pm

Re: gCode documentation for post-processor developers

Postby m0n5t3r » Wed Jan 22, 2020 3:17 pm

a little grep + awk + sort and a touch of hand editing came out with this (excluding postprocessors):

Code: Select all

G0, G00
G1, G01
G2, G02
G3, G03
G21
G40
G41
G42
G53
G54
G55
G56
G57
G58
G59
G81
G82
G83
G90
G98
G99
M0
M1
M3
M4
M6
renne
Posts: 16
Joined: Wed Sep 18, 2019 7:22 am

Re: gCode documentation for post-processor developers

Postby renne » Wed Jan 22, 2020 5:57 pm

I've created a gCode-documentation.
Can anyone fill in the blanks?

Thanx for any hint! :)
chrisb
Posts: 22422
Joined: Tue Mar 17, 2015 9:14 am

Re: gCode documentation for post-processor developers

Postby chrisb » Wed Jan 22, 2020 6:32 pm

G40-G44 is radius compensation. This is not done by the machine it is done on the FreeCAD side. So these can be marked as "not available".
m0n5t3r
Posts: 97
Joined: Fri Feb 03, 2017 2:55 pm

Re: gCode documentation for post-processor developers

Postby m0n5t3r » Wed Jan 22, 2020 7:17 pm

https://en.wikipedia.org/wiki/G-code has a good list

looking at the ones you marked with question marks:
  • G40 turns off tool radius compensation; since FreeCAD will do the compensation itself, you need this (or the equivalent for the machine) in your preamble
  • G41 and G42 are tool radius compensation values, probably safe to strip (they are invalidated by G40)
  • G43 and G44 are tool length offsets; I'm not sure if they are used right now, but maybe the new tools will generate them; what you do with them will depend on the machine, really (if it doesn't have an ATC so you can get repeatable offsets you'll need to probe anyway, so it's best to strip them and put a G49 in the preamble (or equivalent for the machine)
  • G53 to G59 are coordinate systems (G53 is the machine coordinate system, the rest are work coordinate systems)
  • G98 and G99 are used in the drilling operation (G98 is return to initial Z, G99 is return to retract (R) height)
  • M0 and M1 are program stop (M0 is compulsory stop, M1 is optional stop - M1 is probably machine / interpreter specific)
  • M4 is spindle turn on in reverse (works the same as M3)
JustinClift
Posts: 19
Joined: Tue Jan 14, 2020 12:58 pm
Location: Australia

Re: gCode documentation for post-processor developers

Postby JustinClift » Wed Jan 22, 2020 10:28 pm

Seems strange that M5 isn't listed, as that's the corresponding "spindle off" to match M3 and M4 (both "spindle on" commands).
chrisb
Posts: 22422
Joined: Tue Mar 17, 2015 9:14 am

Re: gCode documentation for post-processor developers

Postby chrisb » Wed Jan 22, 2020 11:19 pm

JustinClift wrote:
Wed Jan 22, 2020 10:28 pm
Seems strange that M5 isn't listed, as that's the corresponding "spindle off" to match M3 and M4 (both "spindle on" commands).
It's not coming from the Path generation, it has to be inserted by the post processor if needed.
mlampert
Posts: 1460
Joined: Fri Sep 16, 2016 9:28 pm

Re: gCode documentation for post-processor developers

Postby mlampert » Thu Jan 23, 2020 12:14 am

Just a note - you cannot rely on any restrictions. The user can insert any g-code, standard or non-standard, via a custom operation.
m0n5t3r
Posts: 97
Joined: Fri Feb 03, 2017 2:55 pm

Re: gCode documentation for post-processor developers

Postby m0n5t3r » Thu Jan 23, 2020 8:02 am

mlampert wrote:
Thu Jan 23, 2020 12:14 am
Just a note - you cannot rely on any restrictions. The user can insert any g-code, standard or non-standard, via a custom operation.
true, but you'd expect for the user to know their machine and input valid GCode there :)

I think the idea was to know what Path itself is likely to output so it can be translated to whatever the machine takes if needed, just in case some proprietary fully integrated doodad decides to be ... creative (like the Richauto thing in the other thread - it's identical to Linuxcnc in most respects, but then expects M30 for program end instead of M2), or something is using a 3d printer controller for CNC work (the 3d printing world tended to be _really_ creative about interpreting GCode in the past, and now they are kinda stuck with previous sketchy decisions)
chrisb
Posts: 22422
Joined: Tue Mar 17, 2015 9:14 am

Re: gCode documentation for post-processor developers

Postby chrisb » Thu Jan 23, 2020 10:22 am

m0n5t3r wrote:
Thu Jan 23, 2020 8:02 am
true, but you'd expect for the user to know their machine and input valid GCode there :)
That's true as well, but in some old discussion it was called better style if a post processor names all GCodes it wants to handle and not just pass unknown things through. A good reason for that is, that you may use the same model to generate GCode for different machines.