https://www.haascnc.com/content/dam/haascnc/en/service/reference/probe/renishaw-inspection-plus-programming-manual---2008.pdf These are probably the most "standard" numbers in use for the Renishaw Probe Cycles. I say that based on the sheer number of Haas machines that have been sold with a Renishaw Probe over the years. This package uses O9810 for protected moves, O9811 for single surface probing, O9812 for web/pocket, and O9814 for Bore/Boss. Keep in mind that the Probe cycles themselves can be re-numbered, for all sorts of reasons. The fact that you've bought some of these machines at auctions, means that you'll need to review what Macro Programs are currently installed on each one. That Renishaw manual from 2008 has all the information needed to get a good understanding of the Probe cycles and Parameters (arguements) which can be passed on the Macro call line. Remember to always include a Decimal Point (.) After each argument/parameter.

Anything filled with glass is going to chew up your way covers pronto, and if the seals fail (and they will sooner, rather than later), it will start wearing your ways and/or ballscrews. Dust collection is better than running coolant, if you have the capability. You don't want to breath the dust. It also really tears up your hands. I prefer to wear nitrile gloves when handling the parts. If you run flood coolant, the glass dust mixes with the coolant, and still keeps tearing up your pumps, hoses, and way-cover seals. My best advice is to drain your coolant tank, and clean it before starting the job. When you fill the tank, push the coolant concentration to the lowest you dare go. I like about 4% for anything with glass in it. The reason is that the whole batch of coolant is shot, once there is glass in it. After the job is done, empty and dispose of the coolant; the entire sump full. Clean the inside the of the machine completely, and then remove all the way-covers, and clean the covers and seals, before re-installing everything. I'd budget a full-shift to clean everything, and remove/re-install the covers. That glass powder will stick to everything, and it will act like a fine-slurry of sandpaper, constantly grinding away at everything. The glass sticks to your rubber seals, and will eat away at whatever it gets stuck between.

I wasn't able to find those old sample posts unfortunately. If you can post up a sample file, with several G76 Thread Ops, that you know are good (hand-edit the "good" NC Code), I'll take a look at your Post. It would help if you could give me both "as posted", and then "hand edited" code, that shows what you are after (and that I can compare back to the original Mastercam Ops), that's what I would need to help you sort this out. For Ops, if you can do 6 Ops, as follows, that would help: OP1 - G76, Straight, with 0 Degree Lead-In OP2 - G76, Straight, with 30 Degree Lead-In OP3 - G76, Positive Taper 2.0-Degrees, 0 Degree Lead-In OP4 - G76, Positive Taper 2.0-Degrees, 30 Degree Lead-In OP5 - G76, Negative Taper -2.0 Degrees, 0 Degree Lead-In OP6 - G76, Negative Taper -2.0 Degrees, 30 Degree Lead-In

No need to rename the variable. The first place it was located was 'pwrttparams'. <- This is the Tool Table Parameters. So these variables are available, only during the Tool Table output. You can just copy it straight over to 'pparameter$' without causing any issues. Yes, if you add the 2nd Argument to the 'Mprint' Statement, you get to pick from one of 5 different Message Boxes. There are (I think) up to 7 different Numeric Responses (0-6), which get returned, based on the "type" of Message Box you initiate. (Ok/Cancel, Yes/No/Cancel, Cancel/Abort, Yes/No, Etc.)

The warning part is pretty easy: #Initialize some String Variables, near the top of the Post: str_warn1 : "" str_warn2 : "" str_warn3 : "" str_warn4 : "" str_warn_out : "" str_warn_typ : "" #Lookup String from String Select Table #Next, include some logic in your Post Block, to trap and build the error message. if comp_type = 1 | comp_type = 3, [ #comp_type[1] = Control, comp_type[3] = Reverse Wear str_warn_typ = slout(comp_type, scomp) #Get String, from String List str_warn1 = "Error detected in Operation Number: " str_warn2 = no2str(comp_type) str_warn3 = ". Fix the Operation, and Repost!" str_warn4 = "Press Cancel to quit Posting Process." str_warn_out = str_warn1 + str_warn2 + str_warn3 + no2asc(13) + "COMP TYPE: " + str_warn_typ + no2asc(13) + str_warn4 if mprint(str_warn_out, 2) = 2, exitpost$ ] if comp_type = 0 | comp_type = 2, [ #comp_type[0] = Computer, comp_type[2] = Wear #This is what we want, so we don't do anything. #We technically, don't even need this Post Block here ] if comp_type = 4, [ #comp_type[4] = Off str_warn_typ = slout(comp_type, scomp) #Get String, from String List str_warn1 = "Error detected in Operation Number: " str_warn2 = no2str(comp_type) str_warn3 = ". Fix the Operation, and Repost!" str_warn4 = "Press Cancel to quit Posting Process." str_warn_out = str_warn1 + str_warn2 + str_warn3 + no2asc(13) + "COMP TYPE: " + str_warn_typ + no2asc(13) + str_warn4 if mprint(str_warn_out, 2) = 2, exitpost$ ]

