Hi Ted,
disclaimer first: I learned mechanics as my first education some 10+
years ago, but have since then moved more into electronics and software.
So my experience with "real machining" is rather limited.
If I understand correctly, your goal is that you can approach a surface
with the stylus in "any way" in multiple points and then compensate the
stylus tip diameter in software, right? I might be mistaken, but that
feels like it is going to cause rather much trouble. First of all, the
stylus certainly isn't 100% rigid, so the coordinate that you end up
with will depend greatly on the force applied. What I know from my
experience is having something like that on a mill:
https://www.saratools.com/supplyImagesHeiler-700x700/4c%20558001%200001%20Info.png
There is a spherical probe tip of some diameter (doesn't matter for
using it) and a dial. When you approach the part, the tip will be
displaced, until you get the dial to read 0. When this happens, you know
that the spindle center is now aligned "exactly" to the surface of the
part, no matter from which direction it is approached. So no worrying
about the movement vector and the tip diameter and the force is also
constant, since it is defined by the spring in the probe. This also
works for Z, given that you know the length of the probe from the
reference plane to the theoretical tip when it is fully displaced. For
an electronic system, this would mean to have a comparator switching
when the dial reads 0, causing the momentary axes positions to be read
out at this very moment. I think that same approach is used also in the
only measurement machine (TESA) I've ever seen in action.
Just my thoughts. It is well possible that you know all this already and
I just got you wrong :)
Best regards,
Philipp
On 22.04.22 17:14, Ted wrote:
Good morning!
I've been working on converting an old Cordax CMM to more current
technologies and am wanting to start building out the user interface.
(The basic items like changing out for glass scales, reworking the air
bearing controls, tramming and getting a digital probe on the end,
initial interfacing to LCNC are already done and functional; it's now
time to get to the math taken care of).
The TL-DR version of my goal is to create some version of a manual CMM
interface like MCOSMOS(tm) in function, (that software is one of many
popular commercial CMM control packages currently available today). I'm
not wanting this to necessarily become the next open-source CMM
alternative - just something that can be functional and extend the
knowledge-base with LCNC. Thus, it's a hobby project, not a commercial one.
Note that this is NOT a probing-routine challenge; this is not meant to
retrofit a cartesian machine with the existing hole-probing under
machine control. In fact, I do not want it to be forced to be "CNC" (or
DCC for us old folks) - which is why I want to concentrate on the manual
math first. When it eventually becomes DCC, that's fine, but to try that
first would actually be a path that would involve a little cheating as
well as constrain possibilities.
To that end, I'm looking for some assistance in a) where to get some
LCNC realtime variable data, b) how to deal with some certain variable
types in c (in a halcomp) and c) some thoughts on best practices for
that same programming. I'm quite familiar with John's gtk tutorial
(https://www.gnipsel.com/linuxcnc/gui/index.html) and have referenced it
many times (thank you!) while creating custom guis (such as for press
brakes and punches) and also like some of the info from (Presei's?)
qtdragon work
(https://linuxcnc.org/docs/devel/html/gui/qtvcp.html#_handler_file_in_detail).
The first big math challenge I would like to solve, and something that
even MCOSMOS is a little lax on is vector-defined probing offsets. I
don't have a good name for that, but it's what I'm going to call it. In
a traditional in-spindle probing scenario, say a round hole, you set up
your probe with an assumed-diameter precision tip (ie ruby sphere),
calibrate using a ring gauge or similar artifact, then make a single
radial or a single length offset for that tip. In most cases, it gets
distilled down to an averaged radial offset and a single length offset -
since that is the base structure of how tools are handled, and a spindle
probe has to be fit into that construct. This does work ok for probing
to +/- a couple thou, and since that is often a good capability of
cutting, the results match up acceptably. On a CMM, we are not
constrained to a single vertical probe shaft, nor orthogonal probing
approaches, nor tolerances that can be averaged out to a single offset.
For example, my CMM now has micron scales. The stylus has more than 1
micron runout, and since it is not being spun, there is no averaging.
(Note: don't spin your probes in the spindle under power. I didn't mean
to infer that.) More so, I can approach a feature from any physically
available angle, which means I really do need to calibrate on multiple
points. This is known practice already, and if I were using MCOSMOS, I
could set up my stylus offsets for anywhere from 6 to over 30 (? - don't
know I've never done that many) approach offsets. I would like to do the
same in LCNC. As a side note, I don't think even MCOSMOS takes
vector-based touches into approach, I think it just runs a lot of
best-fit math because you can really confuse it if you try to measure an
inside bore when you specified an outside feature...
So to get to the point (no pun intended) I am comfortable with the math
to infer radius and sphere centers from surface points (even though I
don't like matrix math) - but I need to find two more pieces of
information:
a) if from a python (or c-ish) script get the current vector of travel
in 3d space? I am not sure if there is such a data value available, so
would I have to create some form of time-domain capture loop (say on 0.1
second intervals) as you need 2 coordinates to infer a vector component.
Are there velocity variables exposed I could access, and if so, are
there any best practices on capturing that information? I think if there
has been any work done on profile probing that might be a reference? I'm
not sure if I've seen any hal components doing polar conversion math yet...
b) how can I pass on multi-dimensional arrays through a hal component?
I'm not even sure what the workflow for this data is yet, but if I had
to make an example, a struct of a 4-component XYZQ vector (thus 4
doubles or floats,the "q" is just a 4th future coordinate) that then had
4 instances of that struct (to give 4 touch coordinates, or future
thinking, perhaps more) - how could those be programmed and passed to a
hal component? I have examples for single arrays (using the dotted
notation) but my first pass on doing multi-dim arrays using that type
(and simply by double dotting) was not successful. (I am comfortable in
c++, my python and ansi C is less refined...so variable typing knowledge
is google-fu dependent)
For b) the intent is to be able to create smaller fast-run components
such as:
"cmm-sphereo-from-4-points" - which takes in 4 coordinates and
returns center plus radius - note there is no approach vector info on
this one, it's 4-xyz's in, and 1 radius, 1 xyz out.
"cmm-spherotouch-center" - which takes current machine coordinates,
known center reference coordinate, known radius (from above), the
approach vector coordinates and returns a difference which becomes an
offset for the calibration table.
"cmm-coord-vector-offset" - which might take the approach vector,
the tool/stylus number, have to lookup a tool/offset table for
calibration data and then returns a single corrected xyz coordinate
"cmm-3pt-inbore" - which might take 3 xyz corrected from above and
calculate an inner bore radius and center
"cmm-6pt-inbore" - which might do same as above but finds an
evolving tolerance band based upon iterating through elements 1,3,5 then
2,4,6 -(possibly more combinations) etc.... returning same as above but
largest fitting result and smallest fitting result.
-and so on, which would also then permit creation of wizard-based
programming in the gui to create measuring recipes which could be saved,
edited, recalled, run, data output, etc. The important thing to notice
is the requirement for many multi-dimensional data values....
The functional result would be to:
a) first use a probe of zero-size - not physically possible, but
lets substitute "really pointy". We can then calibrate the system to a
known sphere, eg a precision tooling ball, and those first captured
coordinates can then be fed into the sphere map to give us a confidence
on the size of the ball and its position. This is not really part of the
calibration procedure, but just to ensure that our basic programing
understanding is correct, and that we can actually figure out where the
center of a sphere is. We are restricted to points on the sphere the
probe can reasonably access, but hitting 40% on top is quite feasible,
assuming a vertically mounted probe.
b) confirming the sphere properties, now we have a known/accepted
center position and radius, which we can now move to a non-zero-size
stylus (real probe ball) and using that known sphere data plus the
approach vectors, back-calculate the offset and stuff it into a
calibration table (note that this also takes into consideration the
probe actuation offset since it is unique to the approach vector). We
have made an assumption that the tooling ball is precise, and that is an
acceptable assumption. We are not assuming the ball is mounted in a
particular symmetric location, which is what a single radial offset does.
c) now with approach vectors and a "Triggered current machine
coordinate" we can now forward-calculate a feature coordinate. I don't
need to know right now if it is inside a bore or outside a boss, it's
just the "real" world coordinate of some physical transition from void
to part, but we also happen to know the travel vector from void to
contact as a side-effect, so we could infer inside or outside based upon
if multiple approach vectors would intersect on an internal or external
virtual sphere....
d) now we have datasets to work with, whether that next step is
setting up a virtual work plane, or actually getting coordinates to
define a hole.
There are other math items like what is the best fit for an approach
vector that is close but not exactly as calibrated? That is important
too, but baby steps, right?
Thoughts and opinions appreciated,
Thanks,
Ted.
_______________________________________________
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
