Unified morph

[So not a Guru]

I'm trying out the new unified toolpath. Why does this path create these moves in the corners?

TEST.mcam

[AHarrison1]

I've seen this with ball nose or rad tipped cutters where the path rides up to keep contact with the work.

[So not a Guru]

6 minutes ago, AHarrison1 said:

I've seen this with ball nose or rad tipped cutters where the path rides up to keep contact with the work.

This is a flat 1/8" endmill. The moves in the corners violate the containment. It's weird because the path cuts fine everywhere except the corners.

[JoshC]

you could try checking the Round Corners check box on the cut pattern page, then an additional page will appear underneath cut pattern called Round Corners, in that location enter a radii that is slightly larger than your tools radii.

[tmao]

It usually happens when the cutter DIA is bigger than the corner Rad x 2...

They never tried to solve this problem..

[So not a Guru]

I can fix it, using the old morph pass, by removing the floor surfaces, enabling collision control & tightening the step over chaining tolerance. But I can't get the same results in the unified path.

It's not a big deal, I'm just trying out the new path to see what it will do, and not do.

[Aaron Eberhard]

11 hours ago, So not a Guru said:

I can fix it, using the old morph pass, by removing the floor surfaces, enabling collision control & tightening the step over chaining tolerance. But I can't get the same results in the unified path. 

It's not a big deal, I'm just trying out the new path to see what it will do, and not do. 

A couple of notes: 

If you've got Unified set to "Morph," it's the same exact algorithm that the Morph toolpath uses:

vs

(Images above with no collision detection/corner smoothing).

In your case, you're using "Automatic - Morph" which is a completely different algorithm, so it's the same sort of problem, but it manifests itself differently. 

The older surface-based morph is a bit easier to understand, so let's take a look at why it does what it does (again, no trimming or corner detection):

You can see that it's trying to make sure it cuts every little bit available, so it will run the quadrant of the tool right to the edge of the surface.  It has "no knowledge" of the other surface at that moment, and relies on Collision Control to deal with it, or a corner smoothing post-process to analyze the resultant toolpath and trim it back to fit rounded corners.

The Geodesic method is a a completely different beast.   It's going to mesh the entire set of geometry and generate the toolpath on that.  It actually has two modes as you've discovered, Tool Contact and Tool-Center mode (pay close attention to the picture, for each, it's important):

Tool Contact mode is like making a stock model of your surfaces.   Tool-Center is like making a stock model with an additional offset of the radius of the tool (which is why it only works with full radius tools such as Ball & Lollipop):

All that is to say, it's the same basic problem as the surface based version, but it manifests kinda different.

With both versions of the toolpath, it runs through the magical black box that calculates the raw passes (and that's what's different), and the raw passes are generated from the center-tip.  Since the surface based version (old school Morph) is looking at individual surfaces, whereas the Geodesic (Automatic/Guide modes in Unified) will calculate a full mesh, which means that it "understands" that the corners exist:

(both toolpaths set to Tool Axis Control > Surface with no collision detection)

Look at how much denser the vectors are with the same tolerance Surface vs. Geodesic based!   That's because the Geo. recognizes that it will have to "roll" through the corner, and the old surface doesn't, it just runs to the end and then will snap to the next surface.

So, now that the Raw Passes are generated, now it applies the Tool Axis Control, which is just going to take all of the calculated points and tilt the tool, then compensate it outwards to maintain the tool contact point, which is why you get the old "Fishtail" with old style, and the weird looking comp thing with the new ones.  As you know, you can trim it up some with either Round Corners or Collision Control set to Trim.

One of the super-powers of the Geodesic version, though, is when you use a round tool like a Ball Mill..   Being able to calculate the corners properly means that you're going to generate a gouge-free toolpath from the get-go, no need to trim it up with collision or other tricks.   Here's what that toolpath would look like if you just ran ball mill in Tool Center Mode instead of a flat:

(View from approximately the top)

Look at that beautiful contact calculation!

 

Hope this helps your understanding!

[gcode]

Thanks for the explaination

[Colin Gilchrist]

Knowledge is Power.

Thanks Aaron!

[So not a Guru]

I must admit it took me quite a while to understand this. The term "geodesic" is pretty much meaningless to this high school dropout, even after reading the Wikipedia page on it.

After I figured out to replace "geodesic" with "curve" coupled with "guide", it became much clearer.

Thanks @Aaron Eberhard - CNC Software, this was very informative. I was able to go back and play with the operation & found a multitude of handy features.

[Aaron Eberhard]

1 hour ago, So not a Guru said:

I must admit it took me quite a while to understand this. The term "geodesic" is pretty much meaningless to this high school dropout, even after reading the Wikipedia page on it.

After I figured out to replace "geodesic" with "curve" coupled with "guide", it became much clearer.

Thanks @Aaron Eberhard - CNC Software, this was very informative. I was able to go back and play with the operation & found a multitude of handy features.

Glad it helped!  

I did a "deep dive" into the differences in some videos posted on our forums as part of the "2022 Multiaxis Improvements" threads.  I'd recommend you take some time and check it out if you haven't.  I forget exactly how long they are, but probably about 45 minutes total spread out across 3 videos:

https://forum.mastercam.com/Topic39690.aspx

The second one covers how "Geodesic" is used here, and starts exactly where you did, Wikipedia

This is a cool example of the different algorithms in action in the corners, so thanks for asking the question!  I'll have to incorporate something similar into future training info.

[So not a Guru]

2 minutes ago, Aaron Eberhard - CNC Software said:

I did a "deep dive" into the differences in some videos posted on our forums

Oh cool, I've watched several of Mastercam channels Youtube videos on thus subject. I forgot that I had subscribed to the MC beta channel too.

[motor-vater]

AAron if using center mode you would need to set your tool up in the machine to center aswell right? so if using a 1/2 ball you would have to modify your tool length to match the center point of your tool radius? I ask because I never have used CenterPoint for that reason but my thinking might be wrong? 

[Chally72]

On 7/24/2021 at 12:26 PM, motor-vater said:

AAron if using center mode you would need to set your tool up in the machine to center aswell right? so if using a 1/2 ball you would have to modify your tool length to match the center point of your tool radius? I ask because I never have used CenterPoint for that reason but my thinking might be wrong? 

This is purely a calculation switch, so you're not actually running at ball center in posted code- you're just changing the toolpath creation technique!

[motor-vater]

20 minutes ago, Chally72 said:

This is purely a calculation switch, so you're not actually running at ball center in posted code- you're just changing the toolpath creation technique!

good to know, ive always been scared.. Thanks for the clarification..

[So not a Guru]

2 hours ago, motor-vater said:

good to know, ive always been scared.. Thanks for the clarification..

Yes, I had always wondered too.

[gcode]

Back in the early days of 5X programming, ball endmills were programmed from the center of the ball because

the math was easier.

Both the legacy and ModuleWorks 5X toolpaths have switches to output to the C/L of a ball endmill 

 

[motor-vater]

2 hours ago, gcode said:

Back in the early days of 5X programming, ball endmills were programmed from the center of the ball because

the math was easier.

Both the legacy and ModuleWorks 5X toolpaths have switches to output to the C/L of a ball endmill 

 

SO USING THOSE SWITCHES IS DIFFERENT FROM THIS ONE?

[gcode]

1 hour ago, motor-vater said:

SO USING THOSE SWITCHES IS DIFFERENT FROM THIS ONE?

Yes.. 

Check out a legacy swarf operation.

The Tip Compensation switch on the Cut Pattern page  will affect posted gcode.

Now check out  the Moduleworks Unified toolpath

There is a Tip Comp switch on the Misc page that will affect gcode output

The Calculation Type Aaron was referring to changes they way the toolpath is calculated

The Tip  Comp switch controls how it's posted.

Back in the day, (late 90's. early 20's) I read articles that said

calculating and comping to the center of a ball endmill yield smoother running toolpaths

With modern CAM crunching the numbers and modern machines running the code

I suspect that is no longer true.

I would be interested in Aaron's 2 cents on this

 

[Aaron Eberhard]

Yep, you've got it, Tom!  This drop down only applies to how you're going to set the tool up on the control, and you'd know it if you needed it, every time you touched off a tool to be used in multiaxis you'd subtract the radius from the tool length offset.

And yeah, it doesn't really apply anymore.  Any reasonably modern control should be able to deal with tool length properly but you'll still find the old school shops that still do it because they were early adopters of multiaxis so they have decades of setups that required it.

As you probably know, REALLY old school machines didn't even have a tip comp mode at all, like a lot of peoples' introduction to the 5 axis world; Bostomatic.   If any of you guys ran a machine like that, you actually had a fixture that would make sure your tool was physically positioned at the center of rotation:

For 5 axis work, your tool length offset is 0, and your tool would be physically like this (from the front)

--------------------------------------------------------------------------------------------------------------------------------------------

So Just to be clear:

This setting:

(on the Misc page in ModuleWorks toolpaths and on the Cut Pattern page in CNC toolpaths) WILL MESS UP YOUR OUTPUT CODE!  It MUST match the way you set your tool length on the machine!

 

This setting:

only changes the way the algorithm calculates the passes on the model.  It WILL NOT mess up your output code, but it might not generate the toolpath the way you'd like as described above.  You'll see that in backplot.