Welcome, Guest. Please login or register.
Did you miss your activation email?
April 24, 2017, 07:53:58 PM

Login with username, password and session length
Search:     Advanced search
* Home Help Search Calendar Links Login Register
+  Machsupport Forum
|-+  Mach Discussion
| |-+  General Mach Discussion
| | |-+  edge finding/2.5D probing
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18   Go Down
Print
Author Topic: edge finding/2.5D probing  (Read 67354 times)
0 Members and 2 Guests are viewing this topic.
stirling
Global Moderator
*
Offline Offline

Posts: 2,189

UK


View Profile WWW
« on: October 01, 2007, 05:49:54 AM »

Hi - As I understand it there are no macros/wizards/plugins currently available in Mach for this - i.e. you're on your own with G31. Is this correct?
Logged

vmax549
Guest
« Reply #1 on: October 01, 2007, 07:03:40 AM »

THat is correct at this time. SOme of us have written simple macros to do simple Probing. The real problem is that Mach cannot correct itself for probe tip radius compensation or probe touch/trip movement error before it recorded the data so it makes it impossible to know what the true touch position is.

Art has his thinking cap on concerning the G31 so hopefully we will have a solution soon. I keep poking at him from time to time about it (;-)

Once that part is fully functional it should be fairly simple to create a plugin to do CMM type 2.5d probing with Mach recording the session as you go......

Might want to help remind him from time to time.

(;-) TP
Logged
stirling
Global Moderator
*
Offline Offline

Posts: 2,189

UK


View Profile WWW
« Reply #2 on: October 01, 2007, 08:16:17 AM »

Thanks TP

SOme of us have written simple macros to do simple Probing.
Could you point me at a couple of examples please?

The real problem is that Mach cannot correct itself for probe tip radius compensation or probe touch/trip movement error before it recorded the data so it makes it impossible to know what the true touch position is.
Could you expand on this a little please?

Are these shortfalls restricted only to 2.5D probing? if so, why do they not affect 3D probing in the same way?

Might want to help remind him from time to time.

Hmmmmm - I may be on his back pretty soon about CV - don't want to be too heavy on the man Grin

Ian
Logged

vmax549
Guest
« Reply #3 on: October 01, 2007, 10:20:11 AM »

Hi IAN,  THe 3d approach to probing currently used is known as the bed of nails approach. It is basically probed with just the z axis going up and down and the positions are moved by the xy axis. The height of z when it trips is recorded along with the xy position. The height of the z is really only relative to the reference height of the part. In the trip point file the only thing relative is the relation of the lowest and highest points as a reference so the true position of z is not needed and the position of xy is relative only to the grid you probed on. You will end up with 1000s of points that have to be converted to a skin, later to be carved out by MACH
 
In CMM type probing you are actually probing in the x,y and z planes and the radius of the probe tip AND any movement error associated with the length of the probe arm AND the direction of axis TRAVEL  HAVE to be corrected to give you the exact touch point center line. THat way you have an exactly replication of the coordinate values needed to recreate the surfaces probed. You will only need the coordinates neccassary to recreate the surface. For a straight surface you will only need a start point end point and a base height and top height point to draw the surface. For curves you will need to collect curve data in order to recreate it..

Please don't be TOO hard on them about the cv. It can be a beast to impliment across the extremely broad range of equipment types it is being used on.
It would be a piece of cake if it was only used on one exact type of machine. Then it could be fine tuned to the conditions relatively easy. I find most problems are machine/operator generated. Too small of drives for machine, and too fast of settings for conditions, or getting heavy on the FRO (;-)



Hope that helps (;-) TP

« Last Edit: October 01, 2007, 10:28:24 AM by vmax549 » Logged
stirling
Global Moderator
*
Offline Offline

Posts: 2,189

UK


View Profile WWW
« Reply #4 on: October 02, 2007, 10:36:53 AM »

Hi TP - thanks for your reply

the radius of the probe tip AND any movement error associated with the length of the probe arm AND the direction of axis TRAVEL  HAVE to be corrected to give you the exact touch point center line

