Re: [Emc-developers] Probe result parameters (5061-5069)

2018-07-28 Thread David Bagby 

On 7/28/2018 8:58 AM, Sebastian Kuzminsky wrote:

On 07/27/2018 02:39 PM, Kurt Jacobson wrote:

So the question is, why did LCNC choose to use relative positions for the
probe parameters? There must be a good reason to not follow what seems to
be a standard among other controllers, but the only advantage I can see is
when probing to measure/scan a part, but in that case it would be very easy
to convert the ABS probed pos to relative by subtracting the WCO.

I don't know why the decision was originally made, but I can see the
argument for having both available.

When measuring a part using probing and logging, having the probe
location in the part's coordinate system (ie, in the workspace
coordinate system) makes things simpler.

When probing a part in order to set the coordinate system to the part,
having the probe location in absolute coordinates makes things simpler.



Trying to think of ways to make the behavior more expected for people
coming from other controllers, and at least make it clear in the docs .
Would it make sense to change parameters 5061-5069 to be the ABS probed
pos, or maybe allow using G53 with G38? I think it would also make sense if
`stat.probed_position` was consistent with the 5061-5069.

I don't think we should change the meaning of existing parameters or
fields, because doing that would break existing functionality.

I would prefer adding nine new Interpreter parameters containing the
*absolute* probe location, and adding a new field to the Status buffer
(and the 'stat' variable in the linuxcnc python module) containing the
probed position in *work coordinates*.


The probe position is originally determined by Motion, which operates
*only* in absolute coordinates.  The probe information is relayed from
Motion to Task via the Motion Status buffer, and Task converts it to the
currently active workspace coordinates.

The Interpreter (and thus the Interpreter parameters #5061 through
#5069) use these converted workspace coordinates.  The
'stat.probed_position' variable in the linuxcnc python module gets its
info straight from Motion (again via the Motion Status buffer), so it
sees the absolute coordinates.




This discussion got me thinking about the details of some probing 
routines I did some years back on another control.


I think I understand that LCNC does tip comp - correct?

What module does the tip comp calculation?

On prior controls I always had trouble with cases where I could not get 
a probe trigger coordinate without tip comp applied. That other system 
made two (not always valid) assumptions:


a) tips where spheres

b) probe movement was always along a axis.

This caused inaccurate results when probing in an arbitrary direction, 
or whenever a non-spherical tip was in use.


So, I'm thinking that there is another dimension to be considered 
besides current coordinate system:
"with tip comp applied" or "without tip comp applied". I think of "w/o 
tip comp" as = sphere tip of 0 diameter).


(I have found the ability to get the trigger coord in both G53 and/or WC 
is important in different situations).


The ability to get a "non-tip comp'ed" trigger coord allows one to 
implement code to handle more complex tip geometries.



2nd topic:

Having any probe trigger event cause an action in the control whenever a 
non-probe move is being executed strikes me as not always desirable.  
I've programmed lots of cases were where one wants to execute a move, 
with the probe mounted as the current tool, but not want that move to 
stop things due to jiggle along the way. I would like to see a way to 
enable/disable this "feature".


Dave


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Probe result parameters (5061-5069)

2018-07-28 Thread andy pugh 
On 28 July 2018 at 16:58, Sebastian Kuzminsky  wrote:

> I would prefer adding nine new Interpreter parameters containing the
> *absolute* probe location, and adding a new field to the Status buffer
> (and the 'stat' variable in the linuxcnc python module) containing the
> probed position in *work coordinates*.

I think that, on reflection, this makes a great deal more sense than
adding more variants of the probe G-codes.

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1916

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Probe result parameters (5061-5069)

2018-07-28 Thread Sebastian Kuzminsky 
On 07/27/2018 02:39 PM, Kurt Jacobson wrote:
> So the question is, why did LCNC choose to use relative positions for the
> probe parameters? There must be a good reason to not follow what seems to
> be a standard among other controllers, but the only advantage I can see is
> when probing to measure/scan a part, but in that case it would be very easy
> to convert the ABS probed pos to relative by subtracting the WCO.

I don't know why the decision was originally made, but I can see the
argument for having both available.

When measuring a part using probing and logging, having the probe
location in the part's coordinate system (ie, in the workspace
coordinate system) makes things simpler.

