Why G01 instead of G1?

[chrisb]

It's getting warmer and I can go back to real milling - during winter it was too cold to be fun.
So I created a path with post processor - and it didn't work. I repaired some type issues - it still didn't work as expected.
After quite a while I found that the basic GCode commands have changed. Numbers below 10 get a leading zero, so Instead of G1 I get G01 ...
My post processor has to react on G2 and G3 because the circle's center has to be transformed to absolute coordinates. Now I am unsure what to do: Will it be changed back or not? I have changed the post processor to deal with both representaions but I don't like this kind of code because there is no need to have both.

So may I ask why the leading zeros where introduced?

I think that the commands transferred to the post processor are pure technical stuff and cosmetics should not have room there. We don't have it with the M codes, why should we have it with the Gs?

Since other post processors have this problem too: Could you please change it back?

[GeneFC]

Hmmm, I have never seen anything other than two-digit G-codes from the Path workbench, with the occasional exception of a G0 as the first code in some procedures.

The typical G-code definitions allow for either. Does your machine controller object?

Gene

[sliptonic]

This is an easy customization to your postprocessor. Perfect use case.

[chrisb]

Hmmm, I have never seen anything other than two-digit G-codes from the Path workbench, with the occasional exception of a G0 as the first code in some procedures.

The docs about the Path WorkBench mention one digits Gs only: https://github.com/yorikvanhavre/FreeCA ... ath-module. So does the quick reference of linuxcnc: http://linuxcnc.org/docs/html/gcode.html

The typical G-code definitions allow for either. Does your machine controller object?

My machine is from the 80s, a mechanical dream and a programmer's nightmare. It has very limited memory, I can program a few hundred lines only, then I have to split the files. So I fight for every byte. But in fact it isn't the output which was a problem, it was the input.

This is an easy customization to your postprocessor. Perfect use case.

That's where I will handle it. But I still think the post processors should be used to produce different output formats while having a standard input format.

It is really not a big deal and I will not whine about it over and over. I still would like to know if it has advantages internally, but there is no need to spend extra time to look it up. Only if you know it by heart.

[sliptonic]

I only know that both forms were intentionally supported from the beginning. I don't remember when one started being favored.