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.

In the example, the geometry of the toolpath is being "manually" created. If this is on a surface, use Surface Finish Project, or Surface High Speed Project. Use "Curves" as input. This is purely 3-Axis.

You're welcome. I'm glad that worked. The thing I hope you can see if you examine the Mastercam File I attached > you can use Mastercam to "reverse engineer the G-Code", by plotting the XY points. For the Arcs, on a Haas machine, the IJK values are "relative to the start-point of the arc". This can be easily done by taking the XY position (before the current G02/G03 line), and using Transform to copy that point to the IJK location. Then use "Arc - Polar" to construct the Arc in Mastercam. What I did was to manually draw out the path, so I could visualize the cutter path. When I started building the 2nd path, I could measure that it was offset by 0.015, but by constructing the physical geometry, I was able to deduce that while "x-or-y values have been shifted", that was done by just editing the NC code. The older Leadwell machine was able to ignore the arc errors (likely has a higher tolerance set in the control parameters). So even if the old machinist created all those old programs by hand, you have a very capable tool in the form of Mastercam combined with your mind. I'm a bit surprised that nobody has downloaded the Mastercam File, or the NC Code file. Perhaps people didn't realize there were downloads attached, because they were in the middle of my reply?

I also have a Classic Haas Control Hardware Simulator, running Version 18 Software (Maincon board configuration). Our Federal Phone Support Haas Guru has multiple sets of hardware boards, from the old Motorola processors, through the cold-fire series, up to the last CHC versions. He can swap out components to configure the Haas to diagnose most CHC issues over the phone for our Federal Customers.

