Haas G68 Rotation Errors

[rx8pilot]

Haas G68 Rotation Errors [SOLVED]

I am using G68 Rotation to accommodate less than square stock on a vacuum chuck with no locating features.

The program begins with probing XYZ and also probes the edges to calculate the rotation in the X axis. This value is used with the G68 command.

The bizarre scenario is that the probe routines run fine and the offsets are perfect along with the rotation. The line G68 X0 Y0 R#189 executes and the coordinates are indeed rotated as expected. As soon as the first G00 is executed the machine goes nuts - sending the tool into outer space.

If I start the program AFTER the probing routines every works perfectly. The probing programs run fine. The main program runs fine. Both of them running together creates a bizarre behavior with G68.

I have been working on this for a day - moving, changing, deleting, adding, etc, etc every imaginable permutation of the code trying to sort out what may be causing this. I have tried on a VF2 and UMC500 - same on each. Posted with numerous post processors to see if anything pops up. Read every bit of 68 documentation I can find. So far.....nothing.

Any ideas?

Below is one iteration of the code in question. If I run the whole thing - it will alarm at N250. If I mid program start at N200 - it works as intended with the coordinates rotated.

%
O51177 (PART1)
G90 G94 G17
G20
(VAC CHUCK ON)
G105 A5. B1.
G53 G0 Z0.

(PROBE_Z)
T50 M6
(Stock Haas Probe)
G154 P25
G187 P3
G0 X0. Y0.
G43 Z1. H50
G65 P9832
G65 P9810 Z0.2 F100.
G65 P9811 Z0. Q0.05 S154.10
G65 P9810 Z1.
G65 P9833
G0 X0. Y0.

(PROBE_XY)
G187 P3
G0 X0. Y0.
G65 P9832
Z1.
G65 P9810 Z0.2 F100.
G65 P9812 Z-0.2431 X16.3 R0.5 Q0.5 S154.10
G65 P9812 Z-0.2431 Y10. R0.5 Q0.5 S154.10
G65 P9810 Z1.
G65 P9833
(PROBE Coordinate Rotation)
G00 G90
G154 P10
(PROTECTED POSITION)
G65 P9832
G65 P9810 X-8.5 Y5.5 F100.
G65 P9810 Z-.35 F50.
(PROBE ANGLE)
G65 P9023 A15. I8. J2. B2.
G65 P9833 (PROBE OFF)
G1 Z2. F100.
N200
(ROTATE COORDINATES)
G154 P10
G0 G90
G68 X0 Y0 R#189
(END COORDINATE ROTATION)
G53 G0 Z0.

(TEST)
T6 M6
M1
(3/8 Chamfer)
S8000 M3
G154 P10
G187 P3
N250 G0 X7.975 Y-5.325
G43 Z0.6 H6
G0 Z0.2
G1 Z0.0394 F200.
Z-0.125
Y-5.225
G3 X7.875 Y-5.125 R0.1
G1 X-7.875
G3 X-7.975 Y-5.225 R0.1
G1 Y-5.325
G0 Z0.2
Y5.325
G1 Z0.0394 F200.
Z-0.125
Y5.225
G3 X-7.875 Y5.125 R0.1
G1 X7.875
G3 X7.975 Y5.225 R0.1
G1 Y5.325
G0 Z0.6

 

[Larry Dickman]

your probe routine will clear #189. Try keeping your user variables between 101 and 120

 

[rx8pilot]

your probe routine will clear #189. Try keeping your user variables between 101 and 120

Thanks for taking a look Larry, much appreciated.

The angle macro that populates #189 is the last one run and it stays there - even after M30/reset. Just in case, one of the experiments I did was to put in an explicit R value G68 X0 Y0 R0.150 which yielded the same result.

If I allow the probe macro O9023 to run, the rotation is very far off even though the #189 variable is perfect. When I run the program from N200 (with R#189 or R0.150) it works as intended.

Maybe the O9023 Renishaw macro is doing something that interferes with G68.

I just tried this on my home based Super Mini Mill with NGC control - same problem.

 

[D Nelson]

Does it spear to be 180 off?


Sent from my iPhone using Tapatalk Pro

 

[rx8pilot]

Does it spear to be 180 off?

No. In fact it appears to be scaling in addition to rotating. When I tried it on the UMC500 - I used the C axis to to manually rotate the part to get an idea of where it was going relative the normal coordinates. It was something line 140 deg or so and larger than the programmed geometry.

