G-code coordinate systems explanation -especially for GRBL

Discussion about the arduino based g-code interpreter, grbl
Post Reply
markbotics
Posts: 7
Joined: Mon Mar 02, 2015 5:28 am

G-code coordinate systems explanation -especially for GRBL

Post by markbotics » Mon Mar 02, 2015 8:07 pm

Hello, can someone provide a link or a simple explanation of coordinate systems?

Currently I'm motivated by the need to make a reliable homing system for my GRBL based machine we're making. After the homing sequence $h is finished I want the machine to be set to a fixed X,Y,Z. I assume this the "machine coordinate system" as opposed to the "work coordinate system". Furthermore it appears that there are several machine coordinate systems, each named G54, G55, ..G59.

I know in many CNC cases, the machine never moves except when stepper motor pulses are applied, also that in many applications people manually home their machine. But our machine should be "turn key" for others to use without in depth training. And in our machine, it can be moved once the power is off, indeed one axis is vertical and slumps down to a rest position when power is removed. So some non-volatile machine position stored in the controller is not suitable.

Ideally I would work in just one coordinate system, whose value is set once all limit switches are set in the homing sequence.

In my searches so far it seems there are register names and actual G-code commands, both starting with 'G'. I.e. it seems 'G...' can refer to commands and register names.

I'm assuming some G commands say "from now on x,y,z coords are in space named <--->" and that other G commands should set one of these coordinate systems, either zeroing them ("coordinate system named <---> is currently at 0,0,0") or setting them ("coordinate system <---> is now at coordinates X=542, Y=-200, Z=100").

Do you know any simple clear text anywhere that summarizes the coordinate situation? I imagine a few succinct sentences and examples would do it.

Thanks

twforeman
Posts: 1351
Joined: Tue Jan 29, 2013 4:51 pm
Location: Minneapolis, MN
Contact:

Re: G-code coordinate systems explanation -especially for GR

Post by twforeman » Mon Mar 02, 2015 8:28 pm

Start with this: http://www.shapeoko.com/wiki/index.php/ ... te_Systems

Then ask your questions.
Ender 3 3D Printer
ShapeOko v3 serial #0004 - upgrade thread
All of my ShapeOko related blog posts

markbotics
Posts: 7
Joined: Mon Mar 02, 2015 5:28 am

Re: G-code coordinate systems explanation -especially for GR

Post by markbotics » Mon Mar 02, 2015 10:00 pm

Thank you for that link, the "Using the Work Coordinate Systems" section (your http://www.shapeoko.com/wiki/index.php/ ... te_Systems) explained it all.

My understand of simplest, best practices coord systems is:

Think in terms of two coord systems: MCS (Machine Coordinate System) and WCS (Working Coordinate System).

machine coord system (MCS) -is set to 0,0,0 after homing is complete. And thou shalt not attempt to change this. For our machine at the home position (the border of active and not active for all limit switches when moving in the defined homing direction) is x-180 y-260 z+205, i.e. it is at X=-180mm, Y=-260mm, and Z=205mm in our desired coordinate system, but our machine coordinate system will be X,Y,Z=0,0,0. So our desired (working =WCS) coord system will be offset by 180,260,-205mm from the MCS.

There are actually 6 possible WCS's, I'm going to be simple and only have one working coordinate system. There are 6 possible (called G54-G59), I will use G54 which accessed by P=1.

After homing ($h in Grbl) I will issue the G10 command to set where we are in WCS. From that link, "G10 P[1-9] L20 X [offset] Y [offset] Z [offset]". For our machine I will issue:
G10 P1 L20 X-180 Y-260 Z205

Now I am unsure if I am actually in this P1 WCS coord system? Perhaps I have to invoke 'G54' before all subsequent commands such as 'G1 x10 y10 z0' will be in WCS?

I don't know what L20 is but will take it on faith that it's good.

So I believe that after 'G10 P1 L20 X-180 Y-260 Z205' the system is set so this coordinate system mapping applies: X_wcs=X_mcs+180, Y_wcs=Y_mcs+260, and Z_wcs=Z_mcs-205?

So what I'm going to do upon bootup or after a reset is:
$h
G10 P1 L20 X-180 Y-260 Z205
G90 (set absolute coords -should be default but will issue to be safe)
F10000 (set feed speed)
G1 X0 Y0 Z0 (move to desired origin in middle of workspace)

If Twforeman or anyone else would like to confirm my logic before I try it out on the live machine tomorrow, I would be grateful. Thanks in advance.

MeanderBolt
Posts: 560
Joined: Mon Nov 04, 2013 6:45 pm
Location: Georgia
Contact:

Re: G-code coordinate systems explanation -especially for GR

Post by MeanderBolt » Mon Mar 02, 2015 10:23 pm

For anyone who can edit the Wiki, Being that GRBL 9 is now official, the lines...
The first step to using work coordinate systems is to enable homing. On Grbl v0.8c that requires setting $16 and $17 to 1. In Grbl v0.9 the settings are currently $23 and $24, but this may change when it is released.
You probably also want to set the step idle delay ($7) to 255 so the motors are locked all the time and the machine will not drift or get bumped. In Grbl v0.9 this is the $15 setting. Again, this may change when v0.9 is released.
Can now be changed for permanency.
Shapeoko 2 # 3569 - DW660
Current tool chain > Draftsight > CamBam > ChiliPeppr
Build log

twforeman
Posts: 1351
Joined: Tue Jan 29, 2013 4:51 pm
Location: Minneapolis, MN
Contact:

Re: G-code coordinate systems explanation -especially for GR

Post by twforeman » Tue Mar 03, 2015 12:11 am

Mark: that sounds about right, but you really only need to set the WCS once, and then Grbl remembers it.

Sent using Tapatalk on my Galaxy S4.
Ender 3 3D Printer
ShapeOko v3 serial #0004 - upgrade thread
All of my ShapeOko related blog posts

cvoinescu
Posts: 4442
Joined: Thu Jul 19, 2012 6:50 pm
Location: Camberley, UK
Contact:

Re: G-code coordinate systems explanation -especially for GR

Post by cvoinescu » Tue Mar 03, 2015 12:21 am

You do not have to invoke G54, it's the default. You don't have to repeat the G10, because GRBL remembers it even after a reset or shutdown. You're always in a work coordinate system -- there isn't even a way to switch to machine coordinates, except on very temporary basis: G53 applies only to the line it's on, and then GRBL reverts to whatever WCS you were in.

The simplest workflow is this:
  • First time:
    • Home the machine.
    • Jog to where you want your WCS 0, 0, 0 to be.
    • Say G10 L20 P1 X0 Y0 Z0.
    • GRBL calculates the offsets from machine origin and stores them in non-volatile memory (EEPROM).
  • Every other time:
    • Home the machine. Done.
More advanced:
  • you can set the offset for X, Y and Z separately -- just mention only the axis or axes you want to affect in the G10 L20 command, e.g. G10 L20 P1 X0 Y0 will leave the Z alone.
  • You can set the offsets so that the current position is any known coordinate, not necessarily zero. For instance, if you jog the Z so that you can barely roll an 1/8" cylinder between the surface you want to be at Z = 0 and the tip of your endmill, G10 L20 P1 Z3.175 will set the Z offset in such a way as to make current position Z = 3.175 (very useful, that!).
  • If you know the offsets from machine coordinates, you can enter them directly by using G10 L2 instead of G10 L20.
Proud owner of ShapeOko #709, eShapeOko #0, and of store.amberspyglass.co.uk

markbotics
Posts: 7
Joined: Mon Mar 02, 2015 5:28 am

Re: G-code coordinate systems explanation -especially for GR

Post by markbotics » Thu Mar 05, 2015 6:02 am

Thank you cvoinescu for that succinct answer. That is the knowledge I was seeking (and probably annoyed the Github people a bit to learn as I bugged them with questions).

One first finds the range for each axis for later use with soft limits, enter those 'max travel' numbers in the $130,$131,$132 registers (v0.9g). This is the range (delta) of movements found by jogging that define a safe looking range. These max travel numbers set what the MCS (Machine Coord. System) will be after homing.

Then, yes, use the 'G10' command once, after homing, to set the WCS (Work Coord. System) relative offsets to MCS. These are then stored persistently (non-volatile). Then turn on soft limits to refuse commands and go into reset should a command request motion outside the range of the home position to that in the $130,$131,$132 registers. I was earlier mistaken thinking I could set the MCS range, and that the G92 command would be useful. Thanks to Github @chamnit for being patient and setting me straight (conversation https://github.com/grbl/grbl/issues/613).

Personally I found hard limits $21 (hard limits, bool) not to work for me, I had to keep it at 0. I have a Github issue on this https://github.com/grbl/grbl/issues/616. It is possible that, like other issues, I am wrong, but so far I find it always triggers for any requested move (eg. G1 x0 y0 z0).

Specifically, for others starting like I did, here is what I specifically ended up doing (and understanding). After first reading cvoinescu''s comment above ( Mon Mar 02, 2015 5:21 pm), it may help a newbie to see my example.

First I set these registers for the range of motion:
$130=560.000 (x max travel, mm)
$131=720.000 (y max travel, mm)
$132=400.000 (z max travel, mm)
Then I set these homing registers:
$22=1 (homing cycle, bool)
$23=3 (homing dir invert mask:00000011)
$24=2500.000 (homing feed, mm/min)
$25=2500.000 (homing seek, mm/min)
$26=250 (homing debounce, msec)
$27=20.000 (homing pull-off, mm)
Note I am homing to the bottom left (negative X,Y) but positive Z. Note also I set the offset to 20mm (all axes from the one $27 register).
Then after a homing operation ($h) my MCS is at -540,-700,-20. The MCS was (-560,-720,-0) (from max travel variables for negative homing moving axes X,Z and 0 for positive homing axis z) at the point when the last limit switch was found, before it did the homing pull-off. After the homing is fully finished, it has backed off (moved positive for X,Y and negative for Z) 20mm in each such that the MCS is at (-540,-700,-20). I see this by typing the '?' character and seeing <Idle,MPos:-539.993,-700.000,-19.996,WPos:-260.000,-340.000,285.000>.

Then, the first time, I would define what this MCS is in my desired WCS. There are 6 WCS's supported, the default is the first (aka 'G54') WCS, so we use 'P1'. I confess I don't know what 'L20' does.
G10 P1 L20 X-260 Y-340 Z285
That sets the WCS (see 'WPos:-260.000,-340.000,285.000' part of ? reply above).
Note that the WCS is an offset of the MCS by (280,360,305). I.e. a WCS point is MCS+(280,360,305)

Now if I supply a feedrate (eg. F5000), make sure I'm the first WCS (G54) and then go to my WCS origin with:
G1 X0 Y0 Z0
then my machine moves to the center of my work volume. Then if I type '?'' I see
<Idle,MPos:-279.985,-360.007,-304.994,WPos:0.008,-0.007,0.002>
Note the same relationship where MCS+(280,360,305)=WCS (-280,-360,-305) + (280,360,305) = (0,0,0)

A preamble (similar to that given by @chamnit on Github/grbl) to put at the top of our G-code programs is: (G54 makes sure we're in the first WCS, which is default unless you change it)
G54 G17 G90 G94 G21 (54=make sure we're in WCS#1, G17=XY arcs, G90=absolute coords, G94=feed rate =mm/min, G21=mm units).

Now if I turn on soft limits
$20=1 (soft limits, bool)
then the machine will only let me move to points within the range
range X -280mm to 279.9mm (can enter G1 X-280 or G1 X279 as extremes)
range Y -350mm to 359.9mm (can enter G1 Y-350 or G1 y359 as extremes)
range Z - 95mm to 300.0mm (can enter G1 Z-95 or G1 Z300 as extemes)
These are in the WCS#1 (G54) coord system.

This may be a repeat for experienced users, but hopefully useful for someone like me.

jarretl
Posts: 135
Joined: Mon Feb 24, 2014 2:50 pm
Location: Edmonton, AB

Re: G-code coordinate systems explanation -especially for GR

Post by jarretl » Thu Mar 05, 2015 3:14 pm

markbotics wrote: Personally I found hard limits $21 (hard limits, bool) not to work for me, I had to keep it at 0. I have a Github issue on this https://github.com/grbl/grbl/issues/616. It is possible that, like other issues, I am wrong, but so far I find it always triggers for any requested move (eg. G1 x0 y0 z0).
The issue you describe above is most likely interference on the limit switch lines causing the limits to trigger prematurely, not a grbl bug. This has been documented in a number of forum threads, and some solutions have been posted suggesting wiring in resistors/capacitors to help filter the noise.
See the wiring section here:
http://www.shapeoko.com/wiki/index.php/ ... hes#Wiring
Or this thread:
http://www.shapeoko.com/forum/viewtopic ... 90&p=31052
Shapeoko 2 #4043; DW660

twforeman
Posts: 1351
Joined: Tue Jan 29, 2013 4:51 pm
Location: Minneapolis, MN
Contact:

Re: G-code coordinate systems explanation -especially for GR

Post by twforeman » Thu Mar 05, 2015 3:17 pm

This is not a bug. You most likely need to add a filter capacitor to finish the RC filter to remove the motor noise. Also if you don't have shielded wires for your limit switches this can be an issue.

Other people are using limit switches (myself included) with no issues.

You need to do more research before just assuming that stuff is broken.
Ender 3 3D Printer
ShapeOko v3 serial #0004 - upgrade thread
All of my ShapeOko related blog posts

scott216
Posts: 228
Joined: Thu Oct 10, 2013 12:35 pm
Location: New Jersey

Re: G-code coordinate systems explanation -especially for GR

Post by scott216 » Sun Apr 12, 2015 7:59 pm

Can someone explain how G28 works with GRBL and the shapeoko. I read the wiki here:
http://www.shapeoko.com/wiki/index.php/ ... and_G30.3F
but I still don't understand.

I though G28.1 by itself would set the stored position to the current position, but that didn't seem to be the case because when I entered G28.1 then G28, the machine took off towards the back right corner. I halted it before it got too far.
Next I tried G28.1 X-6 Y-8 Z-1 thinking it would set the saved position to this position, but it didn't, it just moved to that position.
Can someone set me enlighten me?
Shapeoko v2 with DW660
GRBL v0.9i
Location: New Jersey

Post Reply