Sure. This isn't available as a NCI Variable. But not to worry; it is available as an Operation Parameter: 15346. In fact, the option to capture this data is already in MPMaster. What Post did you start with, and what Version of Mastercam are you using? Because I added the [*comp_type, e$] code to a stock 'MPMaster 2021' Post, and got this: % O0000 (T) (MCX FILE - C:\USERS\CGILCHRIST\DOCUMENTS\MY MASTERCAM 2021\MASTERCAM\PARTS\TEST.MCAM) (PROGRAM - T.NC) (DATE - NOV-20-2020) (TIME - 3:20 PM) (T239 - 1/2 FLAT ENDMILL - H239 - D239 - D0.5000") N5 G00 G17 G20 G40 G80 G90 N10 G91 G28 Z0. N15 (COMP IN COMPUTER) N20 (COMPENSATION TYPE - COMPUTER) comp_type 0. N25 T239 M06 ( 1/2 FLAT ENDMILL) N30 (MAX - Z.25) N35 (MIN - Z0.) N40 G00 G17 G90 G54 X-.8543 Y2.7894 S1069 M03 N45 G43 H239 Z.25 N50 Z.2 N55 G94 G01 Z0. F6.42 N60 Y2.2894 N65 G03 X-.3543 Y1.7894 I.5 J0. N70 G01 X2.1654 N75 G02 X2.4154 Y1.5394 I0. J-.25 N80 G01 Y-1.7283 N85 G02 X2.1654 Y-1.9783 I-.25 J0. N90 G01 X-2.874 N95 G02 X-3.124 Y-1.7283 I0. J.25 N100 G01 Y1.5394 N105 G02 X-2.874 Y1.7894 I.25 J0. N110 G01 X-.3543 N115 G03 X.1457 Y2.2894 I0. J.5 N120 G01 Y2.7894 N125 Z.2 N130 G00 Z.25 N135 (COMP IN CONTROL) comp_type 1. N140 X-.8543 Y2.5394 N145 Z.2 N150 G01 Z0. N155 G41 D239 Y2.0394 N160 G03 X-.3543 Y1.5394 I.5 J0. N165 G01 X2.1654 N170 Y-1.7283 N175 X-2.874 N180 Y1.5394 N185 X-.3543 N190 G03 X.1457 Y2.0394 I0. J.5 N195 G01 G40 Y2.5394 N200 Z.2 N205 G00 Z.25 N210 (WEAR COMP) comp_type 2. N215 X-.8543 Y2.7894 N220 Z.2 N225 G01 Z0. N230 G41 D239 Y2.2894 N235 G03 X-.3543 Y1.7894 I.5 J0. N240 G01 X2.1654 N245 G02 X2.4154 Y1.5394 I0. J-.25 N250 G01 Y-1.7283 N255 G02 X2.1654 Y-1.9783 I-.25 J0. N260 G01 X-2.874 N265 G02 X-3.124 Y-1.7283 I0. J.25 N270 G01 Y1.5394 N275 G02 X-2.874 Y1.7894 I.25 J0. N280 G01 X-.3543 N285 G03 X.1457 Y2.2894 I0. J.5 N290 G01 G40 Y2.7894 N295 Z.2 N300 G00 Z.25 N305 (REVERSE WEAR) comp_type 3. N310 X-.8543 N315 Z.2 N320 G01 Z0. N325 G42 D239 Y2.2894 N330 G03 X-.3543 Y1.7894 I.5 J0. N335 G01 X2.1654 N340 G02 X2.4154 Y1.5394 I0. J-.25 N345 G01 Y-1.7283 N350 G02 X2.1654 Y-1.9783 I-.25 J0. N355 G01 X-2.874 N360 G02 X-3.124 Y-1.7283 I0. J.25 N365 G01 Y1.5394 N370 G02 X-2.874 Y1.7894 I.25 J0. N375 G01 X-.3543 N380 G03 X.1457 Y2.2894 I0. J.5 N385 G01 G40 Y2.7894 N390 Z.2 N395 G00 Z.25 N400 (COMP OFF) comp_type 4. N405 X-.8543 Y2.5394 N410 Z.2 N415 G01 Z0. N420 Y2.0394 N425 G03 X-.3543 Y1.5394 I.5 J0. N430 G01 X2.1654 N435 Y-1.7283 N440 X-2.874 N445 Y1.5394 N450 X-.3543 N455 G03 X.1457 Y2.0394 I0. J.5 N460 G01 Y2.5394 N465 Z.2 N470 G00 Z.25 N475 M05 N480 G91 G28 Z0. N485 G28 Y0. N490 G90 N495 M30 %

