Look at the PDF for MP Post Ref Guide - Legacy Chapters > Rotary Processing This chapter covers: Rotary processing types Variables that control rotary processing Processing 4-axis motion Mastercam view matrixes Examples Processing 5-axis motion Matrix mapping Are you already familiar with Linear Algebra concepts, specifically Vector and Matrix mathematics?

There is absolutely nothing wrong with this method of adding a blank line > " ", e$ However, it does add an extra ASCII blank space character to your NC Program. An alternate method of forcing the empty line, is to omit the string literal, and just "force" the end-of-line command (*e$) if prog_stop = 1, pbld, n$, *sm01, e$ if prog_stop = 2, pbld, n$, *sm00, e$ <<============ after *e$ #<======== That will force a blank line, with no space character.

Hi Paul, Not sure why you'd be getting the different angular output between Probing and Drilling. That would really be a question for Renishaw and/or your Mastercam Post Developer. Is this a question of being "off" by 90-degrees, or 180-degrees for the C-Axis Rotation? If it isn't an easy answer like "90-or-180 degrees out", then I think it would warrant some investigation for Renishaw and the Post Developer. Have you looked in the RenMF File? (Renishaw Machine File = Renishaw Post). I know there are some unit vectors defined in that file, were the values are either "0", "1", or "-1", to defined rotary axis directions. Perhaps the unit vectors aren't setup correctly, which could be giving you a 90 or 180 degree shift in the C-Axis output. Are you using the "Miscellaneous Values" (Integers and Decimal Numbers), at the operation level, to control the rotary output? Could this be giving you a different output for the C-Axis when drilling? As a Test, can you program the Drilling Operation as a separate Operation, then take the Probing output you're testing, and edit the C-Axis value to match the Drilling Cycle output? If you hand-edit the code for testing purposes, does the Probing cycle now work as expected? All of the actual rotary axis angle output should be generated by the Mastercam Post Processor, not the

Is your Post encrypted? Does it have both a PST portion, and a separate PSB portion? If the pwrtt$ with the dollar sign ($) being added, is giving you "duplicate Post Block errors", then you've likely got no access to 'pwrtt$'. Did you attempt searching for 'pwrtt$' in the Post, before adding a new section? It may be located in a different spot from where you are used to seeing it, unless it has been encrypted in the PSB seciton. If the section has been encrypted, you'll have to go back to whomever supplied you with the Post, to see if they can expose that section of code, or if they can give you a user-defined Post Block Call, that would be called from inside the encrypted 'pwrtt$' section, and thereby give you access to capture the parameter values, before writing them to the Buffer File.

I had the same attitude which got me into Post Processor Development in the first place. I wanted my code to come out "edit-free", and eventually through learning about the MP Language, I was able to attain that and never looked back. Start with MPLMaster. Both MPMaster (Mill), and MPLMaster (Lathe) are excellent "base" Posts. They make take more initial "tweaking" versus the 2X Hitachi, but the 2X Post will not support 4-Axis output, including Y-Axis. The 4X Posts are much more involved and robust from a "plane handling standpoint". Both the Generic Fanuc 4X MT_Lathe Post and MPLMaster, are great starting posts, but MPLMaster is like a "beefed-up" version of Gen Fan 4X MT_Lathe.

I've setup the Generic Fanuc 4X MT_Lathe Post, and/or MPLMaster, to fit a variety of custom machine and control configurations. M-Codes for machine mode activation, Axial and Radial Live Tool Canned Cycles, Pick-Off/Cut-Off to support all of the Part Handling code between Main and Sub Spindles, Part Flip, or Tailstock operation. Mori Seiki's, Hwacheons, Haas, Okuma, Mazak, Etc. I doubt there is anyone with a personal copy of a Post they have customized for this particular machine/control combination, who has: #1, seen this thread, and #2, is willing to share their work, but I wouldn't be surprised if either Postability, or In-House Solutions, has a post "off the shelf", which would support the basic options of your control. When I was working at CNC Software back in 2013, In-House Solutions was celebrating their "100,000th Paid Post Processor", so considering we're about 10-years on, I'd guess you could probably double that number. (*NOTE: I do not speak for, nor represent, CNC Software, In-House Solutions, or Phillips Corporation in making these comments, for which I'm solely responsible for here.) If you're interested in taking a stab at it yourself, check out my YouTube Channel in my signature. I've uploaded my Basic Mill Post Class (MP 101), 5X Post Class (MP 301), and the start of my Lathe Post Class (MP 201). This reminds me that I should finish uploading those videos...

