Verify not showing tool crash

[Karl@CP PISTONS]

Using X9 to machine some surfacing paths and this is the 3'rd time it has returned with a broken tool. 3 different parts but verify does not show anything wrong. From the looks of the finish it looks like it has gotten to at least operation #13. These operations have been imported and updated from X7 and worked flawlessly there. Anybody else come across this?

 

K Stickel

C P Carrillo

[gcode]

check out this thread

I think you have your X9 machine def set for straight line rapids.. and in real life, your machine dog leg rapids

 

http://www.emastercam.com/board/topic/75105-how-to-address-dog-leg-rapids-in-the-x7-verify-or-why-does-verify-show-gouges-that-arent-there/

[Karl@CP PISTONS]

GCode, I thought of that but the crash is about  Z-1.0. It should  rapid up to Z.5 before any X,Y Rapid per my clearances values.

I even put the stock model as a simple cylinder with the top of stock at Z0 but still nothing there. Backplot show the rapid up in Z to .5 then moving to the next pocket.

I did try changing the machine def but still does not show the crash point.

Any other suggestions?

[Guest]

How about backplot?  Is that showing anything/.....

 

Can you share your file?

[Mike@Lustre]

do your guys single block thru the program we proofing it on the machine ??

 

verifying a program on the computer is one thing , but it will not show any issues related to set-up on the machine .

 

we single block a lot of our programs and it helps catch a mistake during the machine set-up.

[Karl@CP PISTONS]

JParis, I'll try to strip the file else I can not share file. Will try in the morning. Backplot also does not show this move.

 

Mike, We do NOT single block as this could take hours. Fixtures and tooling never change so there is NO setup, just load program and press start. Also there are no setup persons who could do that just operators. Up until X9 there has never be a need to run a program in single block.

 

Until tomorrow.

Thanks for the replies.

[Guest]

do your guys single block thru the program we proofing it on the machine ??

 

verifying a program on the computer is one thing , but it will not show any issues related to set-up on the machine .

 

we single block a lot of our programs and it helps catch a mistake during the machine set-up.

You don't single block 3D programs

 

You double check your clearance height and let it run to the tool change.....

 

I once had a setup guy come to me that he couldn't follow the program, there were too many lines of code going by too fast.....

 

It was a 12 megabyte roughing program.....

[Karl@CP PISTONS]

Never mind I am here, still so I stripped most of the drawing leaving just the surfaces.

3297_stripped.mcx-9

[Mike@Lustre]

You don't single block 3D programs

 

You double check your clearance height and let it run to the tool change.....

 

I once had a setup guy come to me that he couldn't follow the program, there were too many lines of code going by too fast.....

 

It was a 12 megabyte roughing program.....

never worked with a 3D item so I would not know , and from the image and the part highlighted in yellow it looked like it could be a interpolation move not 3D profiling . 

 

and I hear you ion trying to read code on big files when the Robodrill is doing some of the products we run and it's on VoluMill tool path the lines of code are just a blur on the monitor it moves so quick .

[Guest]

Never mind I am here, still so I stripped most of the drawing leaving just the surfaces.

 

Looking at your pics and your file, I can only surmise that paths #12, 13, 15, 18, 20 & 22 are the possible culprits.....

 

Nothing in the backplot, verify or posted code looks wrong......

 

That leaves  me to speculate, is your machine a Fanuc based control? I am wondering if you're not seeing the arc error that raises it's ugly head on occasion..

 

Other than that, there is nothing that jumps out at me as being an issue.....

 

I had had it happen and had to try different toolpaths to get it right....there are supposedly control settings that can be tweaked, I have never had the opportunity to verify that they work.

 

Might try a different path, 3D HS Scallop? HS Project......tightening or loosening your filter tolerances....

[gcode]

I agree with John.
The posted code is good, somewhere in all those arcs there is one end of arc statement your machine doesn't like
Since these toolpaths ran OK in X8 but not in X9, the first place I'd look is the Tolerance page of System Config.
I'd compare the X8 settings to X9 and see if there are any differences.

[Elmer Fudd]

Check your control def settings and see how your arcs are being broken. Is it the same as your older version?

[Karl@CP PISTONS]

Thanks for all the replys!

 

I'll look at the control definition first. Seems that the Update utility should set these things up as they worked before. All the Machines Defs, Control Defs and Posts are just updated to run in X9 with out any manual changing.

 

Anybody know if there is a parameter setting that will cause the machine to alarm when the arc is not correct?

[Leigh @ Kodiak]

 

That leaves  me to speculate, is your machine a Fanuc based control? I am wondering if you're not seeing the arc error that raises it's ugly head on occasion..

 

 

 

I have experienced this arc error on a fanuc control before. Does anybody know if Vericut will catch this problem?

[gcode]

I have experienced this arc error on a fanuc control before. Does anybody know if Vericut will catch this problem?

We recently had a bad crash due this issue.

A proven program that ran properly in Vericut and on 2 different Fanuc driven VMC's.

We moved the part to a 3rd VMC. 2/3's of the way through a roughing cycle, a 2" high feed cutter

plowed through a wall, destroying the tool , a $5k piece of Inconel and knocking the

machine out of alignment.

I  took the program out of the crashed machine and loaded it back into the 2 machines that had run it correctly.

In those 2 machine's it still runs correctly.

We've tried ensuring all the parameters are set the same between machines, but when you have different machines

from different manufacturers running different vintages of Fanuc controls, it becomes an impossible task.

The only bullet proof solution is to linearize the gcode... but then the files probably won't fit the control.

[Karl@CP PISTONS]

Thanks for the replies all,

There were differences in the arc settings on the control definition. Not sure how this would be different since these files are Read Only until I run the update utility then set back to read only. Next part was cut good so something was causing it to post the arc's incorrect.

Again Thanks all 

Karl @ CP-Carrillo

[MIL-TFP-41]

 

There were differences in the arc settings on the control definition.

 

Can you share what the differences were? I did look at your settings in the control def that you supplied, didn't see anything weird, but they are not the same settings we use here. Attached is the settings we use here, and have not seen this issue for quite some time. It has happened in the past tho.....(knock on wood)

[Karl@CP PISTONS]

I set the ARC options to break at 180 degrees and helix only in XY plane. Not 100% sure as part has not been returned (may not have been ran yet).

See attached.

[BenK]

I have been bit by the arc error before as well. Now I like to default to break at quadrants just to be safe. Produces a little more code but that's better than crashing a machine.

[civiceg]

http://www.emastercam.com/board/topic/82717-protip-how-to-set-control-definition-defaults/

 

Colin made a really good write up on changing your default control definition. I always had the problem of the control definition changing back to the default, every time we updated. Checking/updating all of my control definitions gets old, especially when I have 20+ control definitions. 

[Micromoldmaker]

 

I set the ARC options to break at 180 degrees and helix only in XY plane.

I was just about to ask if you were posting with "Post 3D Arcs" option.   I never do.  I have a phobia about posted files interpolating in planes other than X Y. 

[Elmer Fudd]

I set the ARC options to break at 180 degrees and helix only in XY plane. Not 100% sure as part has not been returned (may not have been ran yet).

See attached.

You might have to uncheck "allow 360 degree arcs".

 

When I had this problem I was using "break at 180 degrees" so I set it to 360 degrees and it has seemed to work so far.