RE: Probing

["Dean L. Hedin" <dhedin-at-vsi.net>]

>===== Original Message From emc-at-nist.gov =====
>Dean and Carl
>
>You guys just picked this time to bring up this topic because you knew that I
>had to get other things done but couldn't resist throwing in my2cw.
>

Well, In my case it's just that I have something I want to probe!

>Dean, that is a nice simple probe design for one that trips along it's axis.
>Excellent application of Occams razor.  Thanks for the pic links.
>

Thanks.

>Both of you have good thoughts.  First making the file man readable is an
>excellent start.  By including all of the essential probe info in a "front
>stuff" makes it possible to reproduce the scan easily or set a machine to
>mill to the way that the probe was accomplished.
>
>Several list members have talked a bit about making conversational front ends
>for the emc that hide the actual g-code and run from the conversation screen
>itself.  A probe file format like this would allow for a direct to g-code
>processor.  In this case we would run from some sort of screen that shows the
>point cloud and uses the "front stuff" and a few answers about the machine
>tool and paths to define the tool motion.
>
>An easy first mill from point cloud processor might simply mill point to
>point following the path of the probe.  A second step might be watermarks
>around the shape at various z heights.  Either of these methods could allow
>for roughing and finishing cuts.
>

Yes,  I can envision a "post proccessor" doing many things, like
asking the user for the size of the work piece and calculating rough cuts
etc..

>I can already visualize much of the Tcl code that would build an interface to
>produce or read the "front stuff" for the kind of file you describe.  The
>actual probing would simply be an iterated version of the guts of Will's
>existing probe script.  If we design the read/write to be flexible here we
>can add variables to the front stuff without raising an alarm and we can add
>values to a variable without changing the essential nature of the file
>produced.
>

I was actually thinking of writing the gui & front end stuff in a tcltk
script.   Then using an exec call to a "C" program to do the actual
probing.  There is a tool called "mktclapp" that allows "C" programs
to perform tcltk commands.  Since in the initial script emcsh was
run to extend tcl with emc commands, it should be possible to call
the emc functions from "C" using "mktclapp".  I really hope it works!
I dont want to learn all of tcl's string and i/o functions and I
have alot of C stuff in my "toolbag".   This will be my approach
unless someone can tell me a better way to interface to emc via
"C" without having to make probing part part of emc and forcing everyone
to recompile.  This method will also be platform independent.
"mktclapp" is ported to Windows.

>I recommend that the actual probe data be set up like this.
>
>xn.nnnn yn.nnnn zn.nnnn an.nnnn bn.nnnn cn.nnnn rn.nnnn pn.nnnn wn.nnnn
>
>with the spaces optional and the number of sig digits settable in the front
>stuff.  Perhaps you could choose 3 to six axes in the front stuff or simply
>use the number and names of axes as defined in the ini for the machine
>running the probe.

Good idea.  I will revise the file spec.

>
>Would we want a delimiter to end sections or would the left bracket of the
>heading for the next section be enough?
>

I chose the Window's ".ini" format since I already have canned routines
to read various data types from this type of file.  No delimiters
are required other than having "keystring=value"

>As Carl hints at for his hexapod, or for a 4-6 axis cartesian mill,  the
>project may begin with a six position code for each probed point, but it
>doesn't necessarily need to stay that way.  If we imagine a closed model in
>3d space, the shape is the same regardless of it's orientation or how you
>approach it with a probe or a cutter.  The extra abc or rpw info only tells
>us how we arrived at any point in the cloud.
>
>Dean correctly points out that the probing routine in the EMC is a true
>multidimensional thing.  You can probe along any 3d vector.  This feature may
>be an unnecessary complexity for may of us but for others may be critical.
>The traditional probe math that I've seen used for better probes required
>that we know the complete geometry of our probe and how it trips for any kind
>of touch.  Therein lies one of the values of the simplicity of Dean's probe
>when connected to Carl's hexapod.
>

