All may not be lost yet. From what I can tell your interest is in the 3D probing rather than 2.5D and you'd just (ideally) use the 2.5D to produce the boundary for the 3D probing routine - is that correct?

If so, then you don't HAVE to use the 2.5D routine to create the boundary. You can create that by any number of means, even by hand and feed it into the 3D routine. Check out the attached image and you'll see what I mean. This shows a table with the object (the rough star shape) to be (3D) probed overlapping the table. The small circles show the points (at some arbitrary stepover) that need to be probed and of course the small crosses represent wasted probing in standard routines. The arrows show the points that you could enter into the triplet file by hand, in this case 17 of them. Depending on your amount of "waste" space and the complexity of your object you may find it worthwhile to try this approach. Remember your boundary profile doesn't have to be hugely accurate to cut down dramatically on the waste probing. This example has a saving of nearly 40% over standard routines (crosses / (crosses + circles) * 100)

All may not be lost yet. From what I can tell your interest is in the 3D probing rather than 2.5D and you'd just (ideally) use the 2.5D to produce the boundary for the 3D probing routine - is that correct?

If so, then you don't HAVE to use the 2.5D routine to create the boundary. You can create that by any number of means, even by hand and feed it into the 3D routine. Check out the attached image and you'll see what I mean. This shows a table with the object (the rough star shape) to be (3D) probed overlapping the table. The small circles show the points (at some arbitrary stepover) that need to be probed and of course the small crosses represent wasted probing in standard routines. The arrows show the points that you could enter into the triplet file by hand, in this case 17 of them. Depending on your amount of "waste" space and the complexity of your object you may find it worthwhile to try this approach. Remember your boundary profile doesn't have to be hugely accurate to cut down dramatically on the waste probing. This example has a saving of nearly 40% over standard routines (crosses / (crosses + circles) * 100)

This is what I meant, thanks.
 I'll look into in depth over the weekend, thanks

Two questions in the mean time:
The triplet points, are they the exact object boundary or boundary offset by probe radius?
how precise do the triplet point have to be(within backoff)?

as for efficiency there is another point. Compared to the 3D pluggin: the pluggin reduces the stepover of one direction in relation to the ratio of the size of the individual values for X and Y probing area. So the time increases in proporion to the ratio of the probing area.

If so, then you don't HAVE to use the 2.5D routine to create the boundary. You can create that by any number of means, even by hand and feed it into the 3D routine.

...minor glitch, the X&Y values in probe3d.tap have been all rounded to integer vaues. This makes me conflict with softlimits.
I have tried saving probe25d.csv as *.rtf and *.txt but still no good.

Any advice?

Bang head on keyboard... Thanks for spotting this and letting me know - It's now corrected - my apologies.
please download probe.zip again from http://www.razordance.co.uk/probe25D.htm

No need to go through the whole install again just unzip and copy the patch RazorProbeCtrl.exe over the original (in your case E:\programs\wherever...)

Thanks

Ian

PS - sorry - missed your two questions in your earlier post.

The triplet points, are they the exact object boundary or boundary offset by probe radius?

At the moment it seems the G31 command is in a bit of a state of flux in Mach. There are mentions here and there about whether Mach records on the approach or backoff and whether tooltip radius comp is implemented or not, but to be honest I'm not sure what the state of play is. That's why I've added in the touch point corrections tab. My way of calibration is to probe into an object at a known position, see what Mach says that position is and set the correction on the corrections tab.

