I do both. It really depends whether there is a risk of collision or if the customer for some reason wants a thread of some "accurate" length.

IIRC there used to be a view which shows the axis min-max values for the open program file, but I can't find it anywhere any longer! Has it been removed?

Why not learn a real programming language and code a mobile game or something cool? Macro-B gets boring pretty quickly. But if you want some challenge, google "youtube laser zelda/mario" and do something similar with a mill or a lathe...

Well re-defining the tool with a corner R big enough (so that R = (tool max diameter - minimum cutting diameter)/2) did the trick! So looks like it does not cut like a sharp corner...

Thanks, I don't have a file ready yet.. does Mastercam take the custom tool geometry into account when computing the toolpaths or just the nominal tool diameter? I remember having tried using a custom tool over a year ago but the toolpaths were the same iirc.

As mastercam doesn't support high feed insert geometries (such as H600 wxcu we commonly use) the toolpaths always tend to leave a "bump" on the roughing surface that overloads the cutter on the next depth cut. The only solution is to reduce XY stepover but that results in longer machining time. Is there any better workaround?

Nearly every time I come to the computer and there is an open Mastercam file, it asks whether to save the changes or not when loading another job. I am told to always choose "save" because maybe the workmate has forgot to save. However, there are MANY situations where we make temporary changes to the Mastercam files and I usually have no idea if the currently open project is one of them. For this reason, I'd myself prefer to always choose "don't save" (the programmer's job is to make sure to remember to save; if there was a power cut, all would be lost). Which one do you think is the better practice?

Now that this thread has turned into a wishlist, I'll add another tiny request: each code window should be associated with the path the code window's file was opened/saved in. Currently Cimco always uses the folder any file was last opened from or saved to.

The color tagging is not as extensive as in wm. I can live with that, but what I miss the most is a file-wide comparision bars (See the two left columns in http://winmerge.org/about/screenshots/screenshot_small.png Version 7.

Doesn't work in X9, dragging an MCX file into anywhere in the program window area just opens the file..

Sandvik has also some good info on chip thinning: http://www.sandvik.coromant.com/en-us/knowledge/milling/getting_started/general_guidelines/max_chip_thickness The bigger the lead angle, the faster can go. I love the Pokolm Quadworx high feed milling tool for fast material removal. The lead angle is 80 deg and it can feed 1.5mm (=0.06 inches) per tooth with 0.8mm (=0.03 inches) depth of cut in tool steel (HRC 33).

I use Cimco 7 as the primary code editing tool and would like it a lot more if - it was possible to use WinMerge or any other external tool for code comparision instead of the internal comparator (wm is IMO superior) - there was a favorites tab under the Open/Save dialog. Browsing through the nc file folders over and over again is very tedious.

Thanks for the help. Quality slider has no effect and neither does PrecisionIndex. It it just now a very high-polygon pencil. I started a new file and created a similar toolpath with a ball endmill and voila, the pencil is gone. So, thus far it seems I have to recreate my project from scratch to eliminate this issue as 2017 is not an option... yet. *sigh*

I don't recall encountering this problem in the past but now whenever I try to run verify on surface parallel toolpaths, my ball endmill tools are not round but 90 degrees sharp. Is it just me? Edit: all three tolerance settings under backplot/verify options are set to 0.0025. Attached the problematic file. FAIL.mcx-9

This is probably fixed in 2017, but in case it's not: when I copy-paste a helix-bore operation and choose another tool and recalculate the feeds and speeds, the feed at final depth is not updated. It will be updated only if I switch to the rough/finish page. Almost lost a tool because of this...

WOW those multiaxis toolpaths are brutal to learn!! After a "bit" of messing around, I finally got the swarf to work. THANK YOU VERY MUCH! Example attached (I couldn't make it work using the original geometry/surfaces, the tool control was completely lost) Now it's finally time to go home and sleep... 3D POCKET SWARF.mcx-9

I have little experience with the multiaxis toolpaths and just can't get this one to work. I'm trying to mill a simple eccentric pocket to the cylindrical surface in a lathe, which has both Y and C axis. However, there is something I can't figure out since no matter what, the result is never right. I've never done this before with this machine. Attached is the troublesome Mastercam file (X9 MU2). The first toolpath is a simple C-axis contour, it does not work at all. The second one is much closer to the truth, but the arcs (bottom corners) are machined improperly. You can see that well from the right view. I'll be more than eternally thankful if someone could help me out with this! 3D POCKET.mcx-9

Well it definitely is not you. There are numerous usability glitches in X9 that should be fixed (especially in the op tree). It's the small things that annoy the most..

AFAIK you can't specify it in mastercam, it's a system parameter. On fanuc it's one of the 51** parameters. Not sure about your control..

I have found it incredibly hard not to look for tools and wander around all the time even in our "tiny" shop. For best results, everyone should have their own tools inside their own lockbox and engrave each one's tools with initials. This way you can only be angry at yourself if your tools are missing. And if somebody else touches your tools...

Wouldn't it be cool if you could type something like "spindle_on$", "optional_stop$", "coolant_on$" etc in the manual entry and the post-processor would use this pseudo-code to convert the codes into actual G and M-codes, instead of using the machine-specific codes?

Stock models are cool, but what I dislike is that in the op tree a. the work zero number is displayed (it doesn't really matter) and b. the NC file name is NOT displayed (it really matters). I also wish there was a way to hide them permanently inside the stock model dialog, just like you can hide the default stock. Edit: oops, got mixed up with stock model and manual insert! The first sentence applies to manual entry, not stock model...

Managed to do this using waterline HST toolpath with the profile extruded as a drive surface and a boundary containment, if there's an easier way, I'd like to know...

I need to cut a 2D profile to a cylinder using depth cuts. It takes very little material at the beginning, so I'd like to apply the "rest-machining" method using a stock model to a simple 2D contour to eliminate air cutting. Is This Possible?

It doesn't look too strange, I'd do what the error message suggests. More strange is that the programmer of the simulator middleware failed to handle this error correctly and show this message box only once (assuming the error concerns the same tool).