WIPS Programming

[pixlated]

Hello,
I am trying to get my probe to measure an array of parts, and set the work offsets for each one. I have been trying to use the recommended codes from the renishaw probe, but I am not getting the result I want.

Here is a sample of the Probe cycle:

T10 M06
(1)
G90 G58 X0 Y0
G43 H10 Z.5
G65 P9832
G65 P9810 Z-0.2 F50
G65 P9814 D1.33 S154.01
G65 P9810 Z1.00
(2)
G90 G58 X2.6 Y0
G65 P9810 Z-0.2 F50
G65 P9814 D1.33 S154.02
G65 P9810 Z1.00
(3)
G90 G58 X5.2 Y0
G65 P9810 Z-0.2 F50
G65 P9814 D1.33 S154.03
G65 P9810 Z1.00

When I run this, the probe goes to each position correctly, and touches of the center of a bore, and sets the G154 P1 etc, but the X number doesn't change by the 2.5 inches or so, it just stays the same, within a few thousandths, for each part.

Any idea how to force it to put the machine coordinates into the offset, vs just the difference from the original location?

Thanks!

Similar Threads:

• Am i on drugs? WIPS
• Renishaw WIPS Subs
• WIPS and tool wear compensation
• WIPS Probe questions
• 3d geometry for Haas wips probe

[Ydna]

The values being set into your work offsets are the "starting position error" coordinates, which is the distance of the probed bore center from the position where you started the cycle. That's why it deviates by only a few thou from part to part. In order to do what you want, there's some additional math that has to happen before it sets the offsets, specifically to add or subtract that position error from the starting machine coordinates.

Normally when running the probe cycles through MDI, the "branching" programs (o9023 or o9997) do the math for you then call the subroutine that assigns offsets again to fix it. Anyway I'm not in front of a machine right now but I think this will do what you need:
G65 P9810 Z-0.2 F50
G65 P9814 D1.33 S154.01
#190= #190 + #5041
#191= #191 + #5042
G65 P9732 S154.01 W1. (assign offsets)
G65 P9810 Z1.00 <this could be a rapid movement since it's just going "up", but the protected movement certainly won't hurt

I ripped those lines out of branching program so I believe that'll do it. The macros #190&191 contain that position error which is added/subtracted to the current position (which should be the same as where it started).

There's another way to fix it but it involves running the probe branching program instead of directly calling the bore cycle. So in this case use G65 P9023 A1.0 D1.33 S154.02
The downside is that o9023 will want to activate and deactivate the probe every time, so it adds like 1-2 seconds to each of the measurements. Also you'll need to re-activate the probe to run the protected movement for the second and third parts. So ultimately the program will have some redundancies and a few seconds wasted, but it might end up being more simple (just depends on your goals I suppose)

[pixlated]

The values being set into your work offsets are the "starting position error" coordinates, which is the distance of the probed bore center from the position where you started the cycle. That's why it deviates by only a few thou from part to part. In order to do what you want, there's some additional math that has to happen before it sets the offsets, specifically to add or subtract that position error from the starting machine coordinates.

Normally when running the probe cycles through MDI, the "branching" programs (o9023 or o9997) do the math for you then call the subroutine that assigns offsets again to fix it. Anyway I'm not in front of a machine right now but I think this will do what you need:
G65 P9810 Z-0.2 F50
G65 P9814 D1.33 S154.01
#190= #190 + #5041
#191= #191 + #5042
G65 P9732 S154.01 W1. (assign offsets)
G65 P9810 Z1.00 <this could be a rapid movement since it's just going "up", but the protected movement certainly won't hurt

I ripped those lines out of branching program so I believe that'll do it. The macros #190&191 contain that position error which is added/subtracted to the current position (which should be the same as where it started).

There's another way to fix it but it involves running the probe branching program instead of directly calling the bore cycle. So in this case use G65 P9023 A1.0 D1.33 S154.02
The downside is that o9023 will want to activate and deactivate the probe every time, so it adds like 1-2 seconds to each of the measurements. Also you'll need to re-activate the probe to run the protected movement for the second and third parts. So ultimately the program will have some redundancies and a few seconds wasted, but it might end up being more simple (just depends on your goals I suppose)

Hey,
Thanks you for the reply!

That makes sense as to why I was getting the result I was seeing. I will try out that solution, and see how it works.

I will also try programming it a little different in Mastercam, so that it uses the first position as X0Y0, even with the different offsets. As long as the "Center" of each part is correct, it doesn't really matter where the X0Y0 is on the table.

-Trevor

[generaldisarray]

search referred datum in the Reinishaw Haas manual

Programming manual
H-2000-6222-0A-B

If you had an approximate starting pos in that WOF and made it active @ X0 Y0 it would do what you wanted

T10 M06
(1)
G90 G54.1P1 X0 Y0
G43 H10 Z.5
G65 P9832
G65 P9810 Z-0.2 F50
G65 P9814 D1.33 S154.01
G65 P9810 Z1.00
(2)
G90 G54.1P2 X0 Y0
G65 P9810 Z-0.2 F50
G65 P9814 D1.33 S154.02
G65 P9810 Z1.00
(3)
G90 G54.1P3 X0 Y0
G65 P9810 Z-0.2 F50
G65 P9814 D1.33 S154.03
G65 P9810 Z1.00