In CAM, can I call lathe codes like the Fanuc G71 or G76?

[tdcomer]

As a long time CNC manual programmer, CAM/post programmer and machine tool operator, I have found the use of the machine resident codes like the lathe G70's to be very powerful/helpful and is supported by almost all modern machine tool manufactures.  

The information going into the CAM/post lathe profile command is very much identical to the Fanuc G71 code.  For example, if the CAM/post programmer chooses the wrong depth-of-cut he only has to change one piece of information to affect the depth-of-cut and post the program again.  If the same code were to go to the lathe, in the G71 format, the machine tool operator would only have the change one piece of information, affecting the depth-of-cut, then restart the same program.  The same thing is true with the Fanuc G76 threading routine.  With only two or three lines of machine resident code, tens to hundreds of CAM/post lines of code can be replaced.

That might not seem like of much of an advantage today with cheap CNC memory but it often can be.  Even if the CAM/post programmer takes only a few seconds/minutes to make that change, getting the new program back to the machine tool operator and into the control may take a few or several hours of lost production time.

This is just two examples and there are many others; using sub-routines/sub-programs, pattern rotation/shifting/scaling or machining/engraving serial numbers just to name three.  

I just think that using the CAM/post system with the much more powerful modern machine residents software (that is available today) would be the best of both worlds and benefit industry much more greatly than either system by itself.

Thank you for time and space for my question and comment.

[nick.narzinski]

It's all about the defaults of the operations.  you can't have it both ways...for profiling in the new strategy the default front and back make sense.  in the old facing strategy, the default was to cut to the model front.  in the new opp for facing, you will have to switch the front to stock front and the back to model front.  You will rarely cut the same area with both strategies (outside profiling vs facing). Like i said, it's not a big deal but i can see customers complaining about the change.

[akash.kamoolkar]

@nick.narzinski 

Still not sure I understand. In the old facing strategy you could set the front Z limit to stock front and it would machine to the stock front. If it's just a matter of changing the default front mode to stock instead of model you can change it using the compare and edit function. Or am I missing something else here?

Akash

[nick.narzinski]

I'll try to put a video together for you.  The difference is the old way, we had 2 different operations to store defaults...one for facing in front of the model, and the other for profiling radially on the model.  now you have rolled both of those into one strategy...you can't have 2 sets of defaults for the same operation, so you will have to chose good defaults for facing or good defaults for profiling, but you can't have both like you could when they were separate operations.  

[akash.kamoolkar]

@nick.narzinski 

Are you referring to the existing "turning face" strategy? Because I am referring to the "facing" option in the existing "turning profile" strategy, which is in the same operation as OD / ID. Turning face will remain as it is (with separate defaults) and will not change. We have simply added the ability to do vertical passes in the new strategy which was equivalent to the "facing" option in the existing turning profile strategy.

Akash

[nick.narzinski]

Aha, that's where our disconnect lies.  Yes, i am referencing the turning face strategy.  This type of facing (stock in front of the model) is where I have seen G72 being used the most.  PM Sent 

[tabtas21]

It's great to see these G71 and G72 codes added.Good job.

But when i make a G71 cycle for INTERNAL operation and post process it the output u and w are positive values in the g-code.This is an error because in internal operations they must always be negative ,as long as i want to do a finish with another boring tool, or zero.If i give negative values in X and Z finish allowance boxes then at least in simulation it cuts past my stock.

[akash.kamoolkar]

@tabtas21 Which post processor are you using?

Regards,

Akash Kamoolkar

[tabtas21]

I use haas st-20 post processor. Example :

O10702 (LATHE TEMPLATES)
(Machine)
( vendor: HAAS)
( model: undefined)
(T303 D=0. CR=0. - ZMIN=0. - boring turning)
G98 G18
G21
G50 S4000
G53 G0 X0.
G53 Z0.

(ID Rough G71)
T303
M155
G99
G97
S4000 M3
G54
M8
G18
G0 Z0.
X0.
G50 S4000
G96
S91 M3
X16. Z5.
Z-0.4
X16.8
G71 P10 Q11 U0.2 W0.1 D1.2 F0.127   --->in here u and w should be negative
N10 G1 X28.5 Z-1.
X26.5 Z-2.
Z-31.
X20.
Z-79.5
N11 X18.
G0 X16. Z-0.4
Z5.
G97
S1819 M3

M9
G53 X0.
G53 Z0.
M5

M30
%

[akash.kamoolkar]

@tabtas21 

Thank you, could you also attach the sample f3d file and the post processor (if you want you can privately send me the files).

Regards,

Akash Kamoolkar

[nick.narzinski]

@akash.kamoolkar Can we use G72 to face the stock in front of the model?  I can't get the toolpath to machine all the way to the inner radius.  

[akash.kamoolkar]

@nick.narzinski 

Can you attach the sample file so I can take a look at it?

Regards,

Akash Kamoolkar

[nick.narzinski]

@akash.kamoolkar File attached

[akash.kamoolkar]

@nick.narzinski 

It seems to be a bug that we've already fixed. I apologize for this. We're still fixing a few issues with the new strategies and the next Fusion update should be much more stable in terms of the new turning strategies. For now, setting the grooving parameter to "allow radial grooves" should allow the toolpath to go down to center (I realize, canned cycles are not supported for this mode)

Regards,

Akash Kamoolkar

[akash.kamoolkar]

@tabtas21 

According to the canned cycle u, w convention in the below picture for an ID front to back G71 canned cycle you would need u to be negative and w to be positive. Do you agree?

Regards,

Akash Kamoolkar

[tabtas21]

Hi,
yes u must be definetely negative and w zero or positive.

[tabtas21]

Hi,

yes u must be negative and w must be zero or positive for this G71 - G72  canned cycle when doing internal (boring) operations.

For external roughing  in this G71 - G72 canned cycle both u and w must be positive and it works fine with your new update.

[akash.kamoolkar]

@tabtas21 

Unfortunately it seems like the G71 G72 canned cycle compatible post processors are currently not configured to process u and w differently for machining direction and side. For now the workaround would be to edit the post processor so it will output the correct u and w values. I will get you the requisite code to do so. In the meantime we will be working on a software solution that will eliminate the need for the post processor to manage the u and w processing.

Regards,

Akash Kamoolkar

[tabtas21]

Hi,

I noticed something else i don't like when post processing (in a haas st-20 post processor) these new G71 G72 canned cycles. I think this one has to do with the new clearance boxes in the linking tab. The tool rapids at  G0 Z0. X0. at the start of these canned cycles.I tried a few things to find a solution like overriding setup safe Z and approach Z boxes but nothing changes these rapid suicidal moves.(At least there was a face operation first and there is no crash 😀)

%
O01059 (EXERCISE 23)
(T101 D=0. CR=0. - ZMIN=-18. - general turning)
G98 G18
G21
G50 S4000
G53 G0 X0.
G53 Z0.

(OD Rough G71)
T101
M155
G99
G97
S4000 M3
G54
M8
G18
G0 Z0.   ------------------------->suicidal rapid move
X0.        ------------------------->
G50 S4000
G96
S91 M3
X87. Z5.    
Z-0.4
X68.2
G71 P10 Q11 U0.2 W0.1 D1.2 F0.127
N10 G1 X38. Z-1.
X40. Z-2.
Z-16.
X61.
G3 X65. Z-18. I0. K-2.
G1 Z-45.
N11 X67.
G0 X87. Z-0.4
Z5.
G97
S335 M3

M9
G53 X0.
G53 Z0.
M5

M30
%

[akash.kamoolkar]

@tabtas21 

I see the move. Looks to be coming from the post processor. I will reach out to the post team to see what's going on.

Regards,

Akash Kamoolkar

[akash.kamoolkar]

@tabtas21 

The september hotfix 2 is live and fixes both roughing canned cycle issues: incorrect U, W values and also the rapid move to X0Z0.

Regards,

Akash Kamoolkar