Jump to content

Welcome to eMastercam

Register now to participate in the forums, access the download area, buy Mastercam training materials, post processors and more. This message will be removed once you have signed in.

Use your display name or email address to sign in:

5 Axis Help


CamMan1
 Share

Recommended Posts

Could someone who has Vericut with a Head Head machine run some code thru and check for gouges. I have a small swarfing pocket in a part that is gouging the floor on the machine but it doesn't show up in Backplot or Verify. I can provide a small sample X7 file for it if necessary. I can't release the whole part file because of the nature of the work. I have never used Vericut so I don't know what is needed. We are trying to eliminate if it is the machine at fault. The machine is an SNK PC60V Head Head with 25 degrees range. Any help would be greatly appreciated.

Link to comment
Share on other sites

No Vericut here, but in my opinion, if you're not seeing it in MC then your post isn't doing what you programmed or you control isn't doing what your code is asking of it.

 

I've had similar problems with swarf when it comes to keeping the tool of the floor, so I end up using something like 5-axis Curve instead. I feel you have much more control over you tool on floors with it.

 

Put up a sample file, I'll be happy to look into it and do a quick double check for you.

Link to comment
Share on other sites

I was hoping Vericut wasn't that big of a deal to setup. I have been Trying to get a G-Code simulator here where I work but they don't want to cough up the dough. I was trying to explain to them that if we are going to do 5 axis work we need to have it. The other swarf cuts along the inside profile of the part cut just fine by the way. The machine has just been worked on by a reputable company to adjust the accuracy of the machine. All the toolpaths verified just fine in UVBS and the Machine Simulator. Anyhow attached is the partial file.

SNKPC60V 5 AXIS GOUGE ISSUE 2.MCX-7

Link to comment
Share on other sites

Are you getting really big gouging on the floors? Is it on the walls as well?

This maybe due to the multi passes that you have in your toolpath. I've never really liked the way milti pass work in this toolpath. Gouging was one of the main reasons. I know it's tough to get around it on a part like this though.

 

If you look closely from a side view you'll see that your tough passes are not equal in depth.

Link to comment
Share on other sites

The gouges are on the floor only. The further from the wall the deeper. The walls look great. When the tool is transitioning in the corner to change direction I am getting a pretty big angle move on the machine. Not nice small moves like I am seeing in backplot. It looks like the tool is changing angle before lifting the tool to compensate for the ball diameter. It looks like the tool diameter is stationary in xy when it changes angle which rolls the diameter into the floor before the tool lifts.

Link to comment
Share on other sites

One thing I found that may be giving you a problem with your toolpath is the geometry that you used for your chains.

The upper rail has lines at the ends, arcs in the corners, and an arc at the center of the chain, while the lower rail has lines on the ends, arcs at the corners and a spline in the middle. In my experience this is always been a no-no for swarf.

Both upper and lower rails must match as closely as possible for the control points to match.

 

Try making a three point arc from your spline at the lower rail, re pick your geo, regen and try it again.

Link to comment
Share on other sites

Also, I like to use "Wear" on my comp (control can take advantage of it), I use a tighter cut tolerance (.0005-.0001, code heavy, I know), and "Angle Increment" checked on.

 

My setup is a table/table though. I know the head/head is a bit harder to trouble shoot.

Link to comment
Share on other sites

Thanks for all the help. I will take your suggestions into consideration. First rule of order will be some adjustments to the post. It looks like it is removing some of the moves that are in the corner which is being removed by a max angle setting. Looks like we will be doing some trial and error on the post and the geometry till we get this straightened out. This type of cut is commonplace at our shop. The other programmers are afraid to try this type of cut so they will create multiple WCS and they will flowline or parallel cut out the excess and then use projected cuts for cleanup. It is too time consuming for me to do this but if I have to I will.

Link to comment
Share on other sites

Hey CamMan1 - I took a look.. I'm going to go out on a limb and guess that you don't have TCP (or rTCP if you prefer that parlance) on this machine? Head/head machines are notoriously sensitive to stuff like this (large directional changes in a single vector). What's happening is that your post is compensating for the tool length (you have to enter a length to pivot amount, right?), or maybe it's handled in the control with a G43.3, but all that's compensating for is the start and end points of the vectors.

 

In this case, picture the head moving from the last vector of the long wall (A) to the first vector of the short wall (B.) The two positions are correct, but what's happening between is that you X & Z moves (or Y & Z, I'm not certain how your machine is set up) should be compensated as the head rotates to keep the tool tip tangent, but it's not. It's moving the X & Z in a linear fashion from point A to B. The greater the angle change on each move, the more you'll gouge in between those vectors.

 