By the way, check out the link in my signature. I've got an entire Basic Post Processing Class which was recorded back in 2016, which I've uploaded to YouTube. Be sure to watch the "Office Hours" video sessions, where we are doing the bulk of the "hands on" post development work.

Both of these lines: (TOOL - 1 OFFSET - 1) (RGH TURN .03R INSERT - CNMG-432) Are output by the call to: ptoolcomment ltlchg$ #Toolchange, lathe toolchng = one gcode$ = zero copy_x = vequ(x$) pcc_capture #Capture LCC ends, stop output RLCC c_rcc_setup$ #Setup LCC on first 60000 plcc_lead_begin #Save original in sav_xa and shift copy_x for LCC comp. pcom_moveb #Get machine position, set inc. from c1_xh c_mmlt$ #Position multi-tool sub, sets inc. current if G54... ptoolcomment <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Both lines, are output from this subroutine (post block) call comment$ Inside 'ptoolcomment' > the output comes from the following Original Block: ptoolcomment #Comment for tool if tool_info = 1, [ tnote = abs(t$) toffnote = tloffno$ strtool$ = ucase(strtool$) stinsert2 = ucase(stinsert2) !spaces$ spaces$ = zero scomm_fx_arg = drs_str(2, tnote) + drs_str(2, toffnote) pcomment_out if posttype$ = two, #Lathe toolpath operation [ if tool_op$ = 64, [scomm_fx_arg = strtool$, pcomment_out] #Drill operation else, [scomm_fx_arg = strtool$ + " " + stinsert + stinsert2, pcomment_out] ] else, [scomm_fx_arg = strtool$, pcomment_out] #Mill toolpath operation spaces$ = prv_spaces$ ] Block, with Comments added for clarity: ptoolcomment #Comment for tool if tool_info = 1, [ tnote = abs(t$) toffnote = tloffno$ strtool$ = ucase(strtool$) stinsert2 = ucase(stinsert2) !spaces$ spaces$ = zero # ************ The two lines below, output the TOOL - 1 and OFFSET - 1 > scomm_fx_arg = drs_str(2, tnote) + drs_str(2, toffnote) pcomment_out # ************ This code block, either outputs "lathe drill" comment, or "lathe insert" comments if posttype$ = two, #Lathe toolpath operation [ if tool_op$ = 64, [scomm_fx_arg = strtool$, pcomment_out] #Drill operation else, [scomm_fx_arg = strtool$ + " " + stinsert + stinsert2, pcomment_out] ] # ************* This "else" block, outputs "Mill Tool Comments" else, [scomm_fx_arg = strtool$, pcomment_out] #Mill toolpath operation spaces$ = prv_spaces$ ] I didn't see originally that this was a Lathe Post. For Lathes (with milling capability), the 'psof$', 'tlchg$', and 'tlchg0$' blocks are expanded, to include separate "milling" and "turning" toolchange blocks: lsof$ > Lathe start-of-file (1st toolchange) ltlchg$ > Lathe actual tool change ltlchg0$ > Lathe Null Tool change (tool number repeats) msof$ > Mill start-of-file (1st toolchange) mtlchg$ > Mill actual tool change mtlchg0$ > Mill Null Tool change (tool number repeats)

That should be where you want to add it. Basically > psof$ = "the 1st tool change operation" in the Post ptlchg$ = "the next 'actual' tool change operation ptlchg0$ = "null tool change, tool number repeats"

