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.

Best way is to use the "pparameter$" post block and add lines of logic to read the values from the 'sparameter$' string. You have to create variables first to "hold" the value you are looking to extract. A Parameter Table can also be used, but it is often better to just grab "individual parameters" in 'pparameter$' instead of building a whole Parameter Table. Also, do you need these values "in the Header" of the file (or in the Tool Table)? Or do you just need them "during normal toolpath operation output"? Because if you want to capture values and output them in the Tool Table, you need to add logic to 'pwrttparams$', not just 'pparameter$'.

Personally, when I first started noticing lagging on Code Expert, was years ago. I found (for me), this was likely tied to Graphics Performance. I use the Nvidia Control Panel to 1.) assign the "default profile" in Global Settings to "Catia V5/Dassault, or Solidworks", and then 2.) use the "Program Settings" to force "CodeExpert.exe" to use that profile. I also think this could have something to do with your Licensing, but Code Expert doesn't require a Hasp or NetHasp to run. You can install Mastercam on any computer, and then run Code Expert or Tool Manager (standalone) without a license.

Where are you filling the buffer with data, before reading? You should be capturing the buffer data in 'pwrtt$' (Tool Table), and then outputting (and sorting if necessary) at the beginning of 'psof$'.

The issue is the 'misc values' get reset when you aren't processing a 'Tool Change'. You can setup a 'flag variable' to track the status of 'mi4$', and delay the output until processing in 'plinout'. G0 G90 X.1035 Y4.8144 < OUTPUT FROM TOOL CHANGE (Either 'psof$' or 'ptlchg$) G43 H99 Z.15 S9000 M3 < OUTPUT FROM TOOL CHANGE (Either 'psof$' or 'ptlchg$) Z.057 < OUTPUT FROM 'prapidout' (G-code 0) G1 Z.047 F50. < OUTPUT FROM 'plinout' (G-code 1) G41 D99 X.0156 Y4.8621 F27. < OUTPUT FROM 'plinout' (G-code 1) Start by initializing a variable, near the top of your Post: mi4_flag : 0 Then, capture if the value is '1' during Tool Change (need to put this in 'psof$' and in 'ptlchg$'): pcan #pbld, *sgcode, *sgabsinc, sg80, e$ #ADDED pbld, sg43, *tlngno$, pfxout, pfyout, pfzout, [if nextdc$ <> 7, *speed, *spindle], e$ # G43 with spindle start if mi4$, mi4_flag = yes$ #Set flag else, mi4_flag = no$ #Reset if necessary Now, add your logic to 'plinout': plinout #Output to NC of linear movement - feed pcan1, pbld, n$, sgfeed, sgplane, `sgcode, sgabsinc, pwcs, pccdia, pxout, pyout, pzout, pcout, [if motst$, feed], strcantext, pscool, e$ #Modify following line to customize output for high-speed toolpath #tool inspection/change points if rpd_typ$ = 7, pbld, n$, "M00", "(TOOL INSPECTION POINT - POST CUSTOMIZATION REQUIRED)", e$ if mi4_flag, [ "G91 Z#612 (BLADE THICKNESS ADJUST)", e$ pbld, "G90", e$ mi4_flag = no$ #Reset Flag, to prevent output on every "linear move" ]

MSMW? Minimum Sustaining Manufacturing Workload https://armypubs.army.mil/epubs/DR_pubs/DR_a/pdf/web/ARN20450_AR_700-90_FINAL.pdf

I do this with Operation Groups, and Sub-Groups, in the Ops Manager. Easy to track rotations/tools, when grouping the Operations. Then I can name my groups to convey information back to me, while programming and/or posting. This sounds fairly trivial to do with a script of some sort, but there would be no way to do this "dynamically". If you changed a tool, from T3, to T8, then you run into a situation where the comment doesn't update. Do you want the script to be able to read if there is an existing "T3" appended, and be able to modify that to the current tool number? Now you are talking a script that requires more coding.

Is this for working "inside Mastercam" and seeing the operations, or do you want this in the NC Code output? Because that, would be easy to add to the Operation comment string output. Or are you trying to "find operations which use a particular tool" in the Mastercam Operation Tree? If yes > use "Operation Selection" from the Right-Click menu. You can opt to "use on all operations", or "only on selected operations". (So, if you select say, an operations group, or multiple, because you only want to search in your "OP1" groups, you can do that.) You can filter by tool number, and when you press "ok", the dialog will close and Mastercam will have those operations "selected".

Maybe a bug with 2D/3D switch, when going into an operation for editing?

Check and test the output. Always, Always, make a couple backup copies of your Post, and save them in different folders to be sure you can always restore to a safe point. The output is coming from a variable called 'toolno'. The asterisk in front (*toolno) means the variable is "forced" to output.

Yes. The value gets assigned "zero" in 'ptoolend$'. The output then occurs in 'pl_retract' or 'pm_retract'. ptoolend$ #Read from buffer 1 for prv_, current and next tool info #end tool here, current and next valid if toolend_flag, [ sav_rev = rev #Axis Sub does not update to rev pcan if n1_gcode <> 1000, [ toolno = t$ * 100 + zero #### < Value get assigned here. if millcc, [ pmillcca #End mill conversion ] sav_gcode = gcode$ gcode$ = zero pcool_off if posttype$ = two, pl_retract else, pm_retract Then, is output here: pl_retract #Retract tool based on next tool gcode, lathe (see ptoolend) cc_pos$ = zero if home_type = one, [ pmap_home #Get home position, xabs ps_inc_calc #Set inc. pbld, n$, psccomp, e$ pcan1, pbld, n$, *sgcode, pfxout, pfyout, pfzout, *toolno, e$ ##### Either here, if home_type is 1 pbld, n$, pnullstop, strcantext, e$ ] else, [ #Retract to reference return pbld, n$, `sgcode, psccomp, e$ if home_type = m_one, pbld, n$, *toolno, e$ #### < This is probably where the output occurs. This line is outputting a Tool Offset Cancel. pcan1, pbld, n$, *sg28ref, "U0.", [if y_axis_mch, "V0."], "W0.", pnullstop, strcantext, e$ cutoff_proc = zero #Reset flag if we are retracted if home_type > m_one, pbld, n$, *toolno, e$ ############ Or output here, if home_type is any another value. ] This would fix it: pl_retract #Retract tool based on next tool gcode, lathe (see ptoolend) cc_pos$ = zero if home_type = one, [ pmap_home #Get home position, xabs ps_inc_calc #Set inc. pbld, n$, psccomp, e$ pcan1, pbld, n$, *sgcode, pfxout, pfyout, pfzout, *toolno, e$ pbld, n$, pnullstop, strcantext, e$ ] else, [ #Retract to reference return pbld, n$, `sgcode, psccomp, e$ #if home_type = m_one, pbld, n$, *toolno, e$ ##### DEBUG < Commented Out toolno output! pcan1, pbld, n$, *sg28ref, "U0.", [if y_axis_mch, "V0."], "W0.", pnullstop, strcantext, e$ cutoff_proc = zero #Reset flag if we are retracted if home_type > m_one, pbld, n$, *toolno, e$ ] You will also need to edit 'pm_retract': pm_retract #Retract tool based on next tool gcode, mill (see ptoolend) if home_type = one, [ pmap_home #Get home position, xabs if frc_cinit, cabs = zero ps_inc_calc #Set inc. pbld, n$, psccomp, e$ pcan1, pbld, n$, *sgcode, pfxout, pfyout, pfzout, protretinc, *toolno, strcantext, e$ pbld, n$, pnullstop, e$ ] else, [ #Retract to reference return pbld, n$, `sgcode, psccomp, e$ #if home_type = m_one, pbld, n$, *toolno, e$ ####### < Removed Tool Offset Cancel pcan1, pbld, n$, *sg28ref, "U0.", [if y_axis_mch, "V0."], "W0.", protretinc, pnullstop, strcantext, e$ if home_type > m_one, pbld, n$, *toolno, e$ ]

MP supports a lot of options. Macros? Sure, depending on what you want to do. "Micro Machining" using small decimal values? Sure, it can support that also. You can support up to 9.9 digits (9 decimals before, and 9 decimals after, the decimal point.) But the Post must be configured so the XYZ, Feed, IJK (circle center) values (etc.) are modified for more precision output. Plus, you must go in the Mastercam Configuration File (for Mastercam itself), and enable the "System Tolerance", and set the tolerance to 0.000000001. You will (typically) get the most precision on the machine using Metric Mode. Doing this allows you to support Nanometer Precision output. Now, the issue you will also (typically) face, is how does Windows store the number as a floating point unit, and how Windows operates on very small numeric values, contributes to issues with Rounding in the output. You can utilize 'round_opt$' to influence "what internal routine does Windows use to retrieve and round numbers".

You will need to elaborate on what you mean by "Micro" programming. I have no idea what you are referring to.