I'll tell you what..Lets accomodate the >3 axis machines in the file.
However, lets get it working with just the 3 axis case first.  Then
extend it for more axis and various probing techniques


>So with that as my take on both of your posts, here are a couple of thoughts
>I'd like to toss in.
>
>1 - In the hexapod or six axis Cartesian machine, I imagine a 3d probe
>routine that would first take three points in a regular triangle near each
>other and figure a perpendictular to the surface and then probe from that
>perpendictular.  Repeat until the points do not move any more as the machine
>realligns for the new perpendictular and probes again.  At that point it
>would store the values to the probe file.
>

Ths is an interesting stradedgy, but I think it would take a long time
to probe something.  In fact I think it is going to take a long time to 
probe small objects with even the simple 3-axis case using a simple
grid.

None-the-less, I have accomodated the "Probe Stradedgy" in the file
should the software evolve.  We might have things like Cylindrical
probe method I mentioned earlier.

>Now the probe moves to make the next triangle from two points of the old one
>and repeats the process.  The only change that we would have to make to
>Dean's probe is a smaller tip.  We would also have to watch so that our
>initial three probes can push the tip into the light beam rather than simply
>bending the tip or moving or denting the part being probed.  Perhaps a second
>spring wound part way down the wire probe would be sufficient here.  I
>imagine a ball shaped spring like a mini whip used for cooking.
>
>I can also see some real advantages to taking a cut with a known angle to the
>surface to be cut.  But tangent, perpendictular, or whatever angle of cut,
>can be figured from the point cloud itself and would not necessarily need to
>be kept.

This is true, and is why I have the probe description in the file.
Let the post-processor figure out the tool compensation.

>
>2 - My notion of successive approximation might speed up the probing of
>complex shapes.  For successive approximation.  The first granularity might
>be rough, say 0.1 using the start point of the cube defined by
>
>>[Region 0]
>>Start_x=nn.nnn
>>Start_y=nn.nnn
>>Start_z=nn.nnn
>>Min_x=nn.nnn
>>Max_x=nn.nnn
>>Min_y=nn.nnn
>>Max_y=nn.nnn
>>Min_z=nn.nnn
>>Max_z=nn.nnn
>>Granularity_x=
>>Granularity_y=
>>Granularity_z=.
>
>The probe might plunge the first 0.1 triangle and if it finds nothing move to
>the next.  If it finds something it switches to the finer granularity and
>saves points in much the way that you describe regions.  Some vague step
>models that were used to explain the Calculus come to mind here.  You could
>repeat this for finer granularities as needed for the specific project.
>

Yes, and for the simple 3-axis probing that we have discussed earlier
we thought that and adaptive rapid z height could be used, where the
algorythm esimates where the next Z is. This is dangerous for the simple
probe switch that I have made for model surfaces that have rapid step
changes in height.


>3 - I'd eventually like to see provision for more than a 3d cube shaped probe
>area.  My previous thinking was that we might teach or enter the first point,
>and then do the same for the second.  Lines parallel to the line between
>these first two would be the aproximate probe path for that region.  Then you
>could define points 3 .. n and this would be the shape of the region on the
>first plane.  A few points on the third axis might be used to draw a tent
>over the shape.  The idea of this is to allow for quicker probing of odd
>shapes because the polygon would cut off area outside the shape and the tent
>would shorten the length of the probe vector.
>
>I have probably succeeded in muddying the water here a bit.  Keep talking.
>I'll be out for a week but don't wait for me.  I'd like to see a
>deanprob1.prb file posted by the time I get back.<g>
>
>BTW - You guys bringing this stuff to NAMES?  Anything I could do to
>encourage that?
>
>Ray
>



Nobody ever answered my question.  With EMC, on a hexapod, in g-cod
can you create a temporary coordinate system where the Z axis is
along the axis of the bit AND the head is at some arbitary roll, pitch
& yaw?  So that subsequent position commands are with respect to this
arbitary oriented cartesian coordinate system?