Just giving credit where it is due my friend! Glad to work with you and happy to recommend your services. Speaking of, I may have a project bubbling up for 5-Axis with a Heidenhain Control. The interest from the customer is big, but they aren't sure where the budget is going to come from yet. I'll loop you in if anything comes from it.

Ron's company supports projects with Phillips Federal for Mill-Turn Applications and Training for our government customers including NASA. Hiring him is money very well spent. Many contractors can program a part. The ones who can do what Ron does are few and far between. Ron delivers end-to-end solutions including training, programming, testing/prove-out of posts and machine simulation (providing proper feedback to developers and crafting custom solutions for machine control), tooling and processing recommendations, and creates paradigm shifts in capability for the companies and programmers he trains.

I also got great results with Power Surface in 2023. I did have to create Surfaces from those adjacent solid faces (didn't work well when using the solid/edges), and I had to clean up the wireframe for the "boundary" around the surface edges of the hole. Once I did that, it worked pretty great.

I program every "ID" path with Reference Points for Approach and Retract, in Z. To make sure the tool completely retracts from the bore. Note: you can "just use Z" (don't check X, for example), and let Mastercam use the "diameter" of the path, or you can opt to use "only X". You can also choose between absolute coordinates (forcing a specific X or Z location), or using "incremental", which means "distance is offset from the geometry or initial point of the toolpath" (not G91 output).

These patch surfaces I created in Mastercam. fill holes_patch-surfs_surf-intersections.X_T You can see where I took the "flat tilted floor surface", untrimmed the surface, and expanded it in all directions, then untrimmed the runner cylindrical geometry, and extended it until it fully intersected the flat floor face. I then created a curve at the intersection of those surfaces. (I made the curve thicker.)

I cheated. I did this outside of Mastercam. I fooled around in NX for a few minutes trying to use the synchronous modeling to delete the faces. Each time, to get anything that will allow me to remove the cylinder (hole), it basically defeatures the part until there is nothing to rough. The problem "modeling wise", is the cutouts were made after the holes were already poked through the model. You have the 'runner' geometry (convex cylindrical surfaces), intersection with some "planar tilted pockets", and then there are just a bunch of radius features, thrown on to blend everything together. I gave up trying to just modify the solid. I used 'extract geometry' in NX to create composite curves, and created surface patches.

Try merging these patch surfaces in? fill holes_patch-surfs.x_t

Global Formulas to the rescue! tlngno$ = t$ tloffno$ = t$ Add these formulas, near the top of the Post, starting in the First Column, and you'll never have a H/D number that doesn't match the Tool Number.

Try the Fit Transitions checkbox option as well...

For "Direction", try setting the Plunge Angle to "0.0". (It will accept both positive and negative values! Try them both. Try a 5 degree ramp, and a -5 degree ramp, to see how it affects the entry/exit motion.) Not all angles are created equal. It can be hard to tell "approach angle" and "exit angle" sometimes. What I do is use a 1" entry distance, and a 2" exit distance, so I can then see "visually" based on the toolpath orientation, if I need to use a direction angle of 0-deg, 90-deg, 180-deg, or 270-deg, to get the "direction approach" I'm after. Once I figure out the Plunge Angle, and Direction Angle settings, for both entry and exit, I will then adjust the actual distance to a reasonable value. I'd also recommend changing your cut pattern to "zig-zag", and your Gap Method to "Smooth". Combining "Smooth" with "Tangent Line Extension" should give you an amazing cut pattern. With one-way, if you insist on using it, you are better off making your "gap size just about double your step-over amount", and using the Tangent Line extension option. That would have you "cut through" each slice, beyond the surface, and then due to the gap distance (end of the last cut, to the start of the next cut) being greater than your Gap Size, the tool would then retract up to your Retract Plane, reposition to the start of the next cut slice, and cut through again.

Also, you can use "Direction" button to give you "surface lead in/out" motion, to get the tool in/out of the cut. For undercutting operations, you want to disable all of the "gouge checking" options.

Nice thinking outside the box Ron! I know there is a joke in here somewhere about fitting an oblong peg into a round hole...

I have written several dozen of them over the years. Most of the ones I've developed were "mechanical kinematics", where the machine does not use Dynamic Codes. The Dynamic Codes allow you to adjust the machine to track the Rotary and Tilt axes, zero points, and offsets. For a "purely mechanical" 5-Axis Post, I can set one up in about 20 minutes, and they usually require 1-2 days of back-and-forth testing, or less. But the problem is: these posts rely heavily on being able to take precise measurements at the machine. And you must move your geometry in Mastercam, relative to the "center of rotation" on the actual machine. In other words, you must completely configure your virtual world, to match your physical world. That means you must actually measure at the machine, any time your physical geometry is not oriented perfectly at the machine, and you must repost your NC Program for any changes at the machine. Or, alternatively, you must take the time to "dial in your part perfectly" at the machine, and any error in the setup is translated into errors on the part as you move and rotate the tool and/or part in 5-Axis. I've written several 5-Axis Posts that support Dynamic Codes, and to do this right can take days or weeks of effort, depending on exactly what support is required. Dynamic Work Offset, Tool Center Point Control, and Tilted Work Plane, are the "heavy lifting". Now, couple all the Dynamic Code support, with adding Inverse Kinematics (for driving Machine Simulation from Post Processor output), and you are talking a ton of development time, unless you've already developed a "framework" (like In-House Solutions has done with their IKE Posts), for supporting all these codes. Now, throw all of that development and architecture away, and start over with MP.NET, from the ground up...

Sorry, I just have to revisit this statement again. This is basically the guy admitting that many Resellers don't have the Post Development and Debugging skills, in-house, with developers employed by the Reseller. Any competent Mastercam Post Developer, should be able to fix anyone's code, unless they have truly gone "off the rails", but I've only ever seen a couple of instances of that happening. It is true that if you completely hack up all the logic, and "break" the architecture through bad coding (or refusing to listen to good advice and reason), that even a competent Post developer would say no. But that is really much more the exception, rather than the rule. (And sounds to me like a sales scare tactic. "These things are really complicated, and you might break it, so better to just let our dealership change your oil for $120 bucks, rather than you doing it yourself. If you put the wrong oil in, your car might blow up! ) I've got 42 videos on MP Post Development, which are part of my MP 101 Basic Post Processing class. All those videos are available for free, and I promise if you watch them, you will at least learn enough to know "where your skills are at, and what you should attempt to code yourself, versus leaving to the professionals". I'll let you all in on a little secret. I don't develop 5-Axis Posts for customers. Not because I'm not capable, but because of the amount of focused work required. I basically draw the line at 4X Mill and Lathe Posts, and anything more complex I'll use In-House Solutions. If a customer is already using Postability, then that is fine too. In the interest of full disclosure, one of the reasons I love In-House so much is because of their willingness to help machine tool distributors (like Phillips) with Post Support. We can request a Post for just about any machine and configuration, and get a working copy for my Applications Engineers very quickly. Often, in the same day as the request is made. We also get direct support from them when we go onsite for training, in case we discover any Post issues while onsite. Could I build those 5-Axis Posts? Absolutely, given a clear statement of work, and enough time. But my job involves so many things now of which "Post Development" is just a small piece, I'd rather leave the heavy lifting to the professionals. Plus, I have to support and engage with multiple CAM software platforms, including my new favorite. (Can't name it on here, since that is against the rules, which I respect. Hint: it is two letters, and can do a whole lot more than "just CAM").

No need to contact your Reseller when updating, provided the Post internally is not "Version locked". To "lock a Post to a specific Mastercam version", requires writing logic to test your Mastercam License. Most Reseller Posts are not locked by version (some are, really depends), and so you can simply do as you've always done, and update them all using the Migration Wizard. For the Migration Wizard to work properly, each Control Definition File needs to have the "Control Definition Default Settings" correctly configured. If you are buying your Posts, then this should have been done for you "out of the box". You should be good to continue using the same update process you've been using.

Updating Posts should take a few minutes, using the Migration Wizard, unless the Posts are 3rd Party (like Postability), which are locked to a specific Mastercam Version, and require an update from the developer. I would bet you need to set your "Control Definition Defaults". This would simplify the updating process for any Posts that you've built or maintain, which are not version locked. (If there is no "PSB", the Post is open.)

Thank you all for the kind words. MP.NET has been in development for a while, all focused on the Mastercam Mill-Turn product. I know the plan is to eventually transition all products over to use MP.NET, but I've been hearing that since 2011, when I was working in the Post Department at CNC Software. Now, CNC Software has purchased Postability, so hopefully they will be able to put additional resources towards MP.NET development. The elephant in the room with MP.NET is that you must have a Developer License to modify the Posts. Say goodbye to your ability to make your own changes, or develop your own Posts. I will be curious to see what happens long term with Mastercam Posts. I can't see the MP Language going away for at least another decade. Some issues with this transition: There is no mechanism to convert MP Posts into MP.NET Posts. The languages and processing are completely different. Someone will need to foot the bill for this conversion. That will likely fall on the customer's shoulders. No more "user-development" of Posts without a license. Will they issue licenses to customers for their own development? Who knows. No more "independent 3rd Party Post Developers" who aren't licensed by CNC Software as a MP.NET Developer. Learning MP Posts is still a valuable skill, and will serve you well for likely the next decade. You know those meme pictures where there is a skeleton, with a phrase like "Still waiting for the original poster to respond"? We need one that says "Still waiting for MP.NET to replace MP...". I do find it telling that your instructor was following the party line of "if you're on maintenance you can have your reseller edit the posts for you, and that if you run into some major problems that need fixing on your customized posts that they will not touch it" I won't directly contradict that statement on a Mastercam forum, because I don't want to stir up trouble. But I think both of those statements are designed to get you to spend money, rather than learning a skill. I prefer to teach men to fish, rather than requiring them to buy fish from me in perpetuity.

I'm with Ron on this. You must add logic in several places to support Rigid Tapping with M29. You must "suppress" the Spindle Speed and Spindle On M-Code, from the Tool Change and Start-of-File blocks. With MPMaster or IKE Posts, you simply change a variable "Switch" in the Post to enable Rigid Tapping, and the output will change just by changing that one switch.

X <<<<< and Z. NOT Y >>>> and Z. One thing that is important to understand > The "Default Lathe" Machine Definitions often have "every possible axis" included on the machine. Think of them as a "Virtual Axis". This allows you to "program toolpaths that can't really be achieved on a machine". This means you can have a Mastercam File, with "bad toolpath definitions" (Planes are not set correctly). This can prevent you from "replacing" a perfectly good Machine Definition, in the file you're replacing it in, because the MD doesn't match the configuration of the "existing machine definition inside the file". In your case, this is not happening. Your machine has a Y-Axis and a Z-Axis, but no X-Axis. Close the Axis Combinations window, add a Lathe X-Axis Component as a child, in the kinematic tree. Go into the Axis Combinations Dialog Box, and make sure X-Axis is selected, in your Axis Combination. You can leave XYZ selected (all three), without hurting anything. These are not "linked to the Post", by default.

You are Missing an X-Axis Component. And, depending on the toolpaths being used in the original file > Possibly missing a C-Axis as well. (For any Live Tool work). Open the Lathe Default Machine Definition, and look at the Axis Combinations, and what components they contain. Yours contains only "Z, Y".

You need to fix the LMD-5, so the Axis Combination inside the Machine Definition, has a valid set of axes, that "match the WCS/Plane/Product" information contained in the file you are trying to "Swap out".

You mentioned you "figured it out", but your Feed Plane, was set too low. So the tool was moving downwards, at Rapid, until the last little bit. Free Mastercam Training Materials: https://www.inhousesolutions.com/resource/mastercam-2023-training-links/?fbclid=IwAR37BKhkMZ2SFG6_3x2l54fH-hdj9hCVQti4mQtgs0mPhoYu_uPEH1h_SYc

Hi Terry, I make a copy of the solid, on a new level, and typically in a new color. I run "Remove History" on this 2nd "Manufacturing Model". I then use the "Modify Feature", set to "Remove Feature" to remove the "hole" going through those solid faces. (Note: check the back-side, and first remove any counter-bore, or chamfer features, before removing the "through hole".) Note2: You can "double click" on that cylinder, to have Mastercam "attempt to recognize and identify the whole feature".

You are doing a combination of "Micro" and "Macro" Programming. Which one do you really want? I suspect what you're after is "Macro Programming", not "Micro Programming". In your sample, you're only cutting 241 millionths of an inch of stroke in X and 68 millionths of an inch in Y. Is that what you want? Or were you just giving us an example? Is your machine's least-increment-input set to 1 millionth of an inch? Is your Geometry in Mastercam defined (with system tolerance properly set) to 0.1 millionth of an inch (7 decimal places. 0.0000001)? Or where you just showing the "structure" of what you want the code to look like? The example is a little confusing. Could this be coded inside the Mastercam Post, so you can take a toolpath "input" and turn it into this "output"? The answer is yes. But you're going to need to do a bunch of coding, there is nothing in the Post to do this "out of the box". You may be better off just coding this "by hand" as a Manual Entry Toolpath. Unless you do this day-in, day-out with Macros, and it is important to you and/or the operator to be able to change the variables at the machine.

Someone liked my response above, and I realize there was a bit of a mistake in what I said. The Z-Axis Vector of the Back Plane sets the C-Axis Zero Position. You must rotate this plane, with a "locked X-Axis orientation", about the X-Axis of that plane/WCS. The Back Plane, and the Top WCS, have the X-Axis Positive Orientation "opposed". The point opposite of each other. Any "Lathe T/C Plane" you create, must have the "positive X-Axis direction", pointing away from the X+ orientation of the Top WCS. This setup, is by-far, one of the more confusing "rules" in Mastercam, and is really only dictated by the setup of the MP Lathe Post Processors, and how they were designed to read "Plane Matrix Data", and some of the processing rules and checks for 4-Axis.