I have not been able to identify any number that would correlate with what I see happening. Pretty weird, I have been programming 5 axis machines (and many others) for 14 years and not yet seen this one.

With all that said - I am still assuming that there is something that I did/did not do to deserve this. Not ready to call it a bug.

 

[gregormarwick]

Not a haas guy, but all the same I don't see anything obviously wrong with your program.

What happens if you put either the program or the probing routine (or both) in a separate program and call it from the main program?

 

[Larry Dickman]

Maybe the O9023 Renishaw macro is doing something that interferes with G68.

are you using the probe with G68 active? That's a huge no-no.

 

[Denim]

Not very familiar with Haas, but reactivating the work offset with G68 active could cause some issues. Or maybe G91 is activated in the T6 toolchange and not switched back to G90.

 

[rx8pilot]

are you using the probe with G68 active? That's a huge no-no.

G68 is confirmed OFF. As a precaution, I even put a G69 ahead of the probing cycles. On top of that - Renishaw even has a check at the very beginning of the macros to see if G68 is active. If it is, it will simply alarm the machine.

 

[rx8pilot]

Not very familiar with Haas, but reactivating the work offset with G68 active could cause some issues. Or maybe G91 is activated in the T6 toolchange and not switched back to G90.

As a test - I ran the code in a variety of ways. Activating the work offset before / after, G90 before and after, etc, etc. As many variations as I could think of - all with the same result.....

If the Renishaw Angle macro is run - we have a problem.
If the Renishaw Angle macro is eliminated - everything works (even after tool changes)

I have now tried three Haas machines with NGC controls and different software revisions - so leaning heavily toward operator error but I am totally out of logical ideas now. Now I will start randomly guessing to see where I get.

Messages to Haas have not yet been returned. I just got a contact at the factory which I am hopeful will yield and answer.

 

[Larry Dickman]

here's a quick question. Your using vector probing, did you run the Vector calibration cycle?

First time I used 3 point bore, I'd never heard of vector calibration, and everything was about a 1/4" off.

 

[rx8pilot]

here's a quick question. Your using vector probing, did you run the Vector calibration cycle?

First time I used 3 point bore, I'd never heard of vector calibration, and everything was about a 1/4" off.

Good question - I have not run that cal and have no idea if anyone has. I will check now.
At the moment - the system is off about 18" or so. Rather massive error.

What continues to be weird is that the resulting angle from the probe cycle is correct. The XYZ position is correct - it only goes haywire when G68 is activated after the probe cycle. Does the vector calibration have any impact on the implementation of the G68 command? I have no idea what is happening under the hood.

 

[Denim]

If you substitute just the 9023 angle cycle with a hardcoded #189=0.125 and keep everything else in the program the same, does it still error?

 

[rx8pilot]

*************** SOLUTION **********************

By way of brute force elimination - I found the problem and it was not obvious.

The P9023 A15. Renishaw angle macro has an optional work offset parameter. If you only need an angle, just omit the S parameter. It will run and give you the angles as expected in #189 and #192. I did not use the 'S' parameter to get a work offset because it was not needed - or so I thought. When a work offset is specified the macro not only writes to the offset but also writes(or clears) to other variables that G68 uses.

The probe line must include the work offset parameter if G68 is used after that. Even if G68 is called from a completely different work offset as I am doing in this case.

GOOD:

(PROBE ANGLE)
G65 P9023 A15. I8. J2. B2. S54.
G65 P9833 (PROBE OFF)
G1 Z2. F100.
N200
(ROTATE COORDINATES)
G154 P10 (DIFFERENT OFFSET CALLED)
G68 X0 Y0 R#189
(END COORDINATE ROTATION)
G53 G0 Z0.

BAD:

(PROBE ANGLE)
G65 P9023 A15. I8. J2. B2.
G65 P9833 (PROBE OFF)
G1 Z2. F100.
N200
(ROTATE COORDINATES)
G154 P10
G68 X0 Y0 R#189
(END COORDINATE ROTATION)
G53 G0 Z0.

In the software development world, this is called an undocumented dependency. Very frustrating that an optional parameter is not really optional.

Hope this helps someone in the future......thanks for all that took a moment to read and respond.

 

[Larry Dickman]

I've been bit in the ass by optional parameters before. I recommend you do the vector cal, like pronto, otherwise your numbers are horseshit.

 

[rx8pilot]

I've been bit in the ass by optional parameters before. I recommend you do the vector cal, like pronto, otherwise your numbers are horseshit.

Copy that.....thanks for the tip.