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
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
