Axis Substitution posting in 1.16 degree increments

[balnh]

I have a simple toolpath that’s posting with many breaks in the C axis motion. I am using generic Fanuc 5 axis post. Subbing x axis for C on a table-table AC machine. I did a search and read about brk_mv_head and brk_max_ang. I set them to 1 and -40 respectively. Did not change output. I tried different combos and didn’t affect output at all. I downloaded the newest 5 axis post from the Mastercam website and got the exact same results. I posted with 4axis haas post and got perfect nc code. I have come across this in the past and I was only doing some deburring and didn’t think twice, this toolpath is a flow line so it’s taking about 30 c axis moves to move about 60 deg or arc. Just mildly annoying but the machine will run the program. Is this something in the post that can be fixed? 
 

Thanks

[cncappsjames]

Unfortunately CAM system code will never be as efficient as you could produce by hand. The reasons for this are many and include but not limited to geometric issues/settings, post settings and toolpath settings.

[JParis]

Without seeing the geometry it's impossible to say but I wonder if this is something rolled/unroiled geometry could help with...

[balnh]

9 minutes ago, JParis said:

Without seeing the geometry it's impossible to say but I wonder if this is something rolled/unroiled geometry could help with...

I did unroll the geometry, created a flat surface from the wireframe. The code posted from the 4th axis haas post I have is short and sweet. That’s subbing the Y for A. 

[crazy^millman]

Generic Post says it all to me. No File sorry not in the mood to play 100 guesses.

[balnh]

4 minutes ago, crazy^millman said:

Generic Post says it all to me. No File sorry not in the mood to play 100 guesses.

Fair enough, that’s what I figured with the generic post. 

[balnh]

Here is a screen shot. The feature in question is the red face. The part sits on center on the COR. The undercut is concentric to the bore and outside. No angles on it just a cylinder. 

[#Rekd™]

Did you try Multi-Axis Pocketing toolpath?

[balnh]

59 minutes ago, #Rekd™ said:

Did you try Multi-Axis Pocketing toolpath?

I don’t have a multi-axis liscense. I ran the parts no problem, roughed with optirough with axis sub.  My question was why does the generic 5 axis post break up the c axis motion so much with Axis sub toolpaths. My generic Haas 4 axis post posts nice short Nc code. I figured it was generic 5 axis post limitation. 

[cncappsjames]

1 hour ago, balnh said:

I don’t have a multi-axis liscense. I ran the parts no problem, roughed with optirough with axis sub.  My question was why does the generic 5 axis post break up the c axis motion so much with Axis sub toolpaths. My generic Haas 4 axis post posts nice short Nc code. I figured it was generic 5 axis post limitation. 

BITD (mid 1990's) I did a test between wireframe toolpaths (2D Swept) and a surface toolpath (flowline) and pretty much came up with the same results as you did. The wireframe toolpath produced far less code than the surface toolpath did.

What I never did a deep dive into was the exact reasons "why". Someone smarter than me will have to come and provide that answer.

Where is Jack Summers or @Pete Rimkus from CNC Software Inc. when we need them?

[crazy^millman]

6 hours ago, balnh said:

Here is a screen shot. The feature in question is the red face. The part sits on center on the COR. The undercut is concentric to the bore and outside. No angles on it just a cylinder. 

Axis sub will not machine a 5 axis feature. That is a 5 Axis feature the walls are not normal to the radius. Even Multi Axis Pocket will have issues with that to make the walls perfect. It would rough nicely, but that will need to be done on a 4 Axis with 4 Axis Swarf to finish the walls. You don't have Multi Axis so then will need to machine that in 3 operations.

[Aaron Eberhard]

5 hours ago, cncappsjames said:

BITD (mid 1990's) I did a test between wireframe toolpaths (2D Swept) and a surface toolpath (flowline) and pretty much came up with the same results as you did. The wireframe toolpath produced far less code than the surface toolpath did.

What I never did a deep dive into was the exact reasons "why". Someone smarter than me will have to come and provide that answer.

Where is Jack Summers or @Pete Rimkus from CNC Software Inc. when we need them?

I'll bet you could figure out the answer

When you have a wireframe toolpath, you're handed the contour to follow.  If that contour is an arc, you'll be handed an arc to follow.  If it's a spline, you'll either have to fragment it based on tolerance, or, generate the toolpath then filter it back to an arc if you can .

When you're handed a surface, you're not handed an arc.  You have to fragment the surface based on the tolerance of the toolpath (just like a spline based Contour).  You may be able to filter it back to an arc, but you may not.

For example, here's an arc (black), and a duplicate of it that I used Spline From Curves (red) on.  Notice the same exact Contour toolpath's vectors:

That's what's happening in 3d if you use a Swept vs. (any) surfacing toolpath.