Learning what G53 means to my X-Carve

I just got my XCarve 500mm assembled and working, brand new to CNC. Got the Intro to Easel carve done in some MDF and then did some small engravings in wood discs. Very beginner stuff but looks great right away. Inkscape for graphic design, Easel for CAM and feeding gcode. Having lots of fun, except for when I slam my gantry into the wall…

With home switches in place, I run a home sequence (either with Easel’s “Home” button on Machine menu, or with $H through the Machine Inspector Console), all three axis move to machine zero properly (y=front, x=left, z=top).

To get the gantry out of my way so I can position and secure my workpiece, I issue command “G53 G0 Y100” and the gantry moves 100mm away from me, just about a third of the usable ~300mm distance of Y axis, exactly as expected.

Use Easel’s “Carve…” wizard to walk through machine setup, click the arrow icons to jog and zero on workpiece, execute the carve. For reference, my work zero for Y is at about Y60 relative to machine zero.

Works great, the carve ends with the bit zero’ed on the workpiece, raised up just a bit in the Z axis, all very normal.

To get at my finished product, I need to move the spindle and gantry out of the way.

Issue command “G53 G0 Z0” and the Z axis moves perfectly up to the top position.

Issue command “G53 G0 Y100” and the Y gantry flies to the rear, slams the end plates, and keeps grinding / stalling the motors for what seems as an eternity until I lose nerve and pull the plug from the wall (poor man’s e-stop). All the while, the Y position indicator in Easel’s Machine Inspector keeps climbing into the thousands (of course, the gantry is not moving because its against the plate).

I’ve been able to repeat those steps with the same sad result.

  1. Why does “G53 G0 Y100” behave differently immediately after a Home sequence than after a carve is done? If I read the gcode spec right, G53 forces the rest of the line to be read as absolute from machine zero.

  2. Even if I’m wrong about G53’s behavior and the command is treated as relative to current position, I specifically put my work at Y60 so if it were relative and traveled an additional 100 from there, it should end up at a very safe and inside bounds position of Y160, instead of shooting for the horizon.

I’m not a gcode expert at all so I could be wrong in what I am going to say next, also, I don’t have an answer for you but do have some questions!

The thing that I find interesting is when you say ‘All the while, the Y position indicator in Easel’s Machine Inspector keeps climbing into the thousands’. That shouldn’t be happening right? it should always stay within what it thinks is the machine’s bed. So worse case scenario it should only want to move one more machine bed distance away from the back of the machine.

Can you double-check that the machine dimensions in Easel are right?

The other thing I wanted to mention is that the home position for a machine, in MACHINE co-ordinates is normally at the right rear corner. So most of the machining work we do happens in negative machine co-ordinates, just like the z-axis work happens on the negative, so does the work on the x and y axis.

So what I’ve done is use the info at this link: Shapeoko CNC Router, Rigid, Accurate, Reliable, and Affordable to set the G54 position. The G54 is one of the work co-ordinate spaces, so you can set it to your limit switches position and then issue the G54 command at the start of a session.

What this does is get the machine to stop using the machine co-ordinates, where the home position is at the rear, right corner, and instead move the home position to wherever you have set it (probably at the limit switches).

What I find interesting, and I’m not sure if I’m right here, is that we tend to think of the position at the limit switches as being the home position, when as far as the machine is concerned, it’s not. The limit switches are just somewhere out there, and the machine can find them, but it’s not home to it.

@EmilianoMolina Thanks for the reply. I double checked the machine settings in Easel, and it looks reasonable. I get what you’re describing about the swapping of coordinates (i.e. normally x and y machine zero is right rear). My machine has grbl setting $3=3, which tells grbl that the x and y are actually backward from normal, and z is normal. I didn’t change that setting, it came out of the box like that, and from what I can tell it is correct.

I played a whole bunch with “G53 G0…” commands, and typically it behaves exactly as expected, with moves to positions absolute to machine zero (the xcarve zero front/left/top), just goes out the window after a job is done.

Appreciate the link to the WCS / G54 article. Definitely some helpful material, something to grow into as I learn more about gcode and how this whole system works.

Could it be that Easel leaves the machine in a different mode? Maybe in the way that the G54 command changes the co-ordinates once it’s set, it could be that the Easel g-code is doing a similar thing.

Are you in Australia? I’m not used to quick replies at this time!

Just to confuse the issue, my home position is set to front , left.
Does Easel/grbl enforce a home of right, rear?

@HedgeCourtRobots

Since you are homing the machine ($H) do yourself a favor and turn on soft limits ($20=1).

This will prevent the “rail slamming” experience.

Also, search for G28 and learn how to use G28 and G28.1.

Actually, if you assembled the machine the way Inventables instructions say, then $3=3 is normal.

Check this thread for reference:

@EmilianoMolina I’m in New York, was just up late taking care of something, happy to see your quick reply from the southern hemisphere.

@GeoffSteer That is how my xcarve (and I think all of them for people who follow the assembly instructions verbatim and don’t customize) is set too, machine home is y=front, x=left, z=top. And then the default grbl setting of $3=3 maps that to traditional machines that have home at y=back, x=right by inverting the x and y, but keeping z untouched.

@LarryM Thank you for the link, and then for the links inside of that post. Too much for me to absorb in one sitting without coffee yet, but i’ll be going back there more than once. G28 looks like a good way for me to specify a “get out of my way so I can fiddle with the workpiece” location reliably.

Soft limits are in my near future. Certainly will protect the slamming and possible damage or miscalibration errors that can occur. If I understand correctly, if I have soft limits enabled and issue the command that currently causes the gantry to hit the wall, then grbl will realize the command goes out of bounds and just sit there (raising error that I’ll see in the Machine Inspector event box?). I would not really have any idea why it is just sitting there. As a beginner, although the jarring impact is not good, it is inspiring me to learn more about gcode and controlling the machine in general.

Yes, an out of bounds request will cause grbl to raise an alarm and not move the machine. I don’t use Easel, so I’m not sure how the alarm shows up in Easel.