Currently Unrecognized G-Codes

CAD/CAM Software Tips
1

Here is a short list of unrecognized G-Codes (generated by Fusion360) that I ran across yesterday:

in no particular order:

(Definitions found here: http://www.mmattera.com/g-code/gcodes.html )

G94 = Feedrate is read as Inches/Minute. Used mostly for milling.
(example: G94 G01 X## Y## Z## F##)

I assume that this value is ignored and overridden by GC’s own feed rate settings. Including this (while using GC’s value as a hard limit) would allow Fusion360’s calculations to slow in corners, and other more precise moves/areas.

G17 = Contour plane is XY (Z = spindle)

Not too sure about this, but is this a 3-axis move? (like a downward slope?) I don’t understand “Z=Spindle” though?

G28 = Return to reference point

example: G0 G91 G28 X## Y## Z## (Go to machine XYZ home,passing thru XYZ incremental zero)

Another code that after reading the definition I’d think shouldn’t give an error… Not sure…

G54 = Work coordinate shift,offset #1

example: G54 X## Y## Z##
(Go to this XYZ position referenced from WCS #1)

I think that this was operator error, as I had improperly defined the work surface as above, relative to the Z=0, however, isn’t it quite common for CNC mills to have multiple (at least 1) ‘work offsets’, I seem to recall some youtube videos where this is used to slim some of the operations on other machines, by saying ‘go to offset #1 and re-run a file you have just run.’ or something similar.

M09 = Coolant off

Obviously, no coolants on a MaslowCNC, yet, but shouldn’t GC recognize and ignore as opposed to generating an error and rejecting?

More as I come across them, If anyone finds other unrecognized G-Codes, please post them here with similar attempts to 1) explain how they got there via the CAM software, and 2) why MaslowCNC should or shouldn’t recognize and ignore or respond in some manner other than an error.

cheers!

3 Likes
2

I recommend the excellent machine code reference found on the Tormach support site, it gives more information about gcodes and groups them by their use/effect. Here’s G94, for instance:

G93, G94 AND G95 - SET PATH CONTROL MODE
Details:
Three feed rate modes are recognized: inverse time, units per minute and units per revolution of spindle. Program: G93 to start the inverse time mode (this is very infrequently employed). Program: G94 to start the units per minute mode. Program: G95 to start the units per rev mode.

Based in that, G94 is the only one of the three that makes any sense in the Maslow world, and is the default operation. Should we acknowledge a gcode that does nothing?

G17, G18, G19 select different planes of operation, again only G17 (select XY-plane) makes sense as the Maslow is at best a 2.5D Machine and can’t operate in the other planes.

The unrecognized gcodes suggest that the gcode postprocessor target used was intended for a 3- or 4-axis milling machine. Using a different postprocessor target could avoid other problems as well. Seeing ‘unrecognized gcode’ messages is a hint to check into that. Maybe in addition to the unrecognized gcodes list here we should indicate what postprocessor created it. We could develop a list of postprocessors that fit the Maslow and a list of ones that don’t fit as well.

3

I recommend the excellent machine code reference found on the Tormach support site, it gives more information about gcodes and groups them by their use/effect. Here’s G94, for instance:

G93, G94 AND G95 - SET PATH CONTROL MODE
Details:
Three feed rate modes are recognized: inverse time, units per minute and units per revolution of spindle. Program: G93 to start the inverse time mode (this is very infrequently employed). Program: G94 to start the units per minute mode. Program: G95 to start the units per rev mode.

Based in that, G94 is the only one of the three that makes any sense in the Maslow world, and is the default operation. Should we acknowledge a gcode that does nothing?

yes, because then throwing errors on things we don’t understand becomes
meaningful.

G17, G18, G19 select different planes of operation, again only G17 (select XY-plane) makes sense as the Maslow is at best a 2.5D Machine and can’t operate in the other planes.

The unrecognized gcodes suggest that the gcode postprocessor target used was
intended for a 3- or 4-axis milling machine. Using a different postprocessor
target could avoid other problems as well. Seeing ‘unrecognized gcode’
messages is a hint to check into that. Maybe in addition to the unrecognized
gcodes list here we should indicate what postprocessor created it. We could
develop a list of postprocessors that fit the Maslow and a list of ones that
don’t fit as well.

I think it isn’t making assumptions about what the machine is, but is assuming
that it accepts any g-code. As such it has ‘boilerplate’ stuff that it puts in
‘just to make sure’ the machine is in the correct mode.

4

We really should implement G53-G59 and possibly G92 and eliminate the current
‘set home here’ functionality of GC.

Not only would this be far more standard, it would be far more flexible, and
since all the offset work is being done in the firmware, it is also going to end
up being far more reliable.

3 Likes
5

That would be a useful message in a log window. Something along the lines of “GXX not supported: ignoring”.

1 Like
6

What post processor where you using, GRBL or the Maslow specific one? I was able to compare the two of them back when the Maslow post was first released. The codes you’re referencing look like the ones that come from the GRBL post, not the Maslow one. Then again, things could have changed since I last looked at it.

It seems like everyone else already covered G94 and G17 pretty well. I agree with the points made, those two settings are the only ones we’d really be concerned with for the Maslow.

I feel like I haven’t used the G28 code very often in production work. Maybe I’m missing something here, but I usually would use a G0 command instead if I was programming manually.

I would like to see the coolant command implemented at some point. After doing some aluminum cutting, it would be very nice to have a mister at the tool connected to one of the aux pins to control on/off. We might even be able to set it so high signal at the pin would be mist and low would be flood. Of course, for me to even be able to use these functions with my machine I would have to dig the pile of steel out from in front of it and make my new sled >.>

That is right. G54 work offsets are shown pretty well in this video:

I’ve used it before in production on VMC’s. When I did it, there were 4 vices on the table, each with a part in them. I just set the G54-G57 work offsets for each vice, then ran the program. Really helps with cycle times, as you can reduce the number of tool changes you need to make for several parts.

I agree with David here. While, on the most part, we would be cutting a single pattern out on a sheet of plywood, the work offsets would certainly be useful for fixture work. I could also imagine that I would use a couple different origins during normal operation.

7

Just curious, is there a list of G/M-Codes that ARE recognized by the Maslow/GRBL currently?

Hopefully I just missed it somewhere.

8

‘not supported’ is a scary message to see.

if the code would do nothing, accept the code and do nothing, but document why
we are doing nothing in the code so people know it’s not accidental.

We already have a ‘XXX unknown, ignoring’ message

2 Likes
9

There is a wiki page here which covers the supported commands

1 Like
10

I think “unsupported” is more informative than “unknown” though… Unknown might be garbage in the code while Unsupported means it’s a valid code, just not supported by the machine.

I guess you could detail the specific code’s purpose (“G93 Inverse Time Mode not supported”) but then you’re stuck writing an exception for every condition Maslow can’t support.

Or maybe “implemented” is a better term.

1 Like
11

The firmware responds “Command GXX unsupported and ignored” (with the appropriate gcode number at XX).

1 Like
12

Well there you go. That’s very informative!

1 Like
13

For some background on workspaces (G54-G59) here’s a this old Tony YouTube video

14

short version, it’s the standard way to implement ‘set home’, but it’s not
limited to setting it where you are, and you can have multiple different ‘homes’
saved and switch between them

15

And very handy, too

Darn, that was only 18 characters… Better he wordier; fortunately that’s a natural moose trait.

Think of it as setting virtual home locations by saving offset values and using them to modify machine (absolute) coordinates to workspace (the “virtual” ones). You “touch off” to set a fixed virtual location. I had a small router with a cheap crosshair laser clamped at -1.000, 0, 0 which made it easy to line up marks with non-pointy endmills or find the centers of (most) holes by finding four edges and doing a little arithmetic

16

Is possible to implemet those gcodes G92 to set zero x,y,z on the work piece.

Bit Diameter 			0,25	Inches
Touch Plate Thickness	        0,1	Inches

Z Axis G-Code G38.2 Z-.5 F1;G92 Z0,1;G0 Z0,25
X Axis G-Code G38.2 X-.5 F1;G92 X0,125
Y Axis G-Code G38.2 Y-.5 F1;G92 Y0,125

I’m very interested in G92 command because i would like to work like this:

MASLOW%20LOGO-OK
MASLOW LOGO-OK.jpg1600×1280 66.7 KB

I Think is usefull to do a grid, but, because of calibration changes this grid is impossible to stay in the same place and is neccesary to use G92 to position the work piece on the grid.

Thank you.

1 Like
17

The ‘Define Home’ button changes the location of 0,0 to the present location of the bit, and I believe that change persists even through restarts. Will that do what you need?

2 Likes
18

I’d like something like that:

I’ve made the probe crocodrile in auxport 5 and work fine with aluminium tape.

G21 G90 G38.2 Z-30 F1 G21 G90 M02

But if I try to do the same with X or Y doesn’t work.

WP_20180610_20_18_06_Pro
WP_20180610_20_18_06_Pro.jpg5344×3008 4.42 MB

I could define with small movements the new 0,0 but I think is better in an automatic mode like Z, similar the YouTube video.

19

grbl implements G38.2 for all three axes; presently the Maslow firmware only implements the z axis. G38.2 is supposed to finish at the touch point without altering the home position and the user would use G92 for that. We don’t have G92, so G38.2 zeros the z axis at the touch point.

20

The video shows a full 3-axis machine touching its bit to the sides of a block. How can we do something similar with the router bit for the X- and Y-directions? If the bit drags on the surface, wouldn’t it affect the accuracy of the position? If it doesn’t touch the surface, would it reliably make contact at the proper point? Those are the reasons the firmware only sets the z-axis so far. Is there a way to make it work for X and Y?

1 Like