Re: Probing

[Ray <rehenry-at-up.net>]

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.  

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.

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.

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 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.  

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

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.

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.  

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.

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.

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


On Sunday 13 January 2002 09:27 pm, you wrote:
> On Sunday 13 January 2002 12:17 am, you wrote:
> > Dean,
> >
> > I have a probe tip on my Stewart Platform 6-axis machine.  Could we
> > consider adding rotation axes as well?  P (pitch, about the X axis), R
> > (roll, about the Y axis), and W (yaW, about the Z axis).
> >
> > So far, I'm not using the probe tip to sense forms, but instead to set
> > the Z-axis reference for accurately carving into warped wood.  One day,
> > though, I hope to get involved in creating "point clouds", and fitting
> > surfaces to them.
> >
> > -- Carl
>
> I am now sitting here imagining a small statue inside a hexapod getting
> probed in cylindrical coordinates.  Is this what you have in mind?
>
> The tcltk interface provides us with:
> emc_probe_move: <x> <y> <z>
>
> So I assume that your current Y,P, & R stays constant as the tool head
> moves towards the probe coordinate.
>
> The problem we have here is defining regions with 6 axis along with
> an appropriate probing "path".
>
> In the 3-axis case I am only considering that Z will be the direction of
> interest.
>
> A simple case could be achieved with the hexapod where the Y,R & P are
> fixed thoughout a probing  "XYZ" region.  But I am not convinced that this
> would be of any value.
>
> Let me ask you the following: With the hexapod & EMC's interperter, can you
> establish a temporary coordinate system where the Z axis is along the bit's
> current axis (assuming your tool head is at some arbitrary Y,R &P) ?
>
> Such a translation would be quite useful (even not considering probing).
> If such a coordinate translation is possible on a hexapod using EMC,
> then it would be easy to accomodate in the file format proposed (as well
> as the probing algorythm)
>
> We simply tilt the tool head to the desired Y,R&P and then move
> to a starting coordinate, then follow the region definition previously
> described.
>
> FYI, Probing will always be imperfect. Consider the following little
> thought experiment:
>
> We are on a 3-axis machine and I take a small cylinder and I cut it
> longitudelly in half and lay it on the table flat side down. I probe this
> 3d surface with a probe shaped like a normal cylidrical router bit.  I then
> create some g-code from this point cloud.
>
> I then machine a block of material using this g-code with a bit that
> matched the probe.  I end up with little ridges along the raising & falling
> arcs of the surface but no ridges along the top.  If I take very small cuts
> I can minimize these ridges but I can't get rid of them.
>
> So I say! Ahah! I'll put it on a hexapod and I'll probe it in cylidrical
> coordinates!  That will get rid of the ridges by keeping the bit
> perpendicular at all times!
>
> But this required that you had some prior knowledge of the object being
> probed!  The whole idea of probing  is that we do not know how to easily
> write a tool path (or a probe path) for some arbitary 3d object.
>
>
> BTW, I put the pics up of my home-brew optical probe switch if anybody is
> interested:
>
> http://web.starlinx.com/dhedin/dcp00468.jpg
> http://web.starlinx.com/dhedin/dcp00469.jpg
> http://web.starlinx.com/dhedin/dcp00470.jpg
> http://web.starlinx.com/dhedin/dcp00471.jpg