Hi Pete, There is a Mori App's guy that is a member here. I think his name is Mark? I also think he changed his screen name here within the last few years. Hopefully he will chime in. The issue with all of the new 5-Axis Functions (TWP, TCPC, DWO, WSEC, etc.), is that there are several dozen parameters which are interlinked.

Lol, yeah, I used to hate them. BTW, since you're looking at Buffers... I posted the videos from one of my old classes on Buffer Files, to my YouTube Channel. So if you need a refresher on how they work, there are 8 videos from that class available.

Hi John, I noticed you removed the condition 't$ > 0' from your call to 'ptooltable'. This causes MP to process 'every single Tool Change event'. Which is likely not what you're after. The reason: Depth Cuts and Multi-Passes are output as a 'Null Tool Change' event. This means you'll get an entry in the Tool Table for each pass and/or depth cut. MP has a mechanism built in, which automatically switches the sign of 't$', as the 'pwrtt$' loop is running. For each 'new instance' of a Tool Number, 't$' is signed positive. For every other occurance (Op change, or depth-cut/multi-pass), the tool number is signed negative. I have not had the opportunity to play around with the functions much, but the "Enhanced Tool Table" functions will likely get you what your after. The problem? <- We've been trained to do it the "old way", using 'pwrtt$' and 'pwrttparams$' for a long time. Plus, there isn't much 'sample code' where they are exclusively using the new Enhanced Tool Table functions, to use as a template. Also, the methods themselves, are mutually exclusive. You've got to "convert the whole mechanism over to Enhanced TT", and can't mix-and-match. I'd probably have an easier time doing this with a Buffer File, and just building my own TT output in 'psof$', rather than converting everything over to use Enhanced TT. I've seen a few requests for this lately. Maybe I should put together a new YouTube video to show how I'd handle this...

The issue with 'z_min$' depth, is that it isn't calculated until the end of the loop. (Basically, 'z_min$' is only calculated once the 'path' has been read. That is why you're getting the 'z_min$' value for the "last path", on each tool entry in the table. My suggestion: capture the 'z_min$' values (and z_max$, if needed), into a Buffer File during the Pre-Read Event. (pwrtt$) and then write logic into 'psof$' to read the buffer, filter the data, and match up the Z values, with the Tool Data you're trying to capture.

Mathematically, a 'Singularity' occurs when the Tool Axis becomes "parallel" to one of the rotary axes. This means the centerline of the Rotary, is aligned with the centerline of the Tool Axis. In these states, "any angle" of that aligned axis, will satisfy the mathematically condition of "is my Tool Axis aligned with my Tool Vector"? On a A/C or B/C machine, when the machine is at Rotary Zero (Primary/Secondary both at zero), the C-Axis is naturally in a Singularity state. When resolving rotary angles, the job of the Post Processor is to figure out "how do I rotate the Tool Vector in the NCI File, so that it is parallel with my Spindle (Tool) Axis". When using the "Top" Toolplane with a A/C or B/C machine, "C0." is the default state for output, but it could be "any C-Axis Angle", that satisfies this condition. For a long time, there was no logic in the Generic Fanuc 5-Axis Post, to resolve "other angles" in the Top View. This was because only the "Z-Axis" of the Tool Plane Vector was evaluated, for positioning on the "Top Plane". Starting with the OEM Haas UMC-750 Post, Jeff added some logic to the Post, that detected a "Top/Top" condition, and if it existed, it would check to see if there was a rotation between the WCS and the Tool Plane's X Axes. If they were not aligned, the Post would use ATAN2 to calculate the Primary angle. I don't have a "recent" copy of the Generic Fanuc 5X Mill Post, so I'm not sure if that additional logic was ever incorporated into it. Plus, that logic is in the binned section, so I'd have no way of looking at it, unless had the opportunity to view a copy of the PSM file. I don't foresee being able to take a peek under the hood, anytime soon...