When probing a part in order to set the coordinate system to the part,
having the probe location in absolute coordinates makes things simpler.


> Trying to think of ways to make the behavior more expected for people
> coming from other controllers, and at least make it clear in the docs .
> Would it make sense to change parameters 5061-5069 to be the ABS probed
> pos, or maybe allow using G53 with G38? I think it would also make sense if
> `stat.probed_position` was consistent with the 5061-5069.

I don't think we should change the meaning of existing parameters or
fields, because doing that would break existing functionality.

I would prefer adding nine new Interpreter parameters containing the
*absolute* probe location, and adding a new field to the Status buffer
(and the 'stat' variable in the linuxcnc python module) containing the
probed position in *work coordinates*.


The probe position is originally determined by Motion, which operates
*only* in absolute coordinates.  The probe information is relayed from
Motion to Task via the Motion Status buffer, and Task converts it to the
currently active workspace coordinates.

The Interpreter (and thus the Interpreter parameters #5061 through
#5069) use these converted workspace coordinates.  The
'stat.probed_position' variable in the linuxcnc python module gets its
info straight from Motion (again via the Motion Status buffer), so it
sees the absolute coordinates.


-- 
Sebastian Kuzminsky

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Probe result parameters (5061-5069)

2018-07-27 Thread Gene Heskett 
On Friday 27 July 2018 21:15:03 Kurt Jacobson wrote:

> On Fri, Jul 27, 2018 at 8:46 PM, andy pugh  wrote:
> > Good point. How about...
> >
> > G21 G91
> > G38.2 z-20 F80
> > G0 X#5061 Y#5062 Z#5063
> > G10 L20 P1 Z0
>
> That would probably crash the probe, but a variant of that would work.
>
> G21 G91
> G38.2 z-20 F80
> G0 Z[#5063 + .100] (move up a know amount from where the probe
> tripped) G10 L20 P1 Z.100   (set out current location to the distance
> we moved)
>
> But that gets a little dangerous, because the signs have to be right,
> and if you are probing inside a hole or slot, then what do you do 
>
I probe all 4 directions to get the center of the hole.  Has worked well 
for me for almost a decade, accuracy well under a thou.

> > FWIW I rather agree that probing in absolute coords would seem
> > useful G38,6, 38.7, 38.8 and 38.9 are free
>
> So, one person on my side ;)
> It seems like it might be clearer to be able to do G53 G38.x, but
> adding more gcodes would work too!
>
> This it a little off topic, but currently any probe trip during a non
> probe moves causes an estop (good!). But, some times when backing off
> after a probe with G0 or G1 the probe bounces and causes the machine
> to estop, even though the probe is perfectly safe. So I have though
> about adding a probe backoff gcode, that is basically a G1 (or G0
> maybe) move that ignores probe input. Tormach uses a G38.6 for this
> ...
>
> So, I pondered a little more while cutting the grass today, what about
> having a probe code that probes the part, and then automatically
> retracts to the retract plain R? Who has ever probed with out
> retracting, right? SO might as well have this build in. It would also
> allow for ignoring probe trip on the retract move, which would be a
> really neat solution IMO.
>
Agreed. I record the co-ord at the 2nd slow moving contact, doing a 15 
thou retract with a g0 at first contact, then repeat for the real 
measurement at F.1, measure that and record it, back away with a g0 
about 15 thou to make sure the contact is broken, then start looking for 
the other side of the hole, calculate the center of that and goto it to 
look for the readings at 90 degrees to the first set, but I would never 
consider doing it at F80, in fact I generally do it at F5, retract 15 
thou, and then do the final measured probe at F.1 or .2.  You can't 
expect real accuracy if moving at an F80 on an inch machine. That makes 
the granularity of the measurement pretty bad. F80/servo-thread 
is .080".  Are you happy with that much of a +- to your measurements in 
inches? Maybe close enough in mm's, but surely not in inches. And my 
probe contact is a wire with a  lead wrapped around it to the probe 
input, mounted in the center of a 3/4 teflon rod, and the spindle is 
running at about 1.5k revs, so the wobbling tip of the probe is 
essentially a perfect circle, centered on the spindles axis.  I have 
a .1uf cap across the probe input so the first contact discharges it to 
a logic 0, with the cap being slow enough to recharge so as to still be 
a logic 0 when the next board servo-thread read takes place even if 
probe contact has been lost at that spindle position. My repeatability 
is typically .0004" thou.

