search

winder / Universal-G-Code-Sender

A cross-platform G-Code sender for GRBL, Smoothieware, TinyG and G2core.
http://winder.github.io/ugs_website/
GNU General Public License v3.0
1.92k stars 769 forks source link

Deeply weird problem with G53 #1404

Open RecceDG opened 4 years ago

RecceDG commented 4 years ago

So I have built a fixture plate for my XCarve / XController. I now wanted to write a UGS macro that:

  1. Retracts the spindle
  2. Moves (in machine coordinates) to the known zero point of the fixture
  3. Sets work zero on X and Y

I trued up the work stops on the fixture using a G1 move from the console, and wrote down the machine coordinates from the DRO. For sake of simplicity, let's say X=-19.000 inches and Y=-17.000 inches. This is reasonable, because the DRO reports machine coordinates of X=-20 (ish) and Y=-20 (ish) immediately after homing.

This is where it gets weird.

I expect the line

G53 G0 X-19.000 Y-17.000

to move the machine to the (measured from the DRO) fixture zero. It does not. Instead the machine shoots off in the X+ and Y+ directions and will happily crash if not stopped.

G53 G0 X19.00 Y17.00

triggers a soft limit alarm.

I have tried all sorts of different values of X and Y in an attempt to get just a short move (is it in metric? Nope. Small positives? Small negatives? Nope) and all I can generate to either a mad dash to X MAX Y MAX or a limit alarm.

Then I thought "Hey, maybe G53 is modal"

G53

ok

G0 X-19.000 Y-17.000

results in a short move in the right direction - but not to the right place. Instead, it generates a relative move in mm. So for the example above, the "short move in the right direction" moves -19mm in the X and 17mm in the Y even though the machine is in absolute mode and in inches.

So one or more of the following things is true:

  1. The DRO is not correctly reporting machine coordinates
  2. G53 on the same line as a move is not switching to the machine coordinate space
  3. G53 used modally is switching the machine to metric relative mode
  4. I am all fucked up

A console command that would return the current control point position would help diagnose. I thought $# did that, but it doesn't appear to report that.

RecceDG commented 4 years ago

OK, I have figured this out.

If the move command is:

G53 G90 G20 G0 X-19 Y-17

It works.

In other words, the state of absolute/relative mode and/or the units used must be specified on the same line as the G53 command.

This is super counter-intuative to say the least!

So here is my request:

  1. G53 moves should be aware of the current status of relative/absolute and the units and not fall back to a default; and

  2. G53 used modally should be a no-op (or throw a warning), not reset the machine to metric, relative (as it appears to do)

breiler commented 4 years ago

I agree with you that it's not that intuitive but it would be very difficult or maybe even dangerous 'fixing' this in UGS as we are changing the expected behaviour of the controller. I.e if there's a CAM software that is relying on this behaviour we would break it.

G53 is handled differently between controllers so there is no solution that fits all. The GRBL documentation wasn't clear on this behaviour so that would probably be a good start if you would like to contribute.

We could add a warning in the Gcode editor (example), but that wouldn't help you when editing macros.

G53 documentation for different controllers and softwares: