What's new
What's new

Erratic chamfering from 1 part to next on HL-4

doug925

Titanium
Joined
Nov 21, 2002
Location
Houston
1996 HL-4

We are getting erratic chamfer locations, and missing a radius when using G42.

It will cut 3-4 parts fine. Then (whenever it feels like it) it will start to cut the finish pass about .02 + in Z.
When that happens, I get no radius, and the back chamfer starts too far forward.
I cannot [make] it do it when I want. It has no pattern that is discernible. AFAIK

The program uses a G54 for part face.
The tool is a DNMG 432 set as tool tip 3.

The program looks like this:

....
G50 S2000
T202 (DNMG-AL 432)
G54
G00 G99 G97 S2000 M03
X1.3 Z0.
G01 X-0.05 F0.01 (← face)
G00 X1.13 Z0.1
G01 Z-0.22 F0.01 (← ruff turn)
G00 Z0.2 X1.5
X0.9 Z.1 G42 (← cutter comp enabled)
G01 Z0. F0.007
X1.05
G03 X1.07 Z-0.01 R0.01 (this is the radius that is giving me problems)
G01 Z-0.05
X1.11 Z-0.07
X1.121 Z-0.09
Z-0.15
X1.11 Z-0.17 (this is where the back chamfer starts)
X1.05 Z-0.2
z-0.22
X1.3 F0.02
X1.4G40
G00 X5. Z2.
M01
T303 M08 (32 TPI THREAD)
G54
......


I re-wrote the program to not use cutter com, and the last 7 parts were fine. Zero problems.

So I feel it has something to do with the G42, or my entry or exit moves. ~However~ it would do it every time if the program where incorrect no?

Things I have also checked


  1. Coupling of motor to ballscrew fore-aft. Result no movement more than .001, and it always goes back to 0
  2. Turret play fore-aft. Result no movement
  3. Rapiding fore-aft (Z only) to dial indicators on each end. Result was always stopped on zero.
  4. Rapiding fore-aft with X movements of +/- 2.00" Result was the same. it always stopped on zero.:confused::nutter:
I am fresh out of ideas.

What else could it be???:bawling:

Anybody have any ideas?

Thanks,

Doug.
 
Maybe it doesn't like to turn on comp on a rapid move, at least I think it might be a logical conundrum, since most of the time, rapid moves are not compensated.
 
On older softwares ( I have no idea of HL-s, but the initial sw. rev on my SL10 ) had some issues with cutter comp.
Not the way they function, but rather the control getting lost and forgetting to comp or un-comp.

For the record, all of my Haas's will rapid with comp, rapid ramp-on comp and rapid ramp-off comp. In addition, unlike the idiotic Fanuc, it will NEVER cancel comp on it's own, regardless of how many non-motion blocks it encounters in series.


Doug, you may want to contact some oldtimer at Haas and see if there were any sw. issues back then. The newer service techs likely won't know about them as they probably never have encountered an HL.
 
Hu, you might be right. It is funny though that this has only shown up in the past 6 months.

Seymour, I have spoken with a newer tech, and he is putting the question to some of the "old timers" as you put it to see if there were any s/w bugs.
There were none that he could identify readily.

Come to think of it though, this ~could~ (and I am reaching at straws here) be related to the over threading I encounter when using a G76 thread. (just in X as opposed to Z)
Who knows? It could all be tied together as s/w screw ups.:confused:
 
Doug!

Did you say G76 threading?
Is it prior to the troublesome finish pass with the G42?
Or more specifically, since it is erratic, does it happen when you re-run the G76 cycle and then run the next part????
If the answer is yes to either one of those questions, then you've encountered the very same sw. bug that was in my original SL10!!!!
Unless you replace the software ( unlikely it being an HL ), you GOTTA!!! use G92 for threading.
I do have a buried document somewhere with the description, but is related to the G76 canned cycle not cancelled properly, and what you're actually seeing is the leftover toolshift from the canned thread!!!
Don't worry about the details, just see if a G92 fixes it.
 
Guys,

I wish it was just moving around in the jaws, but it is not. Period.

Trust me. Hard serrated jaws, soft 6061-t6, using 2-300 on the gage which translates to 8KPSI!!!:D
Even at a lowly 2000k RPM there is not enough centrifugal force to spread the jaws, and move the part on a .05" deep radial cut.

This is a software, or mechanical problem that I cannot get a handle on.


Seymoure,

I am sorry I should not have brought up the G76. That is a whole-nother problem.

This problem strictly revolves around the machine ~screwing up~ when a G42 is called.

It somehow changes where it ~thinks~ it is.

Again, If I start the program from the beginning, the 1st tool used is the turning tool.
I can watch it screw up.
I then hit RESET.
Start from the beginning again to re-run the EXACT same. It will cut FINE!

Two parts later, it screws up again.:confused::bawling:
 
Doug, please humor me and change the G76 to a G92 cycle.
I know it is unlikely anyone will be able to verify this at Haas, but my machine shipped with Lathe sw version L04.10. It had a problem with G76, where the tooshift necessary for the G76 threading logic did not cancel after running the code. M30 and M30 only is what cancelled the shift, and even then only if the M30 followed the G76 cycle. If there was any Txx calls between the G76 cycle and M30, the shift remained permanent.
M02, RESET, G80 or any modal codes from different G-groups were ineffective in clearing the shift register. Not even calling a different program or MDI code cleared it.
All non-compensated movements were fine and were executed with proper X and Z coordinates as expected. Only compensated ( G41 and 42) blocks were shifted, and always shifted in the +Z direction by roughly 1/2 of pitch ( that was only guesstimate of mine ) All X coords were fine.

I had sw version L04.26 installed 6 months later, all problems were resolved.
The software release doc. listed a few improvements and additions to some parameters and settings, but no bugfix for the issue was noted. One of the "improvement" tough was related to cutter comp handling, and I have noticed a huge difference in how transitions from G41 to G42 were handled in the new release, as I've crashed a tool. In the previous release G41/42 transitions were handled without a cancel move in-between. In the new one there is a clearance move, just like in all Fanuc codes.
Anyway, the reason I've made it so longwinded is that I'm guessing Haas did not know about the bug. They have made the change to the cutter comp handling for a different reason, which in turn resolved the bug as well.


So just for the hell of it, change the G76 to G92. Yes, I know it's a little bitchier, but try it....
 
Seymour,

"Doug, please humor me and change the G76 to a G92 cycle."

I have not used a G76 in the past 10 years.:D Seriously.
I am not, nor would I use that command. I always use a G92.

The reason I quit using the G76 10 years ago, is the Haas overfed in X. (blew right past the programmed diameter:eek:)
Haas support could never answer why, so I quit using it in favor of G92.

now that I answered that, I will go read the ~rest~ of your post.

Thanks,

Doug.
 
All non-compensated movements were fine and were executed with proper X and Z coordinates as expected. Only compensated ( G41 and 42) blocks were shifted, and always shifted in the +Z direction by roughly 1/2 of pitch ( that was only guesstimate of mine ) All X coords were fine.

:eek::eek::eek::eek::eek::eek::eek::eek:

Holy Sh@$ I think that might be it!
I still don't nor would I use G76, but those symptoms are WAY TOO CLOSE to be anything but the same type of problem!

Thanks! I am calling Haas now!

Doug.
 








 
Back
Top