Generally thats "close enough for the girls I go with"...

> > What happened to G38.1?
>
> Good question, if I try it I get "Unknown g code used", wonder why it
> was skipped, or maybe it was superseded??
>
> I am going to see if I can find where the probe stuff is, and try and
> wrap my head around it ..

-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Probe result parameters (5061-5069)

2018-07-27 Thread Kurt Jacobson 
On Fri, Jul 27, 2018 at 9:29 PM, andy pugh  wrote:

> On 28 July 2018 at 02:15, Kurt Jacobson  wrote:
>
> >> Good point. How about...
> >>
> >> G21 G91
> >> G38.2 z-20 F80
> >> G0 X#5061 Y#5062 Z#5063
> >> G10 L20 P1 Z0
> >>
> >
> > That would probably crash the probe,
>
> Unless I am missing something, it should be a move back to the exact
> point where the probe tripped?
>

Yes are correct, it works for the Z axis! It does not work on the X and Y
axes, as the probe tip diameter has to be taken into account and so the
probe would have to move towards the part by the radius of the tip. Of
course this could be avoided by moving up in z to clear the part ...
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Probe result parameters (5061-5069)

2018-07-27 Thread Jon Elson 
Here's a routine I use that probes the "lower left" corner 
of a part.

So, the probe is on the -X -Y corner.
It backs away a little in -X and then quickly probes in the 
+X direction,
then backs off and repeats at a much slower speed, and then 
sets #1001
to the offset between the probed position and the radius of 
the probe tip.
It then repositions past the corner and does the same 
routine for the Y axis.
Then it raises Z and goes to the calculated coordinates 
(right over the corner)
and then sets that as X0 Y0.  The second probe at lower 
speed can't even be
seen, it happens so fast.  But, it is needed to get 
consistent coordinates, as the

probe signal is only sampled at the servo period on my system.

This has worked very well, and I have a bunch of routines to 
probe the 4 external
corners and the 4 internal corners, plus one to pick up the 
center of a hole.


