re:Digitizing

Gordon R wrote:

>It seems to me Roland (as well as Centroid) has the right idea.
>since any digitizing to a high degree of accuracy would take a long
>time due to the literally thousands of XYZ or XZA points to be
>tabulated, the best solution might be to have a program work as
>follows:<big snip>
>With a system I've just decribed, the probe should not need all
>those 3D movements everyone is trying to build in. All the probe
>would need is simple up and down movement.
>Comments anyone?

Smoke,

What you've described is a 'typical' means of digitising. BUT...

You still need the 3D probe!

Picture digitising an older model truck (with a steep front
windshield angle). As the probe moves down, it will be
stressed 'sideways', and since it only "opens" the circuit in
the 'up/down' direction, it is reasonable to think that the downward
motion will continue until either the sideways component binds or
bends something, or the single axis switch(of the probe) is tripped.
At different probing points (on the 'grid'), the effect may be
increased if the probe has a ball tip. At other probe points, the
effect will be worse with a pointed tip probe (like the roland). Can
you visualise this?

The point is (pun intended) 'sliding down' the surface, moving
slightly sideways as it goes, either binding or 'clicking' at some
arbitrary point (due to the single axis actuation). Allow the probe
to 'click' in any direction and the problem disappears... The
sideways component of the vector(the sloped surface being probed)
will open the switch.

Next problem with "grid" based probing. Visualise a 'stepped' surface.
(one step up, like this:
oo__________
___________| Real part

The o's represent the probe tip in two grid point positions (up
position shown).

You can see that the first one has not reached the vertical step (it
will probe down until it hits the flat surface below). The second is
poised directly above the vertical step. It will probe til it reaches
the upper flat plane. The result of these two probed points will
define this:
oo__________
_________/ Probe Data-derived part

Clearly not an accurate representation of the probed surface!

My guess is that the 'extra' moves your Roland does is based on some
algorithm designed to minimise this sort of error (whether it's a
GOOD algorithm is a DIFFERENT question :-) )

Now instead, if the program drops down to the 'flat',Clears itself by
moving up one step, then begins moving toward the next grid point, it
will 'sideways trip' at the vertical wall. If the program is smart
enough to remember which direction it was moving when it tripped (and
using the concept of PRIORITY axis I mentioned earlier. i.e., clear z
first) it will move 'up' to 'clear' the probe input, which will not
happen until the top is reached (assumes a truly vertical surface).
At THIS point,(those puns again) the program 'should' data-log the
position, even tho it's NOT on the grid! Then TRY to complete the
move to the next grid point. In THIS case, we'll get there(since the
surface is flat) and begin the downward(priority movement first)probe
again...

Even better it will 'log data' at both the top AND bottom of the
vert. wall, but this will require some 'smarts' to recognise
the 'shape' that the probe is moving over, based on the 'tripped'
points. A pre-processor which logs ALL 'trips', then analyses whether
they should be output to the 'logged' file... Sort of a 'look-behind'
to see which of the 'stops' are worth 'remembering'...

This means the grid points will be the MINIMUM number of probe points
logged, and that features lying BETWEEN grid points are recognised.

Hope this helps.

Ballendo