Alarmed Out Helically Interpolating???

[eliot15]

So here's a chunk of code I ran today. I'm just helically interpolating 20 passes in incremental mode, then circularly interpolating 2 passes to get a flat bottomed pocket and a finish pass. Code calls a sub to do the 20 helical passes incrementally.

Ran it, worked fine. Used a 0.5 resharp end mill. Cut pocket was a little undersize. Was shooting for 0.625, got 0.605. So I added -0.010 worth of cutter comp to my Geomeyr (D) offset.

Problem: Machine alarmed out with "Alarm 020 - Over Tolerance of Radius".

It alarms out on the following line in the sub program:

G3I.06Z-.025

...but only after I add -.01 cutter comp.

So I'm wondering if anyone can tell me what it is I need to know about helical interpolation, incremental mode, and cutter comp that I'm spacing out on at the moment.

%O0002
(.5 END MILL)
G90G0G54X0.Y0.
S2500M3
G43Z1.H19T3
M8
G1Z.1F15.
G41X-.06D19F15.
M98P0003L20
G90G0G40X0.Y0.
G1G41Y.0625D19F15.
G3J-.0625
J-.0625F30.
G0Z1.
G40G0X0.Y0.
G90G0Z1.
M101
G28Y0.
M30
O0003 (DEPTH 0.5)
G91
G3I.06Z-.025
M99
%

The way I solved my problem was just to turn off cutter comp. for then helical interpolation and leave it on for the circular interpolation. (I just deleted the G41/G40 from the helical code).

Thanks for any help. This is a real mystery to me.

[ChattaMan]

When cutter comp is applied the control needs to look ahead to be able to calculate it's next comp'd position. After you applied comp with G41, your next line was a sub call (M98). The control cannot read the next line until the sub runs, so it can't calculate the next comp'd position.
The code works on the last part of your program because after the G41 command, the control can read the next line and so work out it's next comp'd position.
Try putting a G91G3I.06Z-.025 before the M98 call, then repeat your sub 19 times (L19)

[eliot15]

Thats really interesting. Thanks for that.

I find it kinda' interesting, though, that the program ran OK the first time when my cutter comp. value equaled zero. I quess the control must have just understood that there was no comp. to calculate. The problem didn't arrise until I changed my cutter comp. to a non-zero value, forcing the calculation.

I also remember now having this problem with look-ahead offset about 6 months ago. Can't remember the details, but maybe this time the source of the problem will stick with me.

Thanks again.

[cogsman1]

MANY machines will NOT allow the "R" to be a negative value. RE-generate your code using a smaller dia. cutter and then make the "R" a positive to adjust. OR, generate your code with a tool dia. of zero and add the radius of the tool into the "R" and it will always be a positive. That is true cutter comp use.

[ChattaMan]

@cogsman1

But eliot15 says the circular interpolation works with a comp value of -0.01. It's just the helical part it errors out on (e.g. the sub)

The way I solved my problem was just to turn off cutter comp. for then helical interpolation and leave it on for the circular interpolation. (I just deleted the G41/G40 from the helical code).

[eliot15]

Yup,

The problem was definitely look ahead offset. As I mentioned, ran into that problem once before. Just forgot all about it.

Not exactly sure what "R" refers to. Usually associate "R" with the retract plane of a canned cycle, or tool nose radius offset in lathe work. My problem was on a vertical mill with Type C Fanuc offset memory, so I have H-offset (i.e. tool length offset) and D-offset (i.e. cutter radius offset). All of our CNC mills and lathes (mostly Mori Seki and PUMA, all FANUC) accept negative H and D values. We never store full cutter radius in the control; our programming software factors cutter radius in the posted code. We only do incremental adjustment of cutter comp. at the control. For example, if I'm climb milling the ID of a pilot hole, I'd travel CCW with my tool on the left of the contour. Turning on cutter comp. with a D:Geometry value of -.005 using G41 will cut my pilot hole .01 larger, i.e., it will move my cutter further into my contour.

Look ahead offset is what burned me. Just hope I remember it next time.

Thanks

[sinha_nsit]

There cannot be two consecutive non-movement blocks after G41/G42.
Therefore, changing
G91
G3I.06Z-.025
to
G91 G3I.06Z-.025
should solve the problem.

[eliot15]

Interesting. Thanks a lot. Same look ahead offset problem, but I really like your solution. Nice and clean.

Thanks again.

[ChattaMan]

Forget using G91 and M98, use a DO/WHILE loop instead. Stay in absolute and use a variable for your changing depth. No messy incremental moves or jumping from one prog to another.

[eliot15]

You know, been wondering about that sort of thing for a while. Are we talking Macros now? Never used one.

I'm real familiar with looping and other flow control contructs (if/then/else, foreach, do/while, switch/case, try/catch, etc.) from C#, Visual Basic, Java, etc. Been programming the .NET Framework since 2001. Yup, its that old. But never did a FANUC Loop.

Where does one start?

Thanks

[christinandavid]

A macro for your helical applications is inherently safer and easier to define (pitch/depth/finish passes/direction). Ours actually grabs the tool offset from the system variable instead of using G41/42, allowing easy programming of arc on, arc off from circle centre.

There is plenty of info on this forum.

DP

[eliot15]

Since all of our machines have FANUC controls, is Fanuc Custom Macro B what I want to be looking at? Is that the FANUC "macro language"? What's the "B" stand for?