Mastercam Optirough Stepup Parameters

[BugRobotics]

If I enable both ways it drops it down to 2.85 (2:51)

I tried both ways once, when they first released it and didn't like it at all

View attachment 349239

Yea I don't use it either. Looks like the CAMWorks is more efficient as it doesn't helix in and just plows material off in that one plane. I don't have an option to not helix into that area which would be nice.

 

[empower]

i dont see much use of just programming and comparing what the cam shows for cycle time. should run each program on a machine as that'll show the efficiency of the code much more.

 

[Marvel]

i dont see much use of just programming and comparing what the cam shows for cycle time. should run each program on a machine as that'll show the efficiency of the code much more.

I personally wasn’t looking for a comparison in calculated cycle time, I was more curious to see the actual tool paths created and to see how they differentiate from one CAM to the next. I just threw my estimated time and actual machine time in cause someone would have asked as some point.

For instance between my CAMWorks program and Bug’s HSMWorks program, for example the part perimeter part of the tool path. CAMWorks calculated to hit the 4 corners first whereas HSMWorks walked around the perimeter in one path which would have more engagement walking around the corners.

HSMWorks helixed down into the pocket feature from the top of stock whereas CAMWorks calculated that material was already removed and helixed down from the top of the already removed stock.


Sent from my iPhone using Tapatalk

 

[empower]

Or at least run all the progs through the same single backplotter (either NCPlot or Cimco etc) or failing that, everyone run it through their own same backplotter as everyone else, which is IDENTICALLY configured, to look at the time....
Machines will all vary because of acc/dec/rapid settings and machine size and toolchange time and spindle ramp up/down etc etc.....

i know, but if the test is done on the same machine then you're eliminating that variable

 

[BugRobotics]

I personally wasn’t looking for a comparison in calculated cycle time, I was more curious to see the actual tool paths created and to see how they differentiate from one CAM to the next. I just threw my estimated time and actual machine time in cause someone would have asked as some point.

For instance between my CAMWorks program and Bug’s HSMWorks program, for example the part perimeter part of the tool path. CAMWorks calculated to hit the 4 corners first whereas HSMWorks walked around the perimeter in one path which would have more engagement walking around the corners.

HSMWorks helixed down into the pocket feature from the top of stock whereas CAMWorks calculated that material was already removed and helixed down from the top of the already removed stock.


Sent from my iPhone using Tapatalk

The toolpath does a few passes around the perimeter and then bores down into the material. So not totally wasted as it's removing material but I would think that removing stock like the CAMWorks does would be more efficient and better for the cutter.

 

[Marvel]

The toolpath does a few passes around the perimeter and then bores down into the material. So not totally wasted as it's removing material but I would think that removing stock like the CAMWorks does would be more efficient and better for the cutter.

View attachment 349255

I see what’s it’s doing, I was assuming it cut that top surface first and then started that pocket cut afterwards. I’d have to go through my settings and figure out what changes that on mine, it used to default like that.

I did notice that perimeter difference though. In this scenario with a 1/2” end mill and 1/4” outside radius’ probably won’t notice it much. I have had parts lift going around outside corners engaging more with the corner though. I’d be curious if you dropped down end mill size if it would change that.


Sent from my iPhone using Tapatalk

 

[BugRobotics]

I see what’s it’s doing, I was assuming it cut that top surface first and then started that pocket cut afterwards. I’d have to go through my settings and figure out what changes that on mine, it used to default like that.

I did notice that perimeter difference though. In this scenario with a 1/2” end mill and 1/4” outside radius’ probably won’t notice it much. I have had parts lift going around outside corners engaging more with the corner though. I’d be curious if you dropped down end mill size if it would change that.


Sent from my iPhone using Tapatalk

I can get it to just plow the top surface (no helix) if I uncheck "machine cavities" but then that would require a second adaptive cycle to get the shallow pocket. If I had to machine this part I would definitely do that because that bore would annoy me.

I haven't ever had issues with more engagement around corners using the adaptive toolpath but I also usually only go with 0.075" engagement for a 1/2" cutter and favor lighter cuts. Takes a bit longer but I'm only doing 1-25 quantities so optimization isn't usually a priority.

 

[goooose]

Yea I don't use it either. Looks like the CAMWorks is more efficient as it doesn't helix in and just plows material off in that one plane. I don't have an option to not helix into that area which would be nice.

Its probably due to your max depth cut setting. If you adjust your max depth so you just hit that first large face, it won't see helixing into that pocket until the second stepdown.

 

[mhajicek]

In Mastercam X9, it wants to spiral down from the top of the stock, and estimates 3:10.3.



If I break it into two operations, above and below the broad face, it estimates 2:39.29.



I used no microlifts, a back feedrate of 5000mm/min (196.85IPM), and a gap size of 63.5mm (2.5in), which is when it chooses to retract as opposed to backfeed.

 

[BugRobotics]

Its probably due to your max depth cut setting. If you adjust your max depth so you just hit that first large face, it won't see helixing into that pocket until the second stepdown.

Yea, you're right, good call. Tool path looks good now.

New estimated time with that change is 2:51 with "both ways" on and 3:14 without which is what I would run.

 

[pato]

Yea, you're right, good call. Tool path looks good now.

New estimated time with that change is 2:51 with "both ways" on and 3:14 without which is what I would run.

View attachment 349273

And now it looks basically the same as the one I did in NX.