Understood - but isn't this a problem that can be solved by either post-processing of, or on-the-fly-processing of the data? What I'm getting at is that there seems to be the idea that currently 2.5D probing can NOT be achieved in Mach. Is it not simply the case that no-one has yet written a plugin/wizard whatever to do it?

i.e. I'm thinking of writing one - I have all the algorithms worked out and tested but if there's something that Mach can't do (that I don't know about) then I'll shelve it for the time being.
Logged

vmax549
Guest
« Reply #5 on: October 02, 2007, 12:54:52 PM »

Hi Stirling,  YES A plugin CAN be constucted as it is. But it will be a beast to impliment. Yes you can do the coordinate value corrections on the fly  after collection/posting. BUT there is a lot a variables involved to do it as a whole. If we wait until ART gets the G31 worked out for CMM type collection it will be a breeze as Mach will do the hard part for us. I think he has a plan worked out but just needs a liitle time to refine it.

I do this all the time with a  collection of probing macros and even using the MPG and a special MACH page with AXIS directional DROs and trip indicator LEDS  but do the actutal corrections by hand as well as the recording of the points. Pencil, paper and calculator method(;-)  WHile wating on ART to get enough request to make it worth his time and effort. It is really hard to justify the time and effort for just a few users. WHEN the masses figure out how USEFULL it really is THEN the light will come on.(;-)

Some things to think about

Tip radius correction
probe arm movement error  and ratio corrections
4 axis movement correlation +/- directions of each to know in which direction the compensation  applies.

THe current G31 movement will NOT allow you to jog off the trip point you must make a gcode move off the trip THEN you can resume a jog mode. I believe G31 is a JOG mode in itself.

A logical ordering of points collection

(;-) TP
« Last Edit: October 02, 2007, 01:07:58 PM by vmax549 » Logged
stirling
Global Moderator
*
Offline Offline

Posts: 2,189

UK


View Profile WWW
« Reply #6 on: October 05, 2007, 06:11:45 AM »

My thinking is that Art & co. probably have enough on their plate at the moment so I think I'll go ahead and have a go. First I'll make a probe and try Art's wizard.
Logged

stirling
Global Moderator
*
Offline Offline

Posts: 2,189

UK


View Profile WWW
« Reply #7 on: October 09, 2007, 10:00:57 AM »

OK so I now have myself a working probe. However I've hit the first snag and am wondering if anyone can help me through it.

It seems that there is no way of telling with G31 whether the probe actually gets tripped or not.
i.e. at the end of G31 it stores X,Y and Z in machine params 2000, 2001 and 2002 whatever happens.

For example: if I start at X0 and have an obstacle at X100 and program G31 X120 then I get (correctly) 100 in parameter 2000.
However if I program G31 X80 I get 80 in parameter 2000 whereas I would have expected some sort of error indication.

Anyone know how to tell if the probe is actually tripped?
Logged

vmax549
Guest
« Reply #8 on: October 09, 2007, 12:39:01 PM »

Sure can, look on the diagnostics page there is a LED that indicates when the probe trips. You need to include this check to see if the probe trips(ledon) before you hit the axis probing limit. It would tell you 1. the probe did not trip or 2. the trip point was beyond the axis probing limits. Therefore you need to repeat that move to try and verify a nontrip due to a probe error.

(;-) TP
« Last Edit: October 09, 2007, 12:41:38 PM by vmax549 » Logged
stirling
Global Moderator
*
Offline Offline

Posts: 2,189

UK


View Profile WWW
« Reply #9 on: October 09, 2007, 01:35:36 PM »

Hmmmmm. I tried that but there's a problem. If I drive into an obstacle with a jog, or a G01 or a G00 then the LED changes state. BUT if I drive into an obstacle with a G31 it doesn't, even though the trip has been actioned by Mach.
I even tried reading the parallel port with a GetPortByte and that doesn't work either with a G31 but does with a jog, G01 or G00.

I'm beginning to think that there are more issues with G31 than you/me/we thought - I'm even thinking of writing my own simulation of a G31 with a G01 and testing the LED as you've suggested.

Any thoughts?

Logged

Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18   Go Up
Print
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.20 | SMF © 2013, Simple Machines Valid XHTML 1.0! Valid CSS!