You can still access "surface finish parallel" via the RMB in the toolpath panel. You can also add a button on the ribbon bar toolpath tab if it's something you use frequently. You can get similar, and even better results, using the HST scallop. But it will require a containment boundary set to contact point. use silhouette boundary to create the containment boundary.

yes, your post that creates the .nc file can buffer out as much or as little data as you would like to an external file. at the end of the posting process it can also launch a .set setup sheet or a .dll or a standalone .exe file. what's best or easiest really depends on what format file you are looking for. .set files are very easy but won't give you graphics or screen shots of your part / toolpaths. I'm unsure how you would automatically launch an active reports setup sheet, it would probably take a chook. It would also be possible to have the setup sheet scan the .nc file for toolchanges and record the associated N line number.

oofta, I've been down this road it's sticky. Getting it to work is fairly easy. In your post use a buffer to save a file that lists the tool # and associated N#, along with any other data you want. This file can then be read by anything; .set, nethook, chook, active reports, etc... You can also have the post automatically run a .set file or chook or nethook that would read the data at the time of posting. the oofta part is one minor change manually made to the .nc file and it's all out of sync after a renumber. So now your at the point you need to scan the actual nc file after it has been edited which is a much bigger job. HTH

Now that I'm on a pc I can see your code. I'm not sure if rpar will read before pheader$ without testing, If what Colin laid out doesn't work there are other ways to handle this. 1.Output header data in psof$ and send the tooltable to a sub and merge it back in so it is below the header data. 2. I'll assume you are importing a lot of toolpaths which causes some extra steps like editing the nc name and program #. You can use a vb script or nethook to do your posting, the script/nethook would set/check the nc name, program #, etc... for all the toolpaths selected for posting and then post the code just by hitting one button. 3. There are some useful options in the config file for naming the nc file, but nothing for the program #. HTH

If progbo$ = 0, progno$ = xxx

If your machine doesn't have tool management there are fairly simple options. Here is one option you can do without a binch of macro code or post edits: 1. Call a sub at each location. Mpmasrer has a sub call drill cycle. 2. In your sub build a counter, once it gets to 5 "GOTO" a line that retracts the tool and resets the counter. 3. "Resume" the .nc file. 4. If your controller doesn't have a resume function build anorher counter into your sub to keep track of total locations so you can restart at a line #. Edit post to only output line #'s on sub callout lines.

One of the the most useful things in Mastercam is "File | File Merge / Pattern". Something I have done for two decades is use "Template" files to really speed up the programming of common/repetitive parts. With a "Template" file You can merge your CAD file into a .mcx-9 file that already has: 1. All the toolpaths you use with lead in/lead out, stepover, feeds/speeds, etc... already setup - just select your geometry 2. All the Tools you use 3. Planes pre-created wherre all you have to do is set the origin to your custom geometry 4. Pre-named levels for you to copy geometry to Using a "Template" file is easy, just open your "Template" and "Merge" in your CAD file. You now have a huge head start on getting that job done. The only real downside to using a "Template" file is I cannot drag & drop a cad file into Mastercam X9 and have it merge the geometry. To use the Merge function I have to do it via the File menu or a shortcut icon. Lots of clicks just to open a file. Hope this helps

circlemill is great, helixbore is great, dynamic mill is great, and ramp contour is great. Each of these have scenarios where they outshine the others, and a good programmer should know when to use each. The type of tool, does the tool centercut, the size of the tool relative to the finish size of hole, size of tool relative to pilot hole size, depth of hole relative to size of endmill, tolerances, tool life, programming time, run time, etc... all play a part in toolpath selection when doing a simple round hole or counterbore. For me circlemill is a toolpath I have always relied upon. The ability to do multiple sizes in one toolpath, ability to plunge at center, the ability to specify a helix dia so the center of my tool is in pilot hole, the ability to do finish passes with a different speed and feed and cutter comp all in one toolpath, the roughing portion will outptu simple arc's for machines with limited memory, the ability to rough and finish with depth cuts, and here's a big one, copy a drill toolpath and convert to a circlemill (or use "last" selection during creation), etc... Circlemill is far from useless, but there are always scenarios where ramp contour, helix bore, or even dynamic mill and a separate finish toolpath are simply better. Maybe a topic that discusses round hole applications and what worked best in specific scenarios would be useful. JM2C

On a machine like the Roeders with advanced lookahead functionality, and depending on application, a good starting point for the fixed segment length (actually a max segment length) is 5% to 10% of the cutter diameter assuming you are finishing with a ball endmill. it's easy to make a change and compare to your existing toolpath in backplot, just turn on the display endpoints function. You may have to go even lower than 5% depending on application Having the post linearize arcs based on chordal deviation is no the same as outputing code at a fixed segment length. Using chordal deviation will create relatively long moves based on the arc radius. Fixed segment length will give consistantly spaced code even areas of relatively low curvature. HTH

Einhorn is Finkle, Finkle is Einhorn! Einhorn is a man! Seriously though, any recommendations on getting a good surface finish? I've never cut this personally so I'm not sure what to expect when doing surface machining with a ball end mill. thank you,

While "not needed" is absolutely correct you may find yourself in situations where a containment boundary worked in the past and doesn't in X7. On some occasions you may need to modify the boundary, but in many situations simply setting the containment boundary to "Outside" will do the trick. HTH.

