Haas Crash with HSM Program

[Wuf Man]

Been running Mcam9 for 6 months with HSM. In the last two weeks been having problem with roughing pocket tools crashing. Every thing verifies OK, but tools crash through parts mid-way through program. Thoughts?

[Psychomill]

A coulple things,....

 

whats the code look like where it crashes? And what do you mean by crash? Is it just gouging or the tool goes thru the part in Z? HMC or VMC? 2D pocket or pocket surfacing? Might need to see the file... and need a little more info.

 

And... Welcome to the Forum.

 

[chris m]

Crash how? Gouge the part, rapid the collet chuck through the part, shank out on the part, etc?

 

I guess I'm too slow...

[gcode]

Mastercam Verify rapids in straight lines

A Haas rapiding from point to point does not.

If you are rapiding down inside a pocket, sooner or later you're going to hit a wall.

Verify will not catch it. You need gcode verification for that.

[Scott Sizemore]

Are you using shortest path in HSM? If you are you should use the map to high-feed function.

[Randy Maynard]

Gcode is right. Many machines have "dogleg" rapid moves as the default. It is a parameter that can be set in the control.

 

Backplot and Verify do not show this because THE MACHINE ACTUALLY INTERPETS AND MOVES DIFFERENTLY, from how the code is output.

 

(Metacut Utilities will simulate dogleg rapid moves)

 

The solution is to be sure your rapid plane is well above the highest point on the piece.

 

I've never seen HSM gouge. But, I have seen dogleg rapids reach up and bite you!

[Müřlıń®]

quote:

---

The solution is to be sure your rapid plane is well above the highest point on the piece.

---

Ben doin' that since ver 6......just to be sure +1 I also set zero at highest point on part to get the double whammy....haven't crashed in several years....knock on wood

 

quote:

---

You need gcode verification for that.

---

CAD CAM verify needed to do GCODE from the start IMO...

[Roger Peterson]

what gcode said. In the hsm have it convert your rapids to a rapid feed move if you think this may be the problem.

 

 

HTH

[Wuf Man]

Not sure about the code question. I am not familiar with the NC code. The toolpath is HSM Pocket Strategy. The crash occurs in the X-Y movement (Tool is moving from the outside to the inside of the part), Using full retracts, no rapid down movement, rapid plane is well above the highest point on the piece.

[Quickmike]

If you can post the file I'm sure someone might be able to help.

[Wuf Man]

The file post fine. It just crashes when you run the machine. We are using a 1.250 inche roughing tool 3.625 inches long for the HSM Pocket Strategy. It is crashing through the side about 2.0 inches down from outside-in.

[chris m]

quote:

---

Not sure about the code question. I am not familiar with the NC code

---

OK, not trying to be a dink here, but this could propose a problem trying to help you diagnose your situation; can you paste 20 lines [or 50, whatever seems reasonable] around where the unintended workpiece contact [AKA crash] occurs into your reply here so that we can see it?

 

C

[SHEP]

We had a similar problem, our dealer changed the post for us to seperate the rapid move in 'z' and 'x y', when before all 3 axis did a rapid move at the same time, went through a couple of side walls, ours was a Haas also. Hope this helped

[Mike Mattera - TFM]

Are you doing arc filtering? If so are you doing IJK or R for the arc moves.

 

Mike Mattera

[Randy Maynard]

Wuf Man,

 

You did say v9 right? Does your post have a variable called mtol? If so, what is the value?

 

I am thinking it is a small rounding error caused by using an older post with a newer MP. This situation is rare and elusive. But, I have seen it.

 

If you do not have mtol, I would add it. If you are outputting 4 decimal places, I would set mtol to .00005.

[Jimmy Wakeford from Barefoot CNC]

If Wuf Man makes the program on one pc it works fine. On the second pc it gets this strange rapid in it. If you take the mc9 with toolpaths to the 1st(good) pc it posts the strange rapid. We thought we had it figured out by turning the graphics acc down, but reappeared earlier this week. They have been cutting molds for a couple of years using the same process.

[gcode]

quote:

---

If Wuf Man makes the program on one pc it works fine. On the second pc it gets this strange rapid in it. If you take the mc9 with toolpaths to the 1st(good) pc it posts the strange rapid

---

Do you regen on the "good" PC before posting??

Are both machines running the same MP.DLL ??

This is Twilight Zone stuff

[chris m]

I'm with gcode on the .dll thing; I had a bad .dll file on my box and I'd get some crazy output from a file that posted fine on the next machine down

 

C

[Jimmy Wakeford from Barefoot CNC]

Yes regen produces bad code, re-pathing produces good code