A typical setup scenario would be to mill yourself a pocket (or island - doesn't matter) then probe it and apply corrections on the tab until the points file is correct. Your probe should now be calibrated for use with my software regardless of how G31 actually works.
 

how precise do the triplet point have to be(within backoff)?

Not sure I understand you here. Can you expand a little. But if it helps - don't confuse MY backoff with any G31 (internal) backoff. G31 (I think) backs off a small amount after a touch - this is when (I think) it records the point. Some seem to think this is some sort of advantage (as opposed to recording the point on approach). Personally I'm unconvinced it makes any difference at all - but I'm open to learn. My backoff is part of the perimeter walking logic and has to do with a compromise for handling the current "slope" of the perimeter being probed. somewhere around 50-70% should generally be good.

Bang head on keyboard... Thanks

Quote from: looker1 on December 07, 2007, 10:19:37 AM

The triplet points, are they the exact object boundary or boundary offset by probe radius?

Quote from: looker1 on December 07, 2007, 10:19:37 AM

how precise do the triplet point have to be(within backoff)?

Not sure I understand you here. Can you expand a little. But if it helps - don't confuse MY backoff with any G31 (internal)

I don't think I made my question clear enough...
I'll manually enter triplets to create the 3D probe path because my object surpasses the table boundaries similar to your example.

So, The triplets that I manually enter into probe25d.csv ....are the triplets  the precise positions of the points on the objects ' boundary or the points posiition offset by the probe radius?

And once the above question is adressed....how accurate do  have to be. Can I guestimate the points or will there be that box-like hunting move if the triplets are not close enough to the actual point on the objects boundary . Does the tolerance in triplet position have to be within your 50%-70% backoff.

I don't think I made my question clear enough...
I'll manually enter triplets to create the 3D probe path because my object surpasses the table boundaries similar to your example.

So, The triplets that I manually enter into probe25d.csv ....are the triplets  the precise positions of the points on the objects ' boundary or the points posiition offset by the probe radius?

And once the above question is adressed....how accurate do  have to be. Can I guestimate the points or will there be that box-like hunting move if the triplets are not close enough to the actual point on the objects boundary . Does the tolerance in triplet position have to be within your 50%-70% backoff.

Sorry - I'm with you now . Entering the points by hand you'd (technically) enter the exact points on the boundary you want to create. However, it isn't actually that crucial in your case because all you're doing is creating a boundary for the 3D probing routine such that it won't waste time probing LOADS of unneccessary space. If you make the boundary a little larger than needs be it just means you'll probe a LITTLE unneccessary space. Probably better to give it a little leeway anyway - better you probe slightly more than you need than miss some of your model. I guess that answers the guesstimate bit - i.e. yes a guestimate is fine and you only need the minimum number of points to adequately "surround" your model.

The little box thing isn't an issue because that's in the 2.5D routine and you're not using that. The tolerance of the triplet doesn't have anything to do with the backoff and again you don't care cos the backoff is in the 2.5D routine.

Hope this helps - keep it coming - we will get your mystical object probed yet 

Hope this helps - keep it coming - we will get your mystical object probed yet 

Cheers, ....off to probe.

BTW, this thing that you made that I'm using, does it have a name, have I missed something?

First impressions:
- In entering my triplets into probe25d.csv I went around the probe object clockwise and picked off the triplets.
- In order to get the triplets for probe25d.csv I did G31 manually in the MDI window of mach3. I used the values in the X&Y in the DRO.
- I would feel more comfortable if the horizontal moves were G31 instead of G00 even though the moves are at SafeZ height.
- it seems that the triplets are modified by the stepover when the probe3d.tap file is made. In my case this threw me into conflict with my soft limits. Somehow a big stepover gave me softlimits warning, but small stepovers did not create a softlimit problem. I got around it.
- Although you made it clear, It has just hit me that your algorithm is pure bed-of-nails, while the mach3 pluggin is modified so that if there is no hit while going down, the probe will move hozontally at full depth, thereby eliminating extra Z moves. It is hard to compare the two as far as runtime goes, but now I question  which one is better suited to my needs.

- Otherwise after 20 minutes I have not crunched my probe.

Good work Stirling, thanks

First impressions:
- In entering my triplets into probe25d.csv I went around the probe object clockwise and picked off the triplets.
- In order to get the triplets for probe25d.csv I did G31 manually in the MDI window of mach3. I used the values in the X&Y in the DRO.

This is fine as we've agreed that the values don't have to be absolutely accurate in this particular case / use.
Ideally of course you'd get the x,y values from gcode params 2000 and 2001.

- I would feel more comfortable if the horizontal moves were G31 instead of G00 even though the moves are at SafeZ height.

I assume you mean in probe3D.tap? I agree - that would be better. I think the reason I didn't do this was because G31 causes enough trouble - especially when it doesn't actually get tripped.

- it seems that the triplets are modified by the stepover when the probe3d.tap file is made. In my case this threw me into conflict with my soft limits. Somehow a big stepover gave me softlimits warning, but small stepovers did not create a softlimit problem. I got around it.

Yes. Put simply - the way the probe3D.tap is generated is that a virtual (but normal zigzag rectangular) bed o nails probe is done over the X,Y extents of the boundary described by the triplets file probe25D.csv. Whenever the virtual probe is outside the boundary the X,Y values are ignored, whenever it is inside, they are added to the routine. Look at the star piccy again and you'll see that the probed points (circles) do not coincide with the triplet points (the arrows) in any way apart from the fact that the circles are inside the boundary described by the arrows.

- Although you made it clear, It has just hit me that your algorithm is pure bed-of-nails, while the mach3 pluggin is modified so that if there is no hit while going down, the probe will move hozontally at full depth, thereby eliminating extra Z moves. It is hard to compare the two as far as runtime goes, but now I question  which one is better suited to my needs.

Fair point - that I can't really help you with - your choice. I guess the plugin kind of works out the boundary on the fly, however there is the issue with the plugin of the pitch of the stepover being determined by the ratio of the X and Y.
Initially the whole idea behind my stuff was to provide only the 2.5D routine (which I believe is the only one of its kind at the moment). I added the 3D "bounded" routine because I thought it was a decent alternative to other methods and an improvement on most.

- Otherwise after 20 minutes I have not crunched my probe.

Good work Stirling, thanks

Excellent - long may it last.

BTW, this thing that you made that I'm using, does it have a name, have I missed something?

Hmmmm - yes, probably should have a name - Razordance probing utilities for Mach?

And finally... guitar? - probing body - neck hanging over the edge?

Finally - a quick edit to add that I recall why I changed the 3D routine to integer stepovers, (see post #59). Now I've changed it back to reals, you MAY get the problem where the vertical G31 doesn't stop when it trips but carries on down to the programed point - crunch. Note however that this is just as likely to happen in ANY probing routine under Mach as it appears its a fault with G31 itself.

How about:
RazorProbe
ProbeDance
Stirling Probe