I think the real issue is your shop sabre cannot apply cutter comp on a 3d move like your toolpath is currently outputing. edit your lead in/lead out to not use a ramp height and see if that helps.

surface rough pocket will also support undercuts. This is nice for roughing purposes so your finish tool engages a consistent amount of stock as it finishes. You can also use it to finish, just "uncheck" roughing. Now you can do "Finish Passes" that support lead in/lead out, cutter comp, a plunge point, etc... HTH

Nice! Good to hear, been busy here too...

I like to create one "feature" and then use the "Manual Pattern" function. Doesn't really matter as long as you get what you need but the manual pattern function works quite nicely. Hey Pete, how you doing?

my biggest issue is with small tools less than 1mm. But for the most part I can verify things that would lock up the X6 verify and leave me spending a lot of time saving stl files or creating stock models where I really didn't want them. I seem to get the best balance between speed and accuracy by not having the performance slider all the way up but instead use the accurate zoom function. For small tools I still use verify to help me visualize what's happening, but to get the accuracy I am looking for I just use a stock model. It can certainly take a while but that's ok as it is crunching in the background. Even the compare function works pretty well, although it does add significant calculation time. Has anyone having issues tried a stock model to get a higher resolution? What did you think of the results? How long did it take to calculate vs. verify?

I don't know of anyone who pushes the FBM Mill button and posts out code, but instead will let it create toolpaths, some of which will be modified and used to output code others will simply be deleted. But it can create some geometry/toolpaths very quickly that would take a lot of time to create manually. The biggest thing is to use it enough, and be familiar with it enough to recognize when it can be useful. FBM Drill is quite useful.

I'll throw my two cents in, feedrate optimization is still a very useful tool and should be a tool that is used. For roughing, even on older/slower machines, I believe in most cases using the dynamic toolpaths is probably a much better aproach. Not just for reducing machining time but also for cutter life. Slowing down a tool as it engages full width or goes into a sharp corner is certainly a good thing. A better thing is to never engage full diameter or never have the sharp corner. Feedrate optimization also has a place for semi finishing and finishing toolpaths, many machines can achieve a good finish at quite fast feedrates in open/free flowing areas but as you get into tight areas with a lot of direction changes going slower is neccesary. So you can either slow the entire toolpath down or use feedrate optimization to slow it down only where it needs it. None of the feedrate optimize tools I've looked at will give the same results as if you simply program a part to do exactly what you want by splitting up toolpaths, editing tolpaths, etc... And they take some work to get results that you like but typically once you figure them out you can acceptable results pretty consistantly. HTH

Curve 5 axis, radial offset to 1/2 the radius, comp to surfaces, and use negative stock to leave. you still get lead in/lead out. you still get overlap on closed contours. you still get multiple passes so you can a rough and a finish on multiple chains in one toolpath. depending on what you are looking for you typically don't need to create any surface fillets/chamfers just use existing wireframe. HTH

we used to be able to do this, sort of, before version X. Back when we had the "import operations" selection from the RMB inside the toopath parameters (where you would select a tool). You could export a bunch of ops. create a toolpath, select your geometry, right click and hit import operations, all the toolpaths would be imported associated to the geometry you selected. do a mass regen and you were done. while you had to jump through a few hoops it worked well, and it took less than 60 seconds to edit the geometry for as many toolpaths as you wanted. This is a function that was more commonly used for applying a set of toolpaths to multiple locations, a simple example would be spot drill, tap drill, and tap. Where you could select all the points, then pick your set of operations, and you were done. I miss this...

While I too want this changed when you create a new level this is an awsome tool as it is. I use template files, and if you encorporate levels and viewsheets into your template file the on/off preference you may have isn't an issue and you can have blocks of levels predefined for multiple viewsheets. As you can see by the poll 20% to 25% want new levels "ON" for all viewsheets, it's not a majority but it's significant. I would like it "OFF" by default, but a switch would allow everyone to set it the way they want. As far as levels set functionality, you can set viewsheets so that it only controls levels. I would like to be able to access my viewsheets from a toolbar dropdown or RMB. I would also like to be able to "tab" through the viewsheets.

While the X7 verify, or simulator, does have a learning curve I don't think I've heard of anyone saying the X6 verify was "faster". While it does need a little work my biggest complaint is having to hit the 5 axis engine button a lot because it won't "stick". Whatever you are seeing for issues send them in to get looked at.

If you like you can certainly use the "simply" function to convert a spline that should have been an arc into an arc. But there's no need to use "break many pieces" to break a spline into multiple arcs/lines. Just set the toolpath to use the arc filter with a 2:1 ratio with an overall tolerance of .0002". This will typically give accurate results, with "mostly" arcs. There are certain situations where another process may be required but for most situations this works well.

This is a tough question as it all depends on your pc and wether or not your working with solids or surfaces. There is some general slowness just from working with solids instead of surfaces. Other than that I've been on pc's that handle 500mb files better than another pc with a 20mb file. I would agree in not splitting things up, if your typical files are slow and hard to work with you just need a higher end pc. Stock models add up, you may be better off creating the stock model then saving it as a stl file so you can delete the stock model. Hopefully we'll get a "compressed stock model" in the future to help with this.

Here is an example file that should help. LOLLIPOP CORNER BREAK.MCX-6