I'd really need some more specifics of what you are trying to measure. Just the "diameter" of the counterbore (0.57186 hole), or are you trying to gauge "rotation" of the features in that pocket? I do not see a single "straight wall" in that pocket, just a series of tangent arcs, and the two "ramped surfaces" at the X- and X+ ends. Are you trying to determine the "size" of those features, or the angular rotation of the pocket as a whole? To determine "size", I'd suggest running a "3-point Bore" (O9823) Macro, on each of the 4 Lobes, at the pocket corners. You must perform "Vector Calibration", to have success measuring bores "not at the quadrant positions". An example, would be the lobe in the X+ Y+ quadrant. You could use A30., B60., and C90., to make 3 hits on that radius. (See Variable Outputs - Chart 2 > #188 = "feature size", in this case "diameter".) You could then save that output (#621 = #188), after executing the cycle, and then repeat the process, on the other 3 lobes, using #622 = #188, #623 = #188, and #624 = #188), where you are placing that equation just after each cycle being executed, to capture the results, for each probing cycle. NOTE: be sure you are cancelling "Block Lookahead", otherwise you won't get correct results. To cancel "lookahead", place > "G103 P1", just ahead of the equation. The G65 P9833 call should turn "lookahead back on". It doesn't hurt to place a "G103" on a line afterwards, just to be sure it is enabled. The code below only shows execution of a single cycle. You'd need to repeat this in at the 3 other lobes, and save #188 results to a unique variable. Then, afterwards, you can compare the results, and make a judgement on "do you need to adjust Cutter Radius Compensation values to make the feature "on size". G65 P9832 G65 P9810 X25. Y40. (GO TO CENTER OF 3-POINT BORE) G65P9810Z-10.F3000 (PROTECTED FEED TO DEPTH) G65P9823A30.B60.C90.D50. G103 P1 #621 = #188 G65P9810Z100. G65P9833 G103 G28Z100. english---renishaw-inspection-plus---programming-manual---2008.pdf

The probe is driven from the spindle centerline, so there is no direct "callout" for the probe diameter. At least, not on the G65 Pxxxx Macro Call Line. Calibration on a Haas should be done through VPS, where you'll have a series of Templates to execute, and here is where you would enter the nominal Probe Stylus Diameter. Do not run "Complete Probe Calibration Macro". Instead, execute Calibration Macros 2, 3, and 4 (Tool Probe Calibration, Spindle Probe Length, and Spindle Probe Diameter), in order. You'll get more accurate results if you run all three sequentially, instead of running "complete probe calibration". On the Spindle Probe Diameter Calibration Macro Page (VPS), this is where you'll enter the Probe Tip Diameter, along with other calibration inputs. The "diameter" actually doesn't get stored. The Calibration Macros will calculate the Probe Radius, and store that value. The "variable ranges" are typically in the #500-#590 range of values. Should be #520-#527, or something like that, for where the actual calibration numbers are stored.

Yes, your best bet is "Backplot & Verify Only".

You're welcome Josh. There is a ton of stuff that is possible with Prod+, but it requires education in how the product works. That education is best sourced from Renishaw, as Prod+ is a product produced by them, and integrated into Mastercam as an add-in. While CNC Software is familiar with how the system works, and is responsible for the integration into the Mastercam Interface, Renishaw are the ones who build the product and are the experts in Probing. Getting some training from Renishaw will pay huge dividends.

What Post are you starting with? The variables for "comment start" and "comment end", are typically: sopen_prn & sclose_prn or scomm_str & scomm_end Example, change from this: sopen_prn : "(" #String for open parenthesis "(" sclose_prn : ")" #String for close parenthesis ")" To this: sopen_prn : '(MSG" ' #String for open parenthesis "(" sclose_prn : ')"' #String for close parenthesis ")" Example, change from this: scomm_str : "(" scomm_end : ")" To this: scomm_str : '(MSG" ' scomm_end : ')"'

The advantage is simply the "existing mechanism" which exists inside MP-based Post Processors. There are 3 Canned Text Post Block Calls: pcan, pcan1, and pcan2. pcan = Canned Text "Before" (the tool change) > will output a line of code with standard architecture. This includes the call to 'pbld' to output Block Delete (if active), Sequence Number (n$ > only if active), the "canned text" (loaded in 'pcant_out'), and the End of Line (e$). pcan2 = Canned Text "After" (the tool change) > will output on a separate line, like 'pcan' does. pcan1 = Canned Text "With". This must be used in 2-parts. First, the "call" to 'pcan1' (generally at the start of the output line), and then the Post Developer includes 'strcantext' as an output parameter, generally at the end of the line of code. Because of the existing architecture, it allows the Post Developer to 'simply move the call to 'pcan', 'pcan1/strcantext', or 'pcan2', and the output location becomes very easy for you to "move around", to get exactly where you want it to occur. There is nothing inherently wrong with the way you may be utilizing Canned Text, but when you modify the 'pcant_out', you are simply changing how 'strcantext' gets loaded with output strings. Technically, you can even leverage Canned Text to "set variable values", or otherwise pass data to the Post, so you "as the developer", can do whatever you want with it. The biggest advantage to Canned Text, is the ability to trigger events "during the Toolpath itself". We typically do that with "chain-based" (Contour) paths, using the Chain Manager, Right-Clicking on a Chain, and using the "Change at Point" command. Here, you can either use Canned Text, Manual Entry, or just trigger changes like Rapid/Feed switching, Jumping Z-Height (super awesome for hopping over clamps), adding a Dwell Command, or modifying Feed or RPM values. The tricky part with modifying RPM/Feed or Feed/Rapid, is the changes are Modal. So, you generally need to make multiple changes at different points in the path, to get the output you desire. But it allows customizing "the motion" to a very high degree, with minimal Programmer inputs needed.

Yes, it is certainly possible to add functionality from one Post, to another. You do need to know the architecture of the Post, as you generally can't just "copy and paste" Post Block Sections, because you need to know if there are variables which are shared across the original post and new "code sections" you're adding. Also, variables must be initialized and/or formatted, so there are often additional sections which must be copied, to support either Post Blocks, or sections of code being added to existing blocks.

You should include the "top surfaces of the screw" in the Machining Geometry Selection. To control the depth of the 1st cut, you should be using the "Stock" page of the Rotary Advanced Toolpath, using a Stock Model, to represent the "current stock condition" of the part you are machining.

What you want to setup is some logic that reads the value of "t$", and then outputs a different "block" of spaces, based on the knowledge of "how many digits is the numeric variable". This would be for "numeric variables only". For Strings, you can use the "String Length" function, to get the number of characters in the string, and then "append" (concatenate) additional space characters, to create output that maintains your "column spacing". Unfortunately, there is no way to control "starting column", as lines of G-Code are assembled, and "things added" to the string line (strings or numeric variables, with their associated prefix strings), one-at-a-time, until the line is forced out with the end-of-line variable (e$). ptspc #Post Block to pad Tool Variable Space Characters if t$ < 10, " " if t$ > 9 & t$ < 100, " " if t$ > 99, " "

Custom Macro is literally "I want to customize a Macro Program to do something unique from a Probing requirement standpoint". For example, you want to measure 20 points around the ID of a bore, and take the average of all of those points, to determine not just diameter, but cylindricity. Or, you want to measure and compare the true position of multiple features, relative to a bore, etc. There is a lot you "could do" by building your own Custom Macro Probing Routine, and Renishaw will come train you on how to unlock this potential, but they aren't just giving away documentation which would allow other Probing Manufacturers to copy their designs. Plus, they need to be sure that your probing knowledge is up to a certain level, and explain how the architecture of the whole system works. When you generate a Custom Macro Program, it will never "call an existing Macro that is already loaded into your control". That is by design. For a Custom Macro Program, you are essentially telling the system "what macro program number to call on the G65 line", and the system will then output that new Macro Program below the M30, after your NC Program has been output. There is nothing to backplot, unless you've created a "path" for the Macro Program to execute. That involves picking positions and entering probing data into the interface. It is certainly possible to create a Macro Program which does nothing but output a "call" or enters "Macro B Logic Statements" into your NC Code, for calculation purposes only. For these programs, there wouldn't be anything to output for Backplot, as no "probe motion" is actually being generated in these scenarios. I would highly recommend having Renishaw come in to help you customize the RenMF File (Renishaw Post), and give you the rundown on how the system works. Are you just trying to call existing Macros on your control, or do you truly need the capability of generating "a custom Probing routine, where the measurement cannot be calculated by using a combination of the existing macro programs". There is also a difference between "writing and calling a Macro Program", and writing/adding Macro B Logic Lines, following a standard macro call. For example, you could write a macro call for a Bore, G65 P9814 xxxxx Then, add lines of Macro B Logic to capture the output variable value: #590=#185 #591=#186 Then, perform some other Probing Cycle G65 Pxxxx xxxxxx Save, the result; #592=#185 #593=#186 And finally, do some macro logic/math with those saved values So while you're using the Prod+ interface to create Macro Calls, you can also do things like "Add a Sequence Number Block between Mastercam Operations". This can be use with a "IF/GOTO" statement to go jump backwards in your program. For example, you can zero out your wear offset (or add to the existing value to leave extra material), and then cut a feature, probe it, calculate the difference between nominal and actual, and then adjust your wear offset, and then jump back to the starting sequence block, to re-cut the feature. There are all kinds of cool things you can do with Prod+, but you really need someone who knows the Prod+ system well, and you're better off getting Renishaw involved, than your Mastercam Reseller. Most Resellers are not experts in driving Prod+, and they know the basics. But to get all the power out of the system, I'd suggest getting Renishaw to train you how the whole system works.

Ron is correct. Your feature is not at TOP, and the values you have entered into the XYZ fields represent the endpoints of the Z-Axis Vector which describes the orientation of the feature, relative to the WCS Plane. Those values (.40825,.40825,.8165) represent the endpoint of a unitized vector (Inch or MM, the 3D vector length is always "1 unit of length", so either 1" or 1 mm). If you want to learn more about how Posts work, you should register and link your Hasp/License on the Mastercam website, and download a copy of the MP Post Documentation (listed under 3rd Party Developers section). To help put that document in context, I've uploaded several of my Post Processor Editing classes to YouTube. See the link in my signature. You'll want to start by watching all 42 videos of my MP 101 class, to understand the Post Language, NCI Data, and Posting Process, and then watch the MP 301 videos, which demonstrate how to configure the Generic Fanuc 5X Mill Post. Contact your Reseller to get a copy of that Generic Post Processor, and you can edit it to suit your needs.

The biggest problem with all of these software platforms is the sheer number of various tools, options, extensions, holders, screws, nuts, bolts, collets, seals, and other options/accessories. Any "neutral vendor" like Machining Cloud must be able to import/input all of the data from each of these tool manufacturers. That is a daunting list of items, let alone all of the data behind the scenes that is required to support all the products.

Try searching also for "Autodesk Powermill". Delcam got bought years ago, so you'll likely find many more sources for tutorials if you don't put "delcam" in your search bar...

Did you ask your Mastercam Reseller for help?

Go into the Control Definition, and edit the "Canned Text Strings" in the bottom (Post Text) section. Go to the "11th" item in the list, and type a string explaining what "the function does", like "Call Tool Breakage Macro". This will "enable" the 11th option in the list. Now, edit your Post Processor (make a backup first!!!), in a text editor. Here is the original section of the Post (search for it): pcant_out #Canned text - build the string for output #Assign string select type outputs if cant_pos < three, #cant_pos indicates canned text output [ if cantext$ = three, bld = one if cantext$ = four, bld = zero #Build the cantext string if cantext$ = one, strcantext = strcantext + sm00 if cantext$ = two, strcantext = strcantext + sm01 if cantext$ > four, [ strtextno = no2str(cantext$) strcantext = strcantext + strm + strtextno ] ] Make edits as follows: pcant_out #Canned text - build the string for output #Assign string select type outputs if cant_pos < three, #cant_pos indicates canned text output [ if cantext$ = three, bld = one if cantext$ = four, bld = zero #Build the cantext string if cantext$ = one, strcantext = strcantext + sm00 if cantext$ = two, strcantext = strcantext + sm01 if cantext$ > four & cantext$ <> 11, [ strtextno = no2str(cantext$) strcantext = strcantext + strm + strtextno ] if cantext$ = 11, strcantext = "M98 P8888" ]

Disable GPU processing Select to disable the use of the computer GPU during simulation. The GPU can greatly improve simulation performance, especially when simulating large toolpaths. However, older computers may not support GPU processing and this can result in slowdowns. There is an option on the Simulation Topic page of the System Configuration dialog box, which allows you to disable GPU processing for Simulation. You won't see your graphics card pegging while calculating toolpaths, but you may see it spike when running Verify or Simulation, if this checkbox is not checked. This is only available in 2023, so they are making some progress in using the Graphics Card GPU for certain calculations.