(probe LOWER LEFT)
g91 g1 F10 Y0.2 X-0.05
g91 G38.2 X0.5
G91 G1 F10 X-0.02
g91 G38.2 F1 X0.1
#1001=[#5061+.0763]
G91 G1 F10 X-.1
G91 Y-.4
G91 X0.4
g91 G38.2 Y+0.5
G91 G1 F11 Y-0.02
g91 G38.2 F1 Y0.1
#1002=[#5062+.0763]
(debug,X,Y   #1001 #1002)
G91 G01 F10 Z.3
G90 G01 F10 X#1001 Y#1002
G10 L20 P1 X0 y0
M02


Jon

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Probe result parameters (5061-5069)

2018-07-27 Thread andy pugh 
On 28 July 2018 at 02:15, Kurt Jacobson  wrote:

>> Good point. How about...
>>
>> G21 G91
>> G38.2 z-20 F80
>> G0 X#5061 Y#5062 Z#5063
>> G10 L20 P1 Z0
>>
>
> That would probably crash the probe,

Unless I am missing something, it should be a move back to the exact
point where the probe tripped?


-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1916

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Probe result parameters (5061-5069)

2018-07-27 Thread Kurt Jacobson 
On Fri, Jul 27, 2018 at 8:46 PM, andy pugh  wrote:

> Good point. How about...
>
> G21 G91
> G38.2 z-20 F80
> G0 X#5061 Y#5062 Z#5063
> G10 L20 P1 Z0
>

That would probably crash the probe, but a variant of that would work.

G21 G91
G38.2 z-20 F80
G0 Z[#5063 + .100] (move up a know amount from where the probe tripped)
G10 L20 P1 Z.100   (set out current location to the distance we moved)

But that gets a little dangerous, because the signs have to be right, and
if you are probing inside a hole or slot, then what do you do 


> FWIW I rather agree that probing in absolute coords would seem useful
> G38,6, 38.7, 38.8 and 38.9 are free
>

So, one person on my side ;)
It seems like it might be clearer to be able to do G53 G38.x, but adding
more gcodes would work too!

This it a little off topic, but currently any probe trip during a non probe
moves causes an estop (good!). But, some times when backing off after a
probe with G0 or G1 the probe bounces and causes the machine to estop, even
though the probe is perfectly safe. So I have though about adding a probe
backoff gcode, that is basically a G1 (or G0 maybe) move that ignores probe
input. Tormach uses a G38.6 for this ...

So, I pondered a little more while cutting the grass today, what about
having a probe code that probes the part, and then automatically retracts
to the retract plain R? Who has ever probed with out retracting, right? SO
might as well have this build in. It would also allow for ignoring probe
trip on the retract move, which would be a really neat solution IMO.


>
> What happened to G38.1?
>

Good question, if I try it I get "Unknown g code used", wonder why it was
skipped, or maybe it was superseded??

I am going to see if I can find where the probe stuff is, and try and wrap
my head around it ..
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Probe result parameters (5061-5069)

2018-07-27 Thread andy pugh 
On 28 July 2018 at 01:32, Kurt Jacobson  wrote:

> I have noticed several people using G10 L20 in their probing routines
> (presumably because it is easy), but it is not at all correct.
>
> Here is a snippet taking from a probing routine:
> ...
> G21 G91
> G38.2 z-20 F80
> G10 L20 P1 Z0
> ...
>
> This will not produce accurate results, as it assumes that the probe
> stopped immediately upon tripping, when in fact it has to decelerate,

Good point. How about...

G21 G91
G38.2 z-20 F80
G0 X#5061 Y#5062 Z#5063
G10 L20 P1 Z0

?

FWIW I rather agree that probing in absolute coords would seem useful
G38,6, 38.7, 38.8 and 38.9 are free

What happened to G38.1?

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1916

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Probe result parameters (5061-5069)

2018-07-27 Thread Kurt Jacobson 
On Fri, Jul 27, 2018 at 6:02 PM, andy pugh  wrote:

> On 27 July 2018 at 21:39, Kurt Jacobson  wrote:
>
> > There are significant advantages to having the probed pos be in ABS
> > coordinates, mainly because it makes it easy to set a WCS to the probed
> pos:
> >
> > G38.2 Z-.5
> > G10 L2 P0 Z[#5063]
>
> Is G10 L20 any help here?
>

G10 L20 set the current position to be the value specified by the axis
letters.
I have noticed several people using G10 L20 in their probing routines
(presumably because it is easy), but it is not at all correct.

Here is a snippet taking from a probing routine:
...
G21 G91
G38.2 z-20 F80
G10 L20 P1 Z0
...

This will not produce accurate results, as it assumes that the probe
stopped immediately upon tripping, when in fact it has to decelerate, so
will have over-shot the pos at which the probe tripped.
There are ways to use G10 L20 to set the WCO correctly, but they are not
clean or neat.

I believe that this is one of the main reasons almost all of the successful
probing routines for LCNC have been written in python, because the python
interface reports the probed pos in ABS coordinates, so makes it really
easy to set the WCO using G10 L2.

Thanks Andy!
Kurt
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Probe result parameters (5061-5069)

2018-07-27 Thread Gene Heskett 
On Friday 27 July 2018 20:10:36 Kurt Jacobson wrote:

> On Fri, Jul 27, 2018 at 5:12 PM, Gene Heskett  
wrote:
> > Somewhere in the gcode is a pair of commands that switch it
> > incremental<->absolute.  Yes g90 for absolute, and g91 for
> > incremental. Its also I think, switchable in the view pulldown.
> >
> > Does this not fix the g38.2 results too?
>
> Gene, G90 and G91 set distance mode, which has no effect on the
> coordinate system that is used.
> Being able to do a probe in G53 (machine coordinates) would be
> perfect, but unfortunately it is not permitted.

Hum, ok, then why is this not a bug? Seems like it ought to be filable as 
such. But I've had wishfull thinking shot down before...

Somebody that knows, please speak up?

> --
> Check out the vibrant tech community on one of the world's
> most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers



-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Probe result parameters (5061-5069)

2018-07-27 Thread Kurt Jacobson 
On Fri, Jul 27, 2018 at 5:12 PM, Gene Heskett  wrote:

> Somewhere in the gcode is a pair of commands that switch it
> incremental<->absolute.  Yes g90 for absolute, and g91 for incremental.
> Its also I think, switchable in the view pulldown.
>
> Does this not fix the g38.2 results too?
>

Gene, G90 and G91 set distance mode, which has no effect on the coordinate
system that is used.
Being able to do a probe in G53 (machine coordinates) would be perfect, but
unfortunately it is not permitted.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Probe result parameters (5061-5069)

2018-07-27 Thread andy pugh 
On 27 July 2018 at 21:39, Kurt Jacobson  wrote:

> There are significant advantages to having the probed pos be in ABS
> coordinates, mainly because it makes it easy to set a WCS to the probed pos:
>
> G38.2 Z-.5
> G10 L2 P0 Z[#5063]

Is G10 L20 any help here?

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1916

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Probe result parameters (5061-5069)

2018-07-27 Thread Gene Heskett 
On Friday 27 July 2018 16:39:56 Kurt Jacobson wrote:

> I asked this on IRC yesterday, but realize that was a bad format, so
> here goes!
>
> I have been helping Lcvette with a very simple probing GUI and some
> probing routines. The routines probes the top and then corner of the
> part and set the specified (not necessarily current) WCOs to the value
> of probed position.
>
> One thing that was unexpected is that the probed pos parameters
> (5061-5069) are relative to the currently active WCS. This is not
> clear from the description in the docs, and is not consistent with the
> values returned by `stat.probed_position` which returns the ABS
> position at which the probe tripped. It makes sense for the probed pos
> to be in ABS coordinates, since one of the main uses of probing is to
> set a WCS. All the commercial controllers I am familiar with report
> probed pos in ABS coordinates, Fanuc even uses the same param numbers
> as LCNC for the probed pos values, but they are ABS vs LCNC relative
> pos.
>
> There are significant advantages to having the probed pos be in ABS
> coordinates, mainly because it makes it easy to set a WCS to the
> probed pos:
>
> G38.2 Z-.5
> G10 L2 P0 Z[#5063]
>
> To get the same function as the Fanuc style parameters in linuxcnc
> requires something like this:
>
> (Get the current WCS Z offset)
> o100 if [#5220 EQ 1]  (G54, 5520 = current work space ID 1-9)
>   # = #5223
> o100 elseif [#5220 EQ 2]  (G55)
>   # = #5243
> o100 elseif [#5220 EQ 3]  (G56)
>   # = #5263
> o100 elseif [#5220 EQ 4]  (G57)
>   # = #5283
> o100 elseif [#5220 EQ 5]  (G58)
>   # = #5303
> o100 elseif [#5220 EQ 6]  (G59)
>   # = #5323
> o100 elseif [#5220 EQ 7]  (G59.1)
>   # = #5343
> o100 elseif [#5220 EQ 8]  (G59.2)
>   # = #5363
> o100 elseif [#5220 EQ 9]  (G59.3)
>   # = #5383
> o100 else (default to G54)
>   # = #5223
> o100 endif
>
> G38.2 Z-.5
> (Calculate the probed ABS pos)
> # = #5063 + #
> G10 L2 P0 Z[#]
>
> Having to use the if-elseif block is somewhat cumbersome, and needs to
> be done for each axis for which it is desired to set the WCO.
>
> So the question is, why did LCNC choose to use relative positions for
> the probe parameters? There must be a good reason to not follow what
> seems to be a standard among other controllers, but the only advantage
> I can see is when probing to measure/scan a part, but in that case it
> would be very easy to convert the ABS probed pos to relative by
> subtracting the WCO.
>
> Trying to think of ways to make the behavior more expected for people
> coming from other controllers, and at least make it clear in the docs
> . Would it make sense to change parameters 5061-5069 to be the ABS
> probed pos, or maybe allow using G53 with G38? I think it would also
> make sense if `stat.probed_position` was consistent with the
> 5061-5069.
>
> Anyway, interested to see what you all think. I am going to at least
> work on clarifying the parameter and python interface docs to better
> reflect what system the probed positions are in. If anything else
> could/should be done I will try to take that on as well.
>
> Thanks all!
> Kurt

Somewhere in the gcode is a pair of commands that switch it 
incremental<->absolute.  Yes g90 for absolute, and g91 for incremental.  
Its also I think, switchable in the view pulldown.

Does this not fix the g38.2 results too?

> --
> Check out the vibrant tech community on one of the world's
> most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers



-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers