Optirough_Rest_Problem_2020.mcam

This will fix things in OP4

1 minute ago, Seedy steve said:

Veiw sheets????

somehow this thing (2018) just created two planes and a view sheet, all at once when i finished creating a simple contour path!!!

idk why. now it has an association between sheet and plane that won't go away. and i can't delete either one. WTF???

I have never used these sheets. don't even know what they're for.  Strange stuff has been going on lately like this....

Did you start the file with an imported file?

Yes, the 19 bullet points in the above video explanations and some write ups in the What's New document installed with Mastercam 2020. The videos above are really good! 

Changes to chaining go far beyond the interface in 2020.

Yes, I can understand that.

On another note. You mentioned you stay away from stock models due to processing time. Stock models process pretty fast when tolerances are aligned. I can see the time maybe taking long if you never adjust the stock model Path tolerance from default, especially on large files. I created a very clean stock model from  OP7 and OP8 in less than 2 minutes using the initial stock shape provided on level 5. the Path tolerance was set to .015 which is still far less than your.05 stock to leave. Remember, stock models are captured in the file so they are safe for long term archiving.

I also noticed someone put a suggested workaround in that file to use a stock model (OP10) that references your STL file after it was imported onto level 200 as a Mesh entity. That too is a viable solution as you will now have the STL data preserved as it is  saved locally on level 200 and a clean stock model from it as referencing a Mesh entity or external STL goes through a clean up process on the triangle data during stock model processing. Your STL was not clean and watertight saved out of verify, that is why OP9 gouges as OP9 simply references the troublesome external STL file. OP11 is clean because the troublesome STL file was brought in as a Mesh entity on level 200 (which is still troublesome) and then selected for Stock Model 10. Upon processing Stock Model 10 the selected troublesome Mesh data was cleaned up, that is why OP11 does not gouge.

Hope this helps some.

Thank you, I'll start with looking into R-18569. I'll have  a read on that ticket as well...

On 1/19/2019 at 8:19 AM, sharles said:

Well,

2019 continues to underwhelm me. They effed up the .stl's that I've used forever with surface high speed area rest roughing. The tool dove right into a bunch of stock. CNC Software noted it as a bug, and just said to create a 'stock model' instead because that would fix the problem. They also effed up the surface high speed scallop rest passes. Over on mastercam.com, CNC Software again said it was a bug: their answer, again, just create a stock model instead of using 'roughing tool'. Problem is these d@mn stock models take a LOT more time to generate for my programs than the .stl files I used in the past... A LOT MORE TIME. And, of course, who knows when CNC Software might get around to fixing it.

 

I'm feeling a little screwed. I argued with our owner to keep Mastercam instead of going to Tebis software, but thus far 2019 has been a pain in the @ss and I have yet to see what it had over X9 other than more glitches, more freezing and shutting down mastercam, and more need of work arounds to do the same things X9 did correctly.

Could you provide any Request or Defect numbers from your 2 concerns you contacted us with? I would like to look at your part files relating to the Rest roughing and scallop rest pass concerns.

It all boils down to understanding how your tools are consumed by toolpaths while realizing defining tools accurately is paramount. Hopefully you all see how we try to balance flexibility against not making the software too flexible which can introduce confusion. We don't want to go crazy adding all sorts of exceptions. A tool can't behave this way over here, that way over there, another way somewhere else. Hard to learn and teach. We chose to make Face Mill behave oneway relative to it's cutting diameter and gave it one exception by supporting the 2D Contour Chamfer toolpath recently as we felt there was good continuity there, facing blocks and cleaning up the edges go hand in hand.

We have the 3 main generic tool shapes for 90% of work, Flat, Bull and Ball. Then we have special tool types like the Face mill, used for Facing blocks and also useful for chamfering the block after facing. Yes, the 2D Contour set to  'chamfer' on the cut parameter page will comp accurately to a Face mill with chamfers. Those two things make good sense for Face mills, other than that you have to go a different route using Flat, Bull or ball.

On 10/31/2017 at 10:07 AM, MIL-TFP-41 said:

Ok, what if my 2" diameter facemill has a 1/4" radius? Use a bullmill?

You use a bull mill if you want to accurately comp the side of the tool, like in a Contour toolpath, yes.

5 minutes ago, gcode said:

I feel your pain... we have old legacy NC files here that defy all the rules of modern manufacturing.

We've been doing it wrong for so long it's too dangerous to do it right

As long as the old hands run the jobs all is well, but as soon as we put a new hire on it, its a forest of red tags.

Well said gCode, same thing goes for software development. It can be dangerous to change a legacy behavior affecting potentially 10's of 1000's of users. with 100's of 1000's of files out there.

I'm sure you all already know this, but just reinforcing. Safest thing to do is define your Face Mill for facing as you get clean overlaps and such and define the same tool as a Flat or Bull nose endmill. As long as you use the same Tool# in Mastercam you can safely use the single face mill on the machine.

 We also must way the impact of such changes. Changing a tool comp is very serious, massive impact, as it will destroy all existing files upon a regen in the version of Mastercam with the change. We have not received a high number of complaints on this comparatively speaking. But that doesn't mean a change is not justified, we just have to tread very lightly with tool comp changes.

Yes gcode, I am currently discussing if we should be using secondary diameter for face mills in toolpaths other than facing with my Mill Team. Stay tuned. It's been this way for decades with very few complaints so it will be hard to get traction for fear of messing up regens in legacy files!

Some times, depending how you are using a tool, you must define it as two different tool types. For Example. I had this 3/4in all in one type tool. I could chamfer, spot drill and side mill with it. I used it to Spot drill in my part file at Tool #6. So I initially defined it as a Spot Drill tool type. Later, I was using our 2D Engrave toolpath and wanted to us it as an engraving tool as it could very well handle it.  The tool was already in the carousal and would do a good job. I selected it and received an error, no toolpath output. Engrave did not like the Spot Drill tool type. So I created an Engrave Tool type and assigned Tool #6. Yes, I received a duplicate tool # warning but I new what I was doing and Mastercam allowed me to define two Tool#6 tools that Mastercam would consume very differently even though it was the same single tool on my machine.

I was milling Aluminum billet Detroit Lions magnets!

21 hours ago, JoshC said:

sounds like you guys found a solution but i wanted to mention that a tool not accurately defined can cause this too. The last time i had this problem on one of our parts it was caused by me not fully defining the tool accurately, if your Corner rad of the Tool is not accurate then this could be the problem because a Flat end mill would use a different step over amount than a Bull end mill would.

Thank you Josh, you stated my entire point of this thread. We must define tools accurately as Mastercam will intelligently apply them based on definition. Did you know...there are actually two very different processing logics behind Dynamic technology. One based on flat sharp endmills and one based on Bull nosed endmills. Ball cutters are simply treated like Flat sharp endmills. Using a Flat or a Bull can affect OptiRough processing time, there is more happening with Bull nosed to ensure no material islands or nubs are left behind...

I can look into the face mill and Contour interaction.. 

Here's your original tool leaving material. You basically defined a flat endmill for toolpath compensation (yellow) and told Mastercam to use the custom profile (aqua) for backplot, verify and stock model as that would truly represent what will happen at your machine. Nothing is wrong here. Stock Model, verify, and your machine all show leftover material, that is correct.

Mastercam does what you ask. You asked it to use a sharp endmill shape and you loaded a different shaped tool at your machine. 

2 minutes ago, MIL-TFP-41 said:

What I was getting at was something like this:

That is a facemill. Not a high feed cutter.

Agreed my example was of a high feed cutter.

 

regardless, you used a sharp face mill with a custom profile, Mastercam never comps to the custom profile. At least define your face mill with a full radius and try to get it close to your actual tool profile. Here's your tool with a tweak. Look at the attached file, two good toolpaths with your tool tweaked and my highfeed, both correct. There are no problems here against facing.

dynamic face_DC.mcam

There should be nothing wrong with the facing toolpath when tools are defined correctly and arc fit tolerances are reasonable.

You did not define a highfeed cutter? You defined a Face mill cutter to look like a highfeed cutter. If you use the actual HighFeed tool type we take care to comp accurately to the bottom highfeed profile. Mastercam is comping your tool as defined like a sharp endmill, the picture shows it on the definition page. Blue flutes represents your profile shape, yellow flutes represent what Mastercam uses to comp.