Machine Coordinates from G-Code, #<_hal[]> support
30 Sep 2013 08:32 #39375
by awetmore
Machine Coordinates from G-Code, #<_hal[]> support was created by awetmore
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.
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.
The following user(s) said Thank You: JetForMe
Please Log in or Create an account to join the conversation.
30 Sep 2013 12:37 #39379
by Rick G
Replied by Rick G on topic Machine Coordinates from G-Code, #<_hal[]> support
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
Rick G
Please Log in or Create an account to join the conversation.
30 Sep 2013 19:05 #39389
by andypugh
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
Replied by andypugh on topic Machine Coordinates from G-Code, #<_hal[]> support
Have you seen the complete list at www.linuxcnc.org/docs/html/gcode/overview.html#sec:parameters ?I'm trying to read the raw machine coordinates from G-Code.
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
Please Log in or Create an account to join the conversation.
30 Sep 2013 20:43 #39394
by awetmore
Replied by awetmore on topic Machine Coordinates from G-Code, #<_hal[]> support
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.
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.
Please Log in or Create an account to join the conversation.
30 Sep 2013 20:49 #39396
by andypugh
No, but you can use G28.1 to read the current absolute machine position into parameters that are visible to your G-code.
Replied by andypugh on topic Machine Coordinates from G-Code, #<_hal[]> support
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.
The following user(s) said Thank You: awetmore
Please Log in or Create an account to join the conversation.
30 Sep 2013 23:09 #39406
by awetmore
Replied by awetmore on topic Machine Coordinates from G-Code, #<_hal[]> support
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.
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).
( 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
M2We'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.
The following user(s) said Thank You: spicer
Please Log in or Create an account to join the conversation.
01 Oct 2013 00:40 #39415
by andypugh
Replied by andypugh on topic Machine Coordinates from G-Code, #<_hal[]> support
That is one way to do it. Many folk use a "reference tool" (often a touch probe) which is the nominal zero length.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).
Please Log in or Create an account to join the conversation.
29 Mar 2019 18:27 - 29 Mar 2019 18:28 #129916
by spicer
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.
Replied by spicer on topic Machine Coordinates from G-Code, #<_hal[]> support
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).
( 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.
measuretool.ngc in Verzeichnis nc_files
o<measuretool> sub
; machine specific parameters
; #1000=-100 (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)
#1002=[-#5163] (probe depth)
; measure
G38.2 Z#1002 F20
G92 Z-2.05 (distance switch_on to Workpiece surface)
G90
G0 Z1
o<measuretool> endsub
M2
Last edit: 29 Mar 2019 18:28 by spicer.
Please Log in or Create an account to join the conversation.
- Richard J Kinch
-
- Offline
- Senior Member
-
Less
More
- Posts: 61
- Thank you received: 4
29 Mar 2019 21:54 - 29 Mar 2019 22:11 #129929
by Richard J Kinch
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.
Replied by Richard J Kinch on topic Machine Coordinates from G-Code, #<_hal[]> support
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:
( Subroutine: read current g53 location )
( Input: #1 = axis code 0..8 )
( Returns: #31 = location )
( Side effects: clobbers #5161--#5169 by using g28.1 )
( RJK 02/2019 )
o<read_ordinate> sub
( Scaffold: modify this using a subr which push-probe-pops #5161--#5166 )
( to avoid potentially interfering with caller's state )
( Scaffold: does not check axis is a valid code, both in range and )
( installed. )
g28.1 ( Read current g53 coordinates into #5161--#5166 )
#31 = [#[5161+#1]] ( G53 ordinate for axis of interest )
o<read_ordinate> endsubYou 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.
Last edit: 29 Mar 2019 22:11 by Richard J Kinch.
Please Log in or Create an account to join the conversation.
29 Mar 2019 22:57 - 29 Mar 2019 23:05 #129932
by spicer
Replied by spicer on topic Machine Coordinates from G-Code, #<_hal[]> support
Our solutions are very close. 
The most important lines in my subroutine are:
The most important lines in my subroutine are:
G91 (incremental mode)
G28.1 (copy absolute coordinates into #5161-#5169)
G38.2 Z[-#5163] F20 (Z probe)
G90 (return to absolute mode)
Last edit: 29 Mar 2019 23:05 by spicer.
Please Log in or Create an account to join the conversation.
Time to create page: 0.091 seconds