Helical arc to short opti area tool path

[brandon b]

I'm really getting sick and tired of this happening at the machine.. Why do I get Alarms saying helical arc too short or small? How do I make it not too small? I've played with all the settings in the arc/filter tab . Thought I fixed it by putting .1 in the min. Arc radius field but it didn't help this time. It's always happening when I try and filter a opti path or parallel path.

[brandon b]

Here's a screen shot

[Allan]

Control def minimum arc length > .005; problem solved.

[brandon b]

Ok I'll have to dig into that. I've never messed with the control def

[brandon b]

this issue is really starting to drive me insane . No matter what I set the min arc length to, be it .001 or .1 , I continue to get these alarms at the fadal )we have 7 and it happens and all of them) that the helical move is too short. This seems to happen on 90% of the surface toolpaths I create.(parallel,blend optirough...) Only happens when I activate the filter.

 

my opti area path today did this. and afetr 10 trial and error of messing with parameters it was my helix entry was too small.

 

now im using a surface finish blend and I ran 70% of the program and now all of a sudden the fadl quit and said helical move to short.

 

How do I resolve this? Is it a post issue? fadal issue?

 

Ive changed the min arc length in my control def.

[Justin Beebe at Folsom Tool]

brandon b

 

I get this message on our Fadals as well. Sometimes if I switch the entry method from helix to profile it fixes the problem. Other than that I just mess with the settings for example step over or depth of cut until I get the toolpath to run all the way through. You can also use the SUM command at the Fadal to check for errors before you run the actual program. It usually tells you if there is a problem. Here is one more thing to try. This is right out of the Fadal user manual.

 

HELICAL MOVE TOO SHORT, N =

 

See error message HELICAL RISE TOO STEEP.

 

HELICAL RADIUS TOO SMALL, N =

 

See error message HELICAL RISE TOO STEEP.

 

HELICAL RISE TOO STEEP, N =

 

The radius of the circle and the helical rise are radically different in length

 

(usually the rise is much longer in comparison to the radius). Also, depending

 

on the programmed feed rate, the control may or may not be able to handle the

 

situation. Reducing the feed rate in the program can sometimes correct this

 

problem.

 

 

May want to try reducing the feedrate where the machine alarms out and see if the machine can handle the code when it is running slower.

 

HTH

[brandon b]

SUM doesn't seem to catch this issue. I'll have to try the feed rate . I'm starting to think it may be that. Most of my parallel and blend paths are .02 step over at 120 ipm

[brandon b]

I put .25 as my min arc radius and the program worked.

 

 

 

 

It was at .1

 

 

 

[brandon b]

Well got the error againy today trying to filter a finish blend and a parallel tool path . I gave up and just left the program un filtered at fed it in the fadal by uaing DNC . Can't seem to find a pattern on what causes it.

[mkd]

what post are u using?

 

can you show us the offending code?

[mkd]

if there is a feed rate component to the control issue i wonder if throwing a G08 in the top of the program would make a difference? total wild-a.. guess.

[brandon b]

Generic fadal post. Next time it alarms ill post a pic. I don't know anything about g8

[Justin Beebe at Folsom Tool]

mkd,

 

Good thinking with the G8 but I think the code that would help would be a G9. This is from the Fadal user manual:

 

G8 Acceleration (No

Feed Ramps)

This code is used when no hesitation is desired between moves. If the tool

hesitates the tool pressure lessens and the tool will leave a tool mark on the

contour. The G8 code would be used to eliminate the tool marks.

The hesitation is called a feed ramp or acceleration-deceleration. Ramping is

used to help the tool move to the desired position.

 

Fadal User Manual

• The G8 code is often used in combination with the M92 code.

• This code is modal and will remain in effect until the G9 code is used.

• The G8 code is a default code for format two.

• The G8 code is incompatible with a G41 or G42 coded on the same line.

• The G9 code is used to cancel the G8 code.

 

• The M95 code is used as a non modal form of the G9 code. It is generally

used when G8 is in effect. See M95 for more details.

 

G9 Deceleration

(Feed Ramps)

This code is used when hesitation is desired between moves. When the tool

hesitates the tool pressure lessens and the tool will leave a tool mark on the

contour. The G9 would be used to help the tool move from place to place when

inertia may be a problem. The use of the G9 code as opposed to using the G8

code will help insure contouring accuracy.

If an axis is faulting at a certain move, the G9 could be used to help the

machine to get through the move by decelerating at the end of the move and ------ READ THIS

then accelerating again at the beginning of the next move.

The deceleration will only slow the tool down at the end of the move. (It will not

come to a complete stop).

• This code is modal and will remain in effect until the G8 code is used.

• This code is default for format one.

 

brandon b what format are you using on your Fadal format 1 or format 2?

 

G8 is the default for format 2 and G9 is the default for format 1

 

I believe using a G9 will make your program run slower so I would turn it on only where needed.

 

G9 may or may not work because the alarm occurs on the arc move but maybe if the tool is deceling on that move it will help.

 

I will be interested to try this next time I get this alarm also because it drives me crazy when it happens.

[brandon b]

I'm using format 2. I'll try it when I get a chance. Thank you

[Jayson Kramer]

Brandon you are finding this on any of the HST paths you use correct?

[brandon b]

The only hst paths I use are opti rough. Also happens on surface finish. Blend, parallel, ....

 

 

It's just when I filter the path. Using create arcs xy or xz yz

[crazy^millman]

Did you see this in previous version of Mastercam like X6 and below? Do you have a file you did in one of those that was posted and ran? IF so take that file update it and regen all the operations even fi they are not dirty and report using the new stuff. Do a compare of the nc code from that file to the old file and let us know what is different.

[mkd]

Did you see this in previous version of Mastercam like X6 and below? Do you have a file you did in one of those that was posted and ran? IF so take that file update it and regen all the operations even fi they are not dirty and report using the new stuff. Do a compare of the nc code from that file to the old file and let us know what is different.

pretty much happens in X5, X6 and7

 

It's just when I filter the path. Using create arcs xy or xz yz

meaning it happens with only xy arcs enabled and / or with xz and zy arc enabled?

[brandon b]

It's happened in x6 . Before that I have no clue I got into programming in x6.

 

It only alarms when I activate the create arcs. All three planes cause an alarm.

[brandon b]

When this alarms again ill post the file.

[mkd]

It's happened in x6 . Before that I have no clue I got into programming in x6.

 

It only alarms when I activate the create arcs. All three planes cause an alarm.

i only allow xy arcs which helps alot, but not 100%.

[brandon b]

Yes mostly I only use xy arcs and that's usually when I get alarms.

[Justin Beebe at Folsom Tool]

For the record I used to get this alarm on a Fadal back when I was programming with MC9 and have gotten it with all versions of Mastercam since then. The only exception is I haven't been using MCX7 very much so I can't say for sure if I have produced the alarm using X7. I believe it to be a Fadal issue and not a Post issue. The machine can't handle the move when "The radius of the circle and the helical rise are radically different in length.". I believe this is why fadal suggests slowing down the feed when you get this alarm. This is also why I believe adding a G9 may fix the problem. In the past I just kept messing with the settings until I got the code to run. Next time this happens, and I'm sure it will, I'll try the G9 and let you guys know the outcome. I'm really glad this topic came up.

[brandon b]

So with the g9 I just add it before the line that alarms and then g8 after that line? Or just replace g8 at the beginning of the program with g9?

[Justin Beebe at Folsom Tool]

brandon b,

 

You can do it either way but from what I remember the G9 code makes your program run slower because the tool is decelerating on each move when it gets close to the end of the move. If you know what line the toolpath alarms out on you could add the G9 just prior to that line. The G9 command is modal and will remain active until you cancel it with a G8. I would also recommend running the tool a few inches above the part the first time you try it just to see how the machine is going to react.

 

Let me know what happens.