HAAS lathe tool widths

I'm very quickly reprogramming my brain to shift from my Fagor 8050T to the HAAS controller. One thing I noticed this week is that FAGOR seems to have much more details for defining tool geometry. HAAS seems to only care about tool tip radius, where FAGOR lets you put in all the cutter angles and overall width, where applicable. So when you do a G71, etc, FAGOR will account for tool width on valleys. HAAS just shows you a centerline path on preview and leaves it up to the operator to calculate offsets for the right side of the tool for valleys and other plunges. Am I missing something, or is this how HAAS works? I'm cool with it, but I want to be sure I'm not missing some key understanding of how to program my machine.

JBNimble said:

So when you do a G71, etc, FAGOR will account for tool width on valleys.
.

Click to expand...

Unless you're talking about conversational programming or conversational entry and then conversion to G-code, I do not see how a plane-jane G71 cycle could accommodate
for the valley.
G71 has only a single U and W definition for leave allowance, and those are directional.
IOW if you've defined a positive W, it will shift all postions by that amount, meaning that the font wall of your valley will have an overcut by the W amount.
This isn't unique to Haas only, I believe all controls behave the same way.

Now, if on the Fagor you input the part geometry on a conversational side, and tell the control to generate the G71 cycle, then it is absolutely possible that the control
interrogates the tool definition file and calculates a properly offset geometry and inputs that into the G71 cycle instead.
That is NOT possible on a Haas as far as I know.

Otherwise, for standard lathe programming the only thing the control needs to know is the tip direction and tip radius.
Any other definition is immaterial and cannot be utilized.
Conversational, yes of course it can be. Straight G-code, no.

My Fagor 8050 absolutely accounts for tool widths in canned cycle profiling with straight Gcode. This is why I was confused that the HAAS, 30 years newer, does not.

Not sure if this is going to be again a long term reply, but I do not see how a straight ISO G71 cycle can possibly use a width parameter.
The G71 has U, R, U, W, P, Q, L and R parameters, none of which applies to tool width.

Not only Haas, but Fanuc, Mits and all other straight G-code machines do the same.
There is no such thing as a width definition.

But again, if you mean conversational generated G71 cycle, then that's different.

I downloaded the manual just to get my head around what the OP is trying to do and it seems that Fagor may indeed need more tool data to do some of the canned cycles.

O.P. Can you post a snippet of your Fagor code? As Seymour said, on Fanuc, Haas, and most other EAI controls its a bare bones G71 code and you would have to do the calculations. Seems that Fagor may have a bit more than I ever gave credit for.....

I do a lot of small parts in 303. To maximize my tool space on my gang, I use a 0.087" wide Iscar groove tool for almost all facing, grooving and parting. In the tables, the 8050 control let's me define the entire tool shape, including width. Then, when I call a canned cycle for profile roughing/finishing, it adds the tool width to Z distances for all left side features. This is true whether I'm running compensation or not. Comp just accounts for tool radius, but width comp is automatically handled. So, back to my original comment, I was baffled that the newer controllers don't do this. I had a recent discussion with my HAAS tech and we agreed that CAM generated code is now so ubiquitous that most programmers don't care about embedded compensation capabilities like this. As a pure g-coder, I wish they had all adopted this.

Also, as shown in the other reply, Fagor is using G68, not G71. Syntax difference only, but I point this out for clarity.

JBNimble said:

CAM generated code is now so ubiquitous that most programmers don't care about embedded compensation capabilities like this. As a pure g-coder, I wish they had all adopted this.

Click to expand...

\

In 20 years, I have never used CAM for lathe code.
That G68 is a non-standard code. Yes, it is cool, but as you've just found out it isn't something anyone else uses.
That is one of the reason I despise everything conversational .

If you stick with the plane-jane EAI code, you can almost always transplant the program from one machine to another and expect the same result ( with only minor modifications)

That is one of the reason I despise everything conversational .

If you stick with the plane-jane EAI code, you can almost always transplant the program from one machine to another and expect the same result ( with only minor modifications)

Click to expand...

Amen, I have always fought with the delima when hiring someone with Mazac, Hurco, Ect on the resume. They can be really good machinist but struggle with basic EAI.

What year of machine? I think around 2013-14 they had a way to import a dxf file and program from that, might help...?