What Toolpath inside Mastercam are you using??? <<- That Makes a difference. MI10$ is for "Toolplane-Based Paths". MI9$ is for "Vector-Based Paths". Perhaps you are programming a 5-Axis Path, and using the wrong integer for control?

The ability to add multiple, separate groups of geometry, each with an independent stock offset, was a significant improvement for all of the surface paths. I've been able to create some amazing toolpaths with this feature, and was able to avoid having to create additional control geometry. I'm very happy they were able to add this.

Sure, no worries. When you program in Mastercam, you create a series of Toolpath Operations. You've probably figured that much out already, based on the fact that you are hand-editing the NC Code output. When you create a new Operation, there are two potential "Operation Interfaces" that you'll see, depending on what type of Toolpaths you use. If you mainly do 2D work, most of the 2D Operations have been re-worked in the Mastercam interface, to use a "Tree Style" Format. On the left side of the Dialog Box, you'll see a Tree, where you select different "branches" or nodes. When you choose a new branch, it changes the display of the 'page' that is shown to you. Each page in the Op Tree contains different settings. One of these pages, is called "Misc. Values". This page is a special page. It is special, because it allows a "two-way flow" of information between the Post Processor, and Mastercam Ops. If you look at the picture, you'll see I selected the Misc. Values page, and the settings are "grayed out". There is a checkbox that you must disable, if you want to use custom settings. Otherwise, you'll just be using the "Post Default Values". The "Strings" which are displayed in this page, come from the Post Processor Text Settings. This gives the Post Developer, the ability to describe "what that control is going to be used for, inside the Post Processor". These settings give you 10 Integer Numbers, and 10 Decimal (Real) Numbers, which act as "Input" to the Post Processor. What can you do with them? >>> Anything!!! They exist in the program architecture as a way for the Post Developer to be able to "control events", based on the number that is being passed for each Operation. This gives the user the ability to set different values, whenever they want a change to occur in the Posted code. None of the Misc. Values are "setup by default", unless they were previously created for the "Base Post" which your Post Processor was created from. Since you are using a Postability Post Processor, they have completely customized this section, to give you the ability to interact with the Post, and pass instructions to trigger different behavior, by manipulating the NC Code output. Technically, there are 3 different mechanisms within Mastercam that allow the Post Developer and User to interact with the Operation Interfaces: Misc. Values - Passes numbers to the Post at the Op Level, to trigger routines in the Post. Drill Cycles - The "Cycle Text" and "Variable Descriptions" are editable, for each individual Drill Cycle. (20 different cycles available!) This allows you to completely customize the Drilling Cycle output, and/or create a "Custom" Drill Cycle. (For example, so you can add "Probing" support to a Post.) Canned Text - A special mechanism within Operations, that allow you to trigger events. And, since the release of Mastercam X, allow you to customize and control Coolant Output. Canned Text is "special", because you can use it "within the motion of a Toolpath", by using the "Change at Point" function in the Chaining Dialog. You can choose Canned Text output options (before, with, after) at the Operation Level (by default), but you can also do some really slick stuff with this function, since you can trigger events within a Toolpath itself. Misc. Values and Drill Cycles are only output at the "Tool Change" event.

To add to this: Dave sets up his Post Processors to allow you "control" over the events that take place. You control the output of the Post Processor, by setting integer values for the Miscellaneous Integers and/or Real Numbers (decimal), for every Toolpath. You can have Postability change the output for these options, to get exactly the code you want. But you'll still need to remember to open each of the Toolpaths, and adjust the settings, so that each approach/retract is handled the way you want it to be handled. You will often have a choice of "0" = Option A, "1" = Option B, "2" = Option C. In addition, there is typically another control that you can set for something like this: "1" = Only at real Toolchange, "2" = At Actual and Null Toolchange, Etc. The idea is to give the Programmer control, so that you can adjust the "input" settings in Mastercam, and based on the changes you made, you get different output generated from the Post Processor.