Hopefully, if you look at my Mastercam File, you can see how I constructed the geometry, and was able to make some assumptions about how the path was originally constructed, so I could fix the issues. There were IJ Center point errors, yes, but also the XY positioning "start points", and even the "entry/exit" lines (point before the Arc Start Point or after the final endpoint (G40) needed to be adjusted, to maintain parallelism and proper tangency. One thing that makes this very difficult, are the changes needed in not only the I-J values (describing the Arc Center, relative to the START POINT), but also the shifting of the "start/end" XY coordinates, due to offsetting an arc that is a "partial arc", where the entry line is not tangent to the arc start point. In this case, you've got to offset, and retrim at the intersections.

Here is how I fixed this. I went into Mastercam, and I plotted all of the points for both passes. I do this so I can draw lines and arcs, and "try to get an idea of what you're doing". There were some issues in how the 0.015" offset Finish Pass was created, that for some reason worked on the Leadwell, but fails on the Haas in Grapics. So, once I figured out that this pass was deeper, and was offset 0.015", I was able to construct geometry, and do things like "trim to the correct intersection points". No warranty for this code is expressed, or implied, so USE AT YOUR OWN RISK!!!! But, that said, I was able to get this modified code to successfully run in Graphics mode on my Haas NGC Simulator. I included my Mastercam File, to show you how I laid out the points. the Green geometry (in general) is the 2nd pass, and the blue geometry is the first pass I plotted. % O04445 G00 G90 G40 G80 N76 M01 (T3- 3/8 EM./D21, FIXED 2ND PASS) T3 M06 N77 G0 G90 X7.301 Y-.315 S2700 M3 N78 G43 H3 Z.1 M8 N79 G1 Z-.271 F42. N80 X4.4995 N81 Y-.5062 N82 Y0. N83 X3.9013 Y.2715 S2800 M3 N84 G1 Z-.475 F42. N85 G41 D3 X3.8388 Y.1633 N86 G3 X3.8305 Y.132 I.0541 J-.0313 N87 G1 Y.0852 N88 G3 X3.8564 Y.073 I.026 J.0215 N89 G1 X4.0941 N90 X7.1063 N91 G2 X7.2495 Y.0137 I0. J-.2025 N92 G1 X7.3045 Y-.0414 N93 G2 X7.3638 Y-.1846 I-.1432 J-.1432 N94 G1 Y-.4454 N95 G2 X7.3045 Y-.5885 I-.2025 J0. N96 G1 X7.2495 Y-.6436 N97 G2 X7.1063 Y-.7029 I-.1432 J.1432 N98 G1 X4.0941 N99 X3.8721 N100 G3 X3.8391 Y-.7298 I0. J-.0337 N101 G1 Y-.8013 N102 G3 X3.8471 Y-.8313 I.06 J0 N103 G40 G1 X3.9071 Y-.9352 N104 G0 Z.1 N105 X3.8876 Y.2777 N106 G1 Z-.488 F42. N107 G41 D3 X3.8258 Y.1708 N108 G3 X3.8155 Y.132 I.0671 J-.0388 N109 G1 Y.0803 N110 G3 X3.8564 Y.058 I.041 J.0264 N111 G1 X4.0941 N112 X7.1063 N113 G2 X7.2389 Y.0031 I0. J-.1875 N114 G1 X7.2939 Y-.052 N115 G2 X7.3488 Y-.1846 I-.1326 J-.1326 N116 G1 Y-.4454 N117 G2 X7.2939 Y-.5779 I-.1875 J0. N118 G1 X7.2389 Y-.633 N119 G2 X7.1063 Y-.6879 I-.1326 J.1326 N120 G1 X4.0941 N121 X3.8721 N122 G3 X3.8241 Y-.7284 I0. J-.0487 N123 G1 Y-.8013 N124 G3 X3.8341 Y-.8388 I.075 J0. N125 G40 G1 X3.8941 Y-.9427 N126 G0 Z.1 N127 X3.9226 Y.1288 N128 G1 Z-.27 F32. N129 G41 D3 X4.0308 Y.0663 N130 G3 X4.0621 Y.0579 I.0313 J.0541 N131 G2 Y-.6879 I0 J-.3729 N132 G3 X4.0321 Y-.6959 I0 J-.06 N133 G1 G40 X3.9292 Y-.7559 N134 G0 Z1. M9 N135 G91 G28 Z0 M5 M30 % test nc code arc issue.mcam O4445.nc

Try this: Take the original program, and run it "as-is". But, before you run the code, go to your Tool Diameter Offset (for T21, this would be "D21"), and set it to "0.0". Does it work with "No Diameter Offset" present? IF YES, then you've likely got a program which is setup to run "Wear Compensation", not "full diameter compensation".

Also, I'd be remiss if I didn't mention, the free Mastercam Training, from In-House Solutions (who host this website that we all chat on):

Also, kudos to you for jumping in and trying to solve the problem. You're making a great effort, and I applaud you for it. But that said, it sounds like you need some basic CNC Training. Fortunately, you've come to the right place on the internet to get help for both Mastercam and Haas machines. (I happen to work for the Haas HFO for the Federal Govt.) https://www.haascnc.com/myhaas/Haas_Learning_Resources.html Download a copy of the Mill Operator's Manual - Programming Guide: https://www.haascnc.com/content/dam/haascnc/en/service/manual/operator/english---mill-ngc---operator's-manual---2020.pdf Also, a copy of the Mill - Programming Workbook, is very handy: https://www.haascnc.com/content/dam/haascnc/en/service/reference/programming-workbooks/mill---programming-workbook.pdf And, if you get stuck on the answers, there is an Answer Book: https://www.haascnc.com/content/dam/haascnc/en/service/reference/programming-workbooks/mill---programming-workbook---answers-book.pdf And finally, here is a link to sign up for the online "Haas Operator Certification" course, if you're interested... https://learn.haascnc.com/

I have to ask... If you are using Mastercam Code Expert, do you not have access to the Mastercam Program, so you can just "program the path" using the software, and then output the NC Code using the Post Processor function? Mastercam makes outputting the code, super easy, so you don't have to figure this out on your own. I noticed you are also using Cutter Compensation. Is it possible that you are programming using "Wear" compensation in the Toolpath, but then performing Tool Probing on the machine, and you're measuring "the diameter"? With Mastercam, you can control the Lead In Lines, and the Lead In Arcs (size and "sweep angle") to configure the Lead In/Out to your personal preferences. But once you learn how to output proper entry/exit in Mastercam, you would never have to hand-edit the G-code...

#Pre-process rotary motion control flags pmx0$ #5 axis gcode setup if drillcur$ = zero, [ if fr$ = -2, gcode$ = zero else, gcode$ = one ] I rinsed the code through Notepad, so the color formatting is removed. This may help with readability.

This checks to see if a Drill Cycle is not-active. (drillcur$ = 1, means active, when drillcur$ = zero, means not-active). When we are "not drilling", this block then converts the current value of 'gcode$' (11, for a 5-Axis path), to either Zero (rapid) or One (feed), based on the 'internal flag variable 'fr$'. The value is signed '-2' when we are in rapid mode, otherwise '-1' means "unchanged" (same feed value repeats). For "regular feed output", 'fr$' will be a positive decimal value, that contains the actual Feedrate unit, in either inches per minute, or millimeters per minute.

On the error line, it tells you the "value of the string selector variable", which is "11". This is because the 5-Axis Toolpaths produce "NCI G-code 11 - Vector Moves". Something in the Post is not resetting the 'gcode$' to '0' (for rapid motion) or '1' (for feed motion). Your post is probably missing the following "pre-process" block: #Pre-process rotary motion control flags pmx0$ #5 axis gcode setup if drillcur$ = zero, [ if fr$ = -2, gcode$ = zero else, gcode$ = one ]