CAD CAM EDM DRO - Yahoo Group Archive

Re: [CAD_CAM_EDM_DRO] re:Digitizing

Posted by Marcus & Eva
on 2001-01-08 08:28:51 UTC
Hi All:
I have been following the digitizing discussion with interest.
What I haven't yet seen, is a comment on how to minimize the crash potential
caused by the issue Ballendo raises below.
When I plan a complex 3D milling job, I tailor the toolpath orientation to
the general shape of the part that I'm trying to cut.
What's wrong with tailoring the probing routine to the general geometry that
you are trying to more fully define?
This way, on the steep sided part of the geometry, you would set up
successive Z level passes, while on the flatter portions, you would set up X
parallel, Y parallel, Flowline or some other probing routine that maximizes
the accuracy of your result by plowing the probe point as nearly
orthogonally into the surface as possible.

Is this how it is done on CMM's?

Cheers
Marcus

-----Original Message-----
From: ballendo@... <ballendo@...>
To: CAD_CAM_EDM_DRO@egroups.com <CAD_CAM_EDM_DRO@egroups.com>
Date: Sunday, January 07, 2001 4:16 PM
Subject: [CAD_CAM_EDM_DRO] 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
>
>
>
>
>Welcome to CAD_CAM_EDM_DRO@...,an unmoderated list for the
discussion of shop built systems, for CAD, CAM, EDM, and DRO.
>
>Addresses:
>Post message: CAD_CAM_EDM_DRO@egroups.com
>Subscribe: CAD_CAM_EDM_DRO-subscribe@egroups.com
>Unsubscribe: CAD_CAM_EDM_DRO-unsubscribe@egroups.com
>List owner: CAD_CAM_EDM_DRO-owner@egroups.com, wanliker@...
>Moderator: jmelson@... [Moderator]
>URL to this page: http://www.egroups.com/group/CAD_CAM_EDM_DRO
>FAQ: http://www.ktmarketing.com/faq.html
>bill,
>List Manager

Discussion Thread

Jon Anderson 2001-01-07 16:09:10 UTC Re: [CAD_CAM_EDM_DRO] Digitizing ballendo@y... 2001-01-07 16:14:36 UTC re:Digitizing Fred Smith 2001-01-07 18:14:46 UTC Re:Digitizing Jon Elson 2001-01-07 20:21:46 UTC Re: [CAD_CAM_EDM_DRO] Digitizing Smoke 2001-01-07 22:35:29 UTC Re: [CAD_CAM_EDM_DRO] Re:Digitizing Smoke 2001-01-07 22:49:47 UTC Re: [CAD_CAM_EDM_DRO] re:Digitizing Jon Anderson 2001-01-08 07:47:47 UTC Re: [CAD_CAM_EDM_DRO] Digitizing Marcus & Eva 2001-01-08 08:28:51 UTC Re: [CAD_CAM_EDM_DRO] re:Digitizing Bill Phillips 2001-01-08 13:55:04 UTC Re: [CAD_CAM_EDM_DRO] Digitizing Greg Nuspel 2001-01-08 14:02:31 UTC Re: [CAD_CAM_EDM_DRO] Digitizing diazden 2001-01-08 15:15:53 UTC Re: [CAD_CAM_EDM_DRO] Digitizing ballendo@y... 2001-01-08 17:05:13 UTC Re: re:Digitizing dave engvall 2001-01-08 17:20:30 UTC Re: [CAD_CAM_EDM_DRO] Re: re:Digitizing Jon Elson 2001-01-08 23:45:05 UTC Re: [CAD_CAM_EDM_DRO] Re: re:Digitizing nelap2002 2004-01-04 21:29:52 UTC Digitizing Graham Stabler 2004-01-05 04:37:03 UTC Re: Digitizing ccq@x... 2004-01-05 08:07:52 UTC Re: [CAD_CAM_EDM_DRO] Digitizing cnczeus 2004-01-05 09:20:29 UTC Re: Digitizing Alan Marconett KM6VV 2004-01-05 12:23:49 UTC Re: [CAD_CAM_EDM_DRO] Re: Digitizing Graham Stabler 2004-01-06 04:45:09 UTC Re: Digitizing Alan Marconett KM6VV 2004-01-06 12:20:10 UTC Re: [CAD_CAM_EDM_DRO] Re: Digitizing alex 2004-01-06 12:32:32 UTC Re: [CAD_CAM_EDM_DRO] Re: Digitizing Alan Marconett KM6VV 2004-01-06 12:51:45 UTC Re: [CAD_CAM_EDM_DRO] Re: Digitizing alex 2004-01-06 13:52:08 UTC Re: [CAD_CAM_EDM_DRO] Re: Digitizing Alan Marconett KM6VV 2004-01-06 15:29:08 UTC Re: [CAD_CAM_EDM_DRO] Re: Digitizing alex 2004-01-06 15:37:24 UTC Re: [CAD_CAM_EDM_DRO] Re: Digitizing Graham Stabler 2004-01-06 17:05:46 UTC Re: Digitizing alex 2004-01-06 17:11:07 UTC Re: [CAD_CAM_EDM_DRO] Re: Digitizing Alan Marconett KM6VV 2004-01-06 17:15:10 UTC Re: [CAD_CAM_EDM_DRO] Re: Digitizing alex 2004-01-06 17:20:28 UTC Re: [CAD_CAM_EDM_DRO] Re: Digitizing