Probe Cals

[MeGoetz]

What causes probes (tips) to be slightly "off" when calibrating them for the first time.

When I create a new tip, I have noticed that it does not align itself with the calibration sphere during the first calibration. After THAT tip has been calibrated though, it's touches are more in line with how you would expect them to be during the calibration routine. Currently I have the Prehit/Retract set to about 0.300". Once they have been calbrated though they can be set to 0.100.

[Matthew D. Hoedeman]

Mostly this is because NONE of the components you are using are perfect, however, the mathematical descriptions of them in the probe file are. This is the biggest reason for calibration to begin with.

[#2#]

That's why you calibrate the tip. The first time through it is "finding" the location of the sphere for that tip (among other things). Nothing is perfect. Each tip will vary slightly due to manufacturing differences and if the tip is straight. Calibrating the tip allows the software to compensate for those differences. The first time through it "finds" the sphere and figures out how far off the tip is. The second time through it already knows where the sphere is and what to do to compensate for the tip's length and location (bend).

Both I and Matt are assuming of course that you are selecting "No" when it asks you if the calibration sphere has moved. If you answer yes and take a manual hit it assumes the sphere is directly underneath your hit. That probably won't be the case.

[Matthew D. Hoedeman]

Yep, after they are calibrated the first time, Pcdmis will then use the 'results' from the last time as the starting point for this time. The previous results are where it thinks the tips are now located, not to the perfect math data.

[#2#]

Currently I have the Prehit/Retract set to about 0.300". Once they have been calbrated though they can be set to 0.100.

In order to minimize error you will want the prehit/retract to be set the same in your program as you use to calibrate. Move speed and touch speed should be the same as well.

I'm not saying that you can't run others as I know for a fact that small changes don't make much difference with my machine. Others on this forum have reported that with their machines these variable can introduce error if they are not the same between the cal. and the program.

[Matthew D. Hoedeman]

In order to minimize error you will want the prehit/retract to be set the same in your program as you use to calibrate. Move speed and touch speed should be the same as well.

I'm not saying that you can't run others as I know for a fact that small changes don't make much difference with my machine. Others on this forum have reported that with their machines these variable can introduce error if they are not the same between the cal. and the program.

I think it might have some to do with WHAT you are measuring as well. The cal-sphere SHOULD be 'perfectly' round, and in theory so should the tip of the probe. Now, IF Pcdmis does NOT do any probe compensation while it is measuring the cal-sphere (and it shouldn't, that is one of the things it is trying to figure out) then it really shouldn't matter WHAT you use for prehit and retract, since the hit will, theoretically, be on a 'perfect' sphere, then when it is done with it's touches, it should then be figuring out what size the tipis. Has anyone tried this to see if there is a difference?


I would think, that in the calibration routine anyway, that you should get the same final results using a 0.010" prehit/retract as you would if you used 1.000" prehit/retract since it does not matter WHERE exactly it touches that 'perfect' sphere, as long as it IS the tip that is touching the sphere. It's all a single ball it is touching and Pcdmis is 'constructing' a ball using the hits and then using the difference of the nominal sphere diameter to the un-comped constructed sphere to give you a tip diameter.

[#2#]

Matt, I have run a calibration at a movespeed/touchspeed combination and a prehit/retract combination. Then, I measured the sphere in a program with many different movespeed/touchspeed and prehit/retract combinations (what I resonably might expect to use). I found that on my machine the error in the diameter of the sphere that was introduced was .00005 in. Much less than I need to worry about and in my opinion less than the repeatablility of my machine.

I have not done it the other way 'round. Where I measure at the same setting but cal. at different settings (why would you do this?).

[Matthew D. Hoedeman]

Matt, I have run a calibration at a movespeed/touchspeed combination and a prehit/retract combination. Then, I measured the sphere in a program with many different movespeed/touchspeed and prehit/retract combinations (what I resonably might expect to use). I found that on my machine the error in the diameter of the sphere that was introduced was .00005 in. Much less than I need to worry about and in my opinion less than the repeatablility of my machine.

I have not done it the other way 'round. Where I measure at the same setting but cal. at different settings (why would you do this?).

Not saying I would, but the original post was useing a BIG pre-re first time around, then a tigher pre-re after that. My intent was that during the cal, the pre-re should NOT matter, if Pcdmis is doing the cal routine in a 'logic' manner.

[MeGoetz]

What started allof this was that the tip offsets for A0B0 got buggered. They were offset - say- 1"-x and 2" -y.
Once I calibrated A0B0 using the buggered offsets, EVERY tip was wrong by the same amount. By the time I discovered what the problem was I had man+dcc calibrated many tips. When I set the Tipoffsets (for A0B0) back to x=0,y=0,z=Z the tip offsets for the other tips were now offset relative to the old buggered values for A0B0
My solution was to shitcan EVERY tip - rebuild the probe - and redefine the artifact (cal sphere).
Now when I come to a "new tip" I have to set the prehit/retract value to 0.300".
I do not have to worry about this with my other software. Would doing a wrist calibration eliminate the need to set the prehit/retract abnormally high?

[Matthew D. Hoedeman]

What started allof this was that the tip offsets for A0B0 got buggered. They were offset - say- 1"-x and 2" -y.
Once I calibrated A0B0 using the buggered offsets, EVERY tip was wrong by the same amount. By the time I discovered what the problem was I had man+dcc calibrated many tips. When I set the Tipoffsets (for A0B0) back to x=0,y=0,z=Z the tip offsets for the other tips were now offset relative to the old buggered values for A0B0
My solution was to shitcan EVERY tip - rebuild the probe - and redefine the artifact (cal sphere).
Now when I come to a "new tip" I have to set the prehit/retract value to 0.300".
I do not have to worry about this with my other software. Would doing a wrist calibration eliminate the need to set the prehit/retract abnormally high?

Sounds like you got some seriously bent parts in your build up. The other thing is, your head might not be square to the machine axis.

Visually inspect your build-up. Put the probe straight down and put it next to an angle plate. Does it look parallel? Turn the angle plate 90 and check the other way.

Put you probe straight forward. Put it close to any stationary object on the table. Move the machine straight back, does it get closer or farther away as you move? If so, your head is not sqaure and THIS will cause a lot of what you are seeing.

I don't think you want to do a wrist calibration, I think it will take forever, but I have never done one myself.

[#2#]

Not saying I would, but the original post was useing a BIG pre-re first time around, then a tigher pre-re after that. My intent was that during the cal, the pre-re should NOT matter, if Pcdmis is doing the cal routine in a 'logic' manner.

If all you take into account is that the cal sphere and the tip variation then the prehit/retract should not matter.

Did you take into account the "coast" factor of a machine? If the machine is moving at a high touchspeed and a low prehit/retract by the time the machine "senses" a hit and reads the scales for a position the head could have coasted past the point where the tip actually contacts the cal sphere.

The software will compensate for this "coast" after calibration. If you run at a different prehit/retract or movespeed/touchspeed the coast may be different.

[craiger_ny]

If you need to square it up here is the quickest, easiest, cheapest way.

Craig

[#2#]

What started allof this was that the tip offsets for A0B0 got buggered. They were offset - say- 1"-x and 2" -y.
Once I calibrated A0B0 using the buggered offsets, EVERY tip was wrong by the same amount. By the time I discovered what the problem was I had man+dcc calibrated many tips. When I set the Tipoffsets (for A0B0) back to x=0,y=0,z=Z the tip offsets for the other tips were now offset relative to the old buggered values for A0B0
My solution was to shitcan EVERY tip - rebuild the probe - and redefine the artifact (cal sphere).
Now when I come to a "new tip" I have to set the prehit/retract value to 0.300".
I do not have to worry about this with my other software. Would doing a wrist calibration eliminate the need to set the prehit/retract abnormally high?

I am not following you. If Matt's answer didn't help please let me know if I am understanding your problem.

Right now you do a cal. of several angles including A0B0. You answer "no" to the sphere having moved. A0B0 cals. OK but when it tries to do another angle A90B90 it thinks the sphere is off somewhere else? Is this the problem you are having?

[craiger_ny]

I have to disagree to some extent on the pre hit retract matching the part program during qualification. The only thing that needs to match prehit and retract wise is the minimum distance it takes to "settle in". Anything more than the minimum is extraneous. If you machine "settles in" with a a distance of 0.02 then anything beyond that distance is extra travel. What distance your machine settles in is a function of the physical charecteristics of the machine (resonation) and machine speed (there may be some probe whip in there too but my guess is that settles in faster). Once the machine is settled in during the prehit that is that. If a machine settles in within 0.020 then 0.3 prehit on qualification is no different than 0.12 prehit during the part program execution. Once the 0.020 has been achived it is all the same. I only use 0.020 as an example, I do not know what is typical. I bet Hilton could settle this.

Touch speed on the other hand should be the same.

Craig

[#2#]

I have to disagree to some extent on the pre hit retract matching the part program during qualification. The only thing that needs to match prehit and retract wise is the minimum distance it takes to "settle in". Anything more than the minimum is extraneous. If you machine "settles in" with a a distance of 0.02 then anything beyond that distance is extra travel. What distance your machine settles in is a function of the physical charecteristics of the machine (resonation) and machine speed (there may be some probe whip in there too but my guess is that settles in faster). Once the machine is settled in during the prehit that is that. If a machine settles in within 0.020 then 0.3 prehit on qualification is no different than 0.12 prehit during the part program execution. Once the 0.020 has been achived it is all the same. I only use 0.020 as an example, I do not know what is typical. I bet Hilton could settle this.

Touch speed on the other hand should be the same.

Craig

I agree with you Craig, as long as your machine has time to settle from the movespeed to the touchspeed in the prehit distance it shouldn't matter.