There's not a whole lot you can do other than break the vectors up to a smaller, acceptable gouge, unless you have TCP, you'll never really eliminate it. And that's all TCP really does is just (in the background) break up multiaxis moves into really small segments, and makes sure the axis are properly synced through them. You can get a large part of the way there by specifying a max angle increment, and for something like this I'd start in the .1* range or so.

 

The other option is to use the new Swarf toolpath instead of the classic. It's a lot more tolerant about things like this. You can see an example of the problem corner in these pics, and check it out on the file.

 

Cheers,

 

Aaron

SNKPC60V 5 AXIS GOUGE ISSUE 2 - ACE.zip

post-12334-0-75061700-1402335460_thumb.png

post-12334-0-00692200-1402335470_thumb.png

Link to comment
Share on other sites

Yes Aaron you are correct with the no TCP. And from what I am seeing on the machine it is what you are saying. The tool is making an angle change before compensating for the tip which is sweeping the ball into the floor.

Link to comment
Share on other sites

I would really like to stay with this type of toolpath because for me it is faster than what our other programmers are doing. And I am the one who does the majority of the 5 axis programming. Do you think I should just machine it a totally different way or will the new swarf possibly fix my issues?

Link to comment
Share on other sites

I would see if the new swarf helps you out, because the angular change is more gradual. The old swarf was extremely literal, so when the chains were out of sync, the toolpath was the same (as Oscar mentioned above).

 

Edit: Oh, and this would be an excellent case study for G-Code verification. If your control had TCP and you hooked up MachSim through your post, it would be 99% of the way there, but without TCP, this is a primo example of where you need to have something like CAMPlete or Vericut or whatever that simulates the machine motion the way your control interprets it

Link to comment
Share on other sites

I would really like to stay with this type of toolpath because for me it is faster than what our other programmers are doing. And I am the one who does the majority of the 5 axis programming. Do you think I should just machine it a totally different way or will the new swarf possibly fix my issues?

 

I understand what you are saying, but with the control and checking ability of this toolpath I can swarf with it no problem, but then nail down things I could never do with Swarf. I always had problems with swarf and would go to curve to control things to the level I needed. Swarf to me was never at that level and normally was my last choice to us in 5 axis toolpaths. I have had some heated conversations about it over the last 10 years and every time I through out the challenge on the difficult areas I was trying to machine many times people would agree Curve was a better choice. The new Swarf is much better than then old one since you have so much more control, but Morph between 2 curves is so much a change in mind set and direction hard to not use it where I used either Swarf or Curve before. Control is what we all need as programmers and you either figure out how to use the tool you have before which is Mastercam in this case or you use the tools after the fact like Vericut to help you limp along out of the problem you could not dial in to begin with. If it is machinable Mastercam can machine it so way some how. All else fails offsets the surfaces to the center line of the tool. Then drive it center line and then put everything like you need how you need where you need and know without a shadow of doubt you got what you need.

 

Oh and once you dial a process down with Morph Between 2 Curves you will be light years faster then the other way the old school not willing to change programmers are doing. :scooter:

Link to comment
Share on other sites

The gouges are on the floor only. The further from the wall the deeper. The walls look great. When the tool is transitioning in the corner to change direction I am getting a pretty big angle move on the machine. Not nice small moves like I am seeing in backplot. It looks like the tool is changing angle before lifting the tool to compensate for the ball diameter. It looks like the tool diameter is stationary in xy when it changes angle which rolls the diameter into the floor before the tool lifts.

 

CamMan something I have noticed as well in the multiaxis tpaths is if I'm using a mill with the same or larger dia than the corner, it will induce some whacked out movement in the corners.

Link to comment
Share on other sites

Crazy Millman, Are you saying that you can use morph between 2 curves to machine the excess material from that undercut from the top down to the floor? I did use Morph between 2 curves to lollipop the curved surfaces on the inside walls. I didn't think there was any other way to remove the undercut material except for one of the swarf toolpaths. I know I can create multiple WCS and use some Legacy paths to get the job done but that is not what I want. If you have the time I would greatly appreciate the help if you could shoot me over an example. I am definitely open to learning new tricks. Thank You Very Much for your input.

Link to comment
Share on other sites

what do you think of this here,....

I used parallel to curves and a chain for the tool axis control,...

I also changed the dia of the tool to 5/16 to see if it would interpolate the corners a bit better,..

Link to comment
Share on other sites
Guest MTB Technical Services

