Machine Coordinates from G-Code, #<_hal[]> support

I'm trying to read the raw machine coordinates from G-Code. This will be helpful in probing subroutines to know how far one is allowed to probe in the Z axis. Currently I do this by using a G53 G0 Z0 to first raise the quill to the top in absolute mode, then switching to G91 and doing G38.3 Z-5.5 F10 to lower the quill until the probe trips (knowing that Z-5.5 is my maximum travel). That wastes a lot of time, especially when I use a slow feedrate against a rigid tool setting plate probe.

I'm also open to other suggestions.

The #<_hal[]> notion mentioned in the remapping documentation would allow me to access these variables, but doesn't appear to be in the 2.5.3 branch. I've properly enabled FEATURES=12 in the RS...NGC section of the INI. I'm not crazy about upgrading to the devel branch yet, this machine is used in a semi-production environment.

I'm curious why G53 doesn't support the G38 commands, it seems like probing would often want it's limits set to machine coordinates.

Have you looked at using G92.1 and G92.3? Or switch to a coordinate system that is not offset from the machine coordinates for the probing?

Rick G

awetmore wrote: I'm trying to read the raw machine coordinates from G-Code.

Have you seen the complete list at www.linuxcnc.org/docs/html/gcode/overview.html#sec:parameters ?

I think you can do what I think you want to do using G28.1 or G30.1
www.linuxcnc.org/docs/html/gcode/gcode.html#sec:G28-G28_1

I have studied the documentation and looked closely at G28, G30, and G92.

I don't think that I can use G28 and G30 while probing. The documentation for both says "makes a rapid traverse move from the current position to the absolute position". That is basically like G53 G0 to a set of coordinates that were previously saved using G28.1 or G30.1. G53 G0 won't do what I need either, I need the equivalent of a G53 G38.3.

G92 could work if I replaced all touch off procedures across the entire machine with G92 operations instead of G10 L20. I did check to see if G10 L20 also updates G92 by looking at #5210 (which tells you if G92 is in use), but it does not, #5210 stays 0 until you do a G92. Using remap I could potentially remap all G10 L20 to G92s, but that isn't available in the current branch and seems somewhat risky. To be honest I'm not sure where there are these two very similar but incompatible ways of adapting from machine to part coordinates.

I hadn't considered shifting to a different coordinate system while probing with G55...G59. I can try that since our machine is unlikely to have so many vises that it would end up using all 10 available coordinate systems.

awetmore wrote: I don't think that I can use G28 and G30 while probing.

No, but you can use G28.1 to read the current absolute machine position into parameters that are visible to your G-code.

Thanks, that did the trick. I had missed that G28.1 worked that way.

Here is what I ended up with, maybe it'll be useful to someone else. It assumes that tool heights are measured as tool stick out from the spindle to the surface (a zero tool height would mean the spindle nose touches the surface).

We'll use this now to make it a lot easier to measure tool heights on a Bridgeport Boss (which has repeatable tool heights in it's quick change chuck).

Once the remap stuff becomes available in a tested release I'll be able to use this along with a remapped M6 to automatically measure tool heights on my Taig CNC mill (ER16) on every tool change.

awetmore wrote: It assumes that tool heights are measured as tool stick out from the spindle to the surface (a zero tool height would mean the spindle nose touches the surface).

That is one way to do it. Many folk use a "reference tool" (often a touch probe) which is the nominal zero length.

awetmore wrote: Thanks, that did the trick. I had missed that G28.1 worked that way.

Here is what I ended up with, maybe it'll be useful to someone else. It assumes that tool heights are measured as tool stick out from the spindle to the surface (a zero tool height would mean the spindle nose touches the surface).

Code:

( measure the height of a tool using a probe plate ) o<measuretool> sub ; machine specific parameters #1000=-5.5 (max Z depth in absolute coordinates) ; setup G49 (cancel tool lengths) G91 (incremental mode) G28.1 (copy absolute coordinates into #5161-#5169) #1001=#5163 (current depth) #1002=[#1000-#5163] (probe depth) ; measure G38.3 Z#1002 F10 (probe fast down) G38.4 Z1 F1 (probe slow up) G43.1 Z#5422 (save current Z as tool height) ; cleanup G90 (return to absolute mode) G53 G0 Z#1001 (return to original Z) o<measuretool> endsub M2

We'll use this now to make it a lot easier to measure tool heights on a Bridgeport Boss (which has repeatable tool heights in it's quick change chuck).

Once the remap stuff becomes available in a tested release I'll be able to use this along with a remapped M6 to automatically measure tool heights on my Taig CNC mill (ER16) on every tool change.

I have modified your subroutine a little bit for my plasma cutter.
With this it gives no error when i move Z near 0 first.

awetmore wrote: I'm trying to read the raw machine coordinates from G-Code.

This simple idea should be plainly documented, but is not. It also needs a formal name, which I propound should be "the instant ordinate" of an axis (calling it "raw" or "machine" is not informative since the G-code machine model is a hairball of confusion). Here is an O-code subroutine gem to do it universally for any machine state and axis:


You can see there are only two lines of code required. This is clumsy and not obvious even to experts, but that's G-code.

Even this subroutine is not quite pure; it ought to push and pop the g28.1 conditions, such as with subroutine local variables, to guarantee no global side effects. Such purity requires it be done in a subroutine, which is itself an insoluble impurity; there's no proper way to do this in G-code that is both "flat" and not dependent on a language extension (such as a subroutine). This model deficiency explains the embarrassment of it not being documented. The ugliest measles always get documented last.

Our solutions are very close.
The most important lines in my subroutine are: