part destroyed?

[Shawn Wentzel- Wenteq Inc]

I ran a file last light and everything looked fine in verify and the part got cut in two spots where it said it wouldn't be. I dont know why. I even pulled the code off the machine and verified it with the code from the computer to make sure nothing was lost in the transfer. Could somebody please verify with something else to see why it did this. click here for the file

[Smit]

Where is it at on the FTP site? I can't access the link...

[Shawn Wentzel- Wenteq Inc]

It is under all NC programs. Name is cone60 square block2.mc9

[Jim at Gentex]

Where are the 2 bad spots? I ran backplot and verify and it looks good.

[gcode]

Does your machine rapid in a straight line or

"dogleg"? Neither backplot and Verify will can

catch a dogleg crash.

[Shawn Wentzel- Wenteq Inc]

I know, so did I. It looks fine in MC but was killed on the machine. The lower right cone had the top boss cut and the lower left cone was goughed so hard it tripped an alarm on the machine at about-.8 deep.

[Shawn Wentzel- Wenteq Inc]

It's not in a rapid, its in feed. I changed the pocket design and now it gouged in another spot.

[Jim at Gentex]

hmmmmmmm...

 

I've had this happen before but I always traced the problem to either a bad spline or a poorly trimmed surface. If that's the case it doesn't show up in backplot or verify either. Your model looks pretty clean though.

 

The only thing I see here even remotely suspicious is in your Surface Rough Pocket toolpath you checked 'plunge outside containment boundary'. I've seen this cause trouble before too b/c sometimes the machine doesn't know what to do when it gets conflicting info, but in your case it looks harmless enough.

 

The only other advice I would give is double check and maybe increase all of your Z clearence heights and make sure they are Z+ absolute values. Other than that, I'm stumped.

 

Sorry I can't be more help.

[Shawn Wentzel- Wenteq Inc]

I changed it to a morph pocket and changed nothing else, and it worked fine, just takes a long time. I don't know whats wrong either.

[crazy^millman]

quote:

---

The only thing I see here even remotely suspicious is in your Surface Rough Pocket toolpath you checked 'plunge outside containment boundary'.

---

In my humble opinion this is a not soemthing I would do with this toolpath. the very meaning of it would be enough to make stay away from it. I understand its reasoning but you are not asking the program to take away control from your toolpath. I want ot know exactly where what when and how my tools are working, going and doing and if you start allowing Mastercam to make choices for you I think it spells trouble.

[TheePres]

Would this be on a Fadal??.

Maybe adjust your filter settings, and put a bigger value on minimum arc allowed.

[Shawn Wentzel- Wenteq Inc]

No its on a Haas. I'll try the plunging idea and backplot to see if that works.

[Smit]

I ran the NCI file through Vericut, it looked fine. I couldn't find a gouge.

 

Sometimes the machine doesn't interpret the code the same way Mastercam verify or vericut does. I've especially had trouble with Fadal and Deckel Maho. Usually small Z and K moves.

 

I know that's not much help, sorry.

[steve f]

AeroTech,

 

how big are the gap settings in the operation. It's happened to me in the past that when the gap setting is too large, a straight line feed move will occur through the part instead of a retract/rapid over move. I also found in V8.1 that if you're using parallel in surface rought pocket with quick zigzag checked and the part has multiple bosses, the tool may feed through one or more of the bosses.

 

HTH,

 

steve

[Shawn Wentzel- Wenteq Inc]

I ran the file in Metacut and it showed the gouge.