Hey CamMan1 - I took a look.. I'm going to go out on a limb and guess that you don't have TCP (or rTCP if you prefer that parlance) on this machine? Head/head machines are notoriously sensitive to stuff like this (large directional changes in a single vector). What's happening is that your post is compensating for the tool length (you have to enter a length to pivot amount, right?), or maybe it's handled in the control with a G43.3, but all that's compensating for is the start and end points of the vectors.

 

In this case, picture the head moving from the last vector of the long wall (A) to the first vector of the short wall (B.) The two positions are correct, but what's happening between is that you X & Z moves (or Y & Z, I'm not certain how your machine is set up) should be compensated as the head rotates to keep the tool tip tangent, but it's not. It's moving the X & Z in a linear fashion from point A to B. The greater the angle change on each move, the more you'll gouge in between those vectors.

 

There's not a whole lot you can do other than break the vectors up to a smaller, acceptable gouge, unless you have TCP, you'll never really eliminate it. And that's all TCP really does is just (in the background) break up multiaxis moves into really small segments, and makes sure the axis are properly synced through them. You can get a large part of the way there by specifying a max angle increment, and for something like this I'd start in the .1* range or so.

 

The other option is to use the new Swarf toolpath instead of the classic. It's a lot more tolerant about things like this. You can see an example of the problem corner in these pics, and check it out on the file.

 

Cheers,

 

Aaron

 

The SNK PC60V may have TCP depending on the vintage.

If it does, it's likely the older version G-Code for it.

As I recall, that machine came with a FANUC 16M and was before the i-Series were released.

Lots of guys on the west coast using an NIT system with that machine and running APT source directly.

 

Set the fanning in the Classic Swarf.

In APT systems this is similar to using a LINTOL command.

http://icam.com/Tech...esday/Tip40.php

Link to comment
Share on other sites

The SNK PC60V may have TCP depending on the vintage.

If it does, it's likely the older version G-Code for it.

As I recall, that machine came with a FANUC 16M and was before the i-Series were released.

Lots of guys on the west coast using an NIT system with that machine and running APT source directly.

 

Set the fanning in the Classic Swarf.

In APT systems this is similar to using a LINTOL command.

http://icam.com/Tech...esday/Tip40.php

 

Yes it is a 16M control. It was built November of 1995. I hate to admit it but I have no idea what an NIT system is or APT source. Could you please explain. I really appreciate the feedback. We did manage to eliminate the problem. We changed the post by adjusting brk_mv_head from 3 Degrees to 1 Degrees and changing brk_tol from .001 to .0001. Then in my parameters in Swarf I changed Angle increment to .5 Degrees which I did not even have turned on. My Bad. Then changed Wall Following method to Cut Tolerance of .0002 and Max Step to .010. I attached pictures to show the difference it made. Went from .010 deep gouges to .0002 deep transition marks. I am happy with it as long as it stays this way.

post-40422-0-81579000-1402415020_thumb.jpg

post-40422-0-70448200-1402415037_thumb.jpg

Link to comment
Share on other sites

We did manage to eliminate the problem. We changed the post by adjusting brk_mv_head from 3 Degrees to 1 Degrees and changing brk_tol from .001 to .0001. Then in my parameters in Swarf I changed Angle increment to .5 Degrees which I did not even have turned on. My Bad. Then changed Wall Following method to Cut Tolerance of .0002 and Max Step to .010. I attached pictures to show the difference it made. Went from .010 deep gouges to .0002 deep transition marks. I am happy with it as long as it stays this way.

 

CamMan would be surprised how many times the things like that create the problems most programmers see when it comes to 5 axis. People forgot posts are just a translation of the idea to the machine. If they were dialed into what you have majority of people would complain they are getting to much code since majority of the time what was set got the job done. It is these situations where having it all under your control and understanding leans itself to get the best output possible. Having Vericut, ICAM, NC Simul or any other Verification program would help, but getting a in depth understanding you just got will help in so many other areas not even funny. I am glad you came back with that answer, but sadly majority of people coming to this forum will breeze over this topic and use it as a how much Mastercam Sucks, verse how getting everything dialed in to get the job done correctly helps. I looked at your file and yes Morph Between 2 curves will cut what you are doing, a little more work than the new Swarf so I backed off. Still a great toolpath and yes it will still cut it, but in time you will embrace the different toolpaths as you get more comfortable out preforming the other programmers. A topic like this gives me hope others are just as crazy as I am pushing the status quo and not into accepting what we have done is the only and correct way to get the job done.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

  • 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

×
×
  • Create New...