Sign in to follow this  
rdshear

Part Crash Today

Recommended Posts

Today we had an unusual issue arise where a program that had passed verify and backplot in Mastercam X6, crashed at the machine. The program was helical milling an open bottom pocket perimeter to a given depth. Everything worked fine until the tool reached the depth and then the program wanted to move the tool to X zero to begin the bottom finishing pass. When it got to this point, the machine tried to travel a full circle to get to X zero which didn't work.

 

Here is a snippet of the code in the offending area:

 

 

9142 CC X+0 Y+0

9143 CP IPA-14.701 Z-1.956 DR- RL

9144 CC X+0 Y+0

9145 CP IPA-14.701 Z-1.957 DR- RL

9146 CC X-.472 Y-1.7993

9147 CP IPA+179.99 Z-1.9607 DR+ RL

9148 CC X+0 Y+0

9149 CP IPA+29.399 Z-1.9639 DR+ RL

9150 CC X+.472 Y-1.7993

9151 CP IPA+179.99 Z-1.9675 DR+ RL

9152 CC X+0 Y+0

9153 CP IPA-14.673 Z-1.9685 DR- RL

9154 CC X+0 Y+0

9155 C X+0 DR- RL

9156 CC X+0 Y+0

9157 C X-.3647 Y-1.3901 DR- RL

9158 CC X-.472 Y-1.7993

9159 C X-.5794 Y-2.2086 DR+ RL

9160 CC X+0 Y+0

9161 C X+.5794 DR+ RL

9162 CC X+.472 Y-1.7993

9163 C X+.3647 Y-1.3901 DR+ RL

9164 CC X+0 Y+0

9165 C X+.0007 Y-1.4372 DR- RL

9166 CC X+.0009 Y-1.8347

9167 C X-.2803 Y-1.5537 DR+ RL

9168 L X+.0009 Y-1.8347 R0

9169 L Z+5 R0 F MAX

/9170 STOP M9

 

and an illustration of the part. The pocket that posed the problem is the center bottom one.

 

Image1_zps574ce00d.gif

 

What I think happened is a rounding error between where Mastercam thought the tool would be Vs where the mill ended up. Watching backplot, Mastercam was 0.0007 away from X zero when it got to the equivalent of line 9153. Thus making the move to X zero would move the cutter that 7 tenths to begin the finish pass. I think the mill was past that point because of all the incremental moves and possible rounding and had to make a full circle to get back to X zero.

 

My questions:

 

Where would I turn off incremental polar angular moves so the numbers are absolute?

Would using toolpath filtering help or be the best way to 'fix' this?

Our original post was passed to us from an old contact about 10 years ago and has been updated very little (only as needed) to keep it running with current Mastercam versions. Could this be a post issue?

Would the control definition setting for End point checks (No rounding - break arc on failure) help?

 

Just trying to come up with a way to prevent this from happening again.

 

Thanks for any and all help,

 

Rick

Share this post


Link to post
Share on other sites

The machine is a Stanko Horizontal bar mill with a Heidenhain 426 control.

Share this post


Link to post
Share on other sites

Just a stab in the dark but maybe change your min arc radius to a larger number?

Share this post


Link to post
Share on other sites

I played with the filter settings and that changed the code generated to eliminate that move to X zero at the bottom prior to the finish pass. Filtering was off in the original path. The part of this that messes with my head is the fact that we never saw it coming. I don't normally see a difference in the way the programs run on the mill vs. what I see in backplot or verify.

 

Are the filter settings the best way to go about this or is there another more certain way?

Share this post


Link to post
Share on other sites

Try these settings in your control definition. Make sure you make a note of any changes so you can put it back.

 

image00141_zps35e7dc98.png

 

image00219_zpsb47ad104.png

 

Like I said this is just a guess.

 

Good luck

Share this post


Link to post
Share on other sites

Todd Tracey from Fastech

 

I'm ashamed to admit, but my G-Code skills aren't all that high. We program strictly conversational heidenhain. If I remember right, the I,J,K make up incremental moves Vs. Absolute with R. I, J, K, is similar to what is being output from our post in places and R in other. For the Helix moves, an absolute circle center is defined ( CC X+0 Y+0) then an incrementally angular move from the current cutter position to an absolute Z depth. (CP IPA-14.673 Z-1.9685 DR- RL) - Circular_Polar_move Incremental_Polar_Angle-14.673 Z-1.9685 Direction_of_Rotation- Right_Line_comp.

 

Now once it gets to the bottom of the pockets it all goes absolute.

 

 

Hockey Guy™

 

The settings in my control def are pretty good for the most part, but the minimum arc radius is set to 0.0001. We could try bumping that up, but I don't know how it would effect surface finishing paths.

Share this post


Link to post
Share on other sites

Set Control def to break arcs @ 90 degrees and then post again. That will probably fix the problem. if it does not then it might be small arcs, set it to .002 and try again. If that does not do it then it is an error with arc check and tolerance.

 

Only do one change at a time. Post then check on machine. 90% of the time break arcs @ 90 deg will solve the issue.

Share this post


Link to post
Share on other sites

I am not allowed to use any arc's or Helix moves whatsoever.

That way out of the blue we never get this problem.

Everything is set to .0001 and we post it from there.

Miles of Code and Crunch time but we never have to worry about anything.

 

I disagree with this theory but as the owner says

"I know what works"

Share this post


Link to post
Share on other sites

9142 CC X+0 Y+0

9143 CP IPA-14.701 Z-1.956 DR- RL

9144 CC X+0 Y+0

9145 CP IPA-14.701 Z-1.957 DR- RL

 

This is the only way Heidenhain handles the helical moves.

It's kinda like I-J-K. The CC-line is the arc center and the IPA in the next line is an incremental arc.

So there is not an exact X,Y endpoint, only the result of that arc.

The next helical move start from that 'not exact endpoint' with a new incremental arc and so on, that way you buildup the mismatch.

This is an contour with only arcs and at the bottom the cutter is complete from his position.

If there is a line in the contour then that linear move wil correct the mismatch.

 

Breaking arcs have no sense here, there are more IPA lines to the bottom then the mismatch wil be more

 

 

For this i would suggest the following for your post:

  1. Be sure that the IPA value always is rounded down to the 3 digits.
     
  2. Insert after every helical move line an linear move to the exact X-Y-Z position.
     
  3. Eventually skip that line for the full arcs ( IPA = exact +/- 360.000 )

BTW this is one of the very few things i don't like on the Heidenhain controls.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.

Join us!

eMastercam - your online source for all things Mastercam.

Together, we are the strongest Mastercam community on the web with over 56,000 members, and our online store offers a wide selection of training materials for all applications and skill levels.

Follow us