Initialize a numeric variable, load it with the value from mi7$ in pmiscint$ and check that variable in pretract instead of mi7$. The problem you are seeing is that pretarct is called by ptlchg1002$ which means the mi7$ value is the value from the next operation when there is a tool change. Alternately, you could update the previous value of mi7$ (using !mi7$) in pmiscint$ or at the end of psof$, ptlchg$ and ptlchg0$ and then check prv_mi7$ in pretract.

On Fanuc or Pseudo-Fanuc controllers, set your clearance value to something above the part (i.e .1 absolute if your part is at Z0). Your retract height should be set to .1 above the last drilled depth in subsequent ops or same as Clearance in first op (i.e. if your first op drilled to -1.4 your second op would be set to -1.4). Top of stock is set to the drill depth of the previous op ( in this example 0 for first op) and depth is set to whatever you can reach with the tool in the given operation. This will result in G98'2 being output on subsequent ops. The tool will rapid to that point, then rapid to the retract height (which will be in the part for subsequent ops) then will feed to depth and will rapid back out. Peck Drill ops (i.e G83) will peck and retract all the way out between pecks before rapiding back down into the hole, chip-brak ops (i.e G73 will only retract to the level set in retract height before rapiding back down). i.e. % O0001(DRILL EXAMPLE) G20 G0 G17 G40 G49 G80 G90 T1 M6 G0 G90 G54 X0. Y0. S2000 M3 G43 H1 Z.1 G99 G81 Z-1.5 R.1 F4. G80 M5 G91 G28 Z0. M01 T2 M6 G0 G90 G54 X0. Y0. S2000 M3 G43 H2 Z.1 G98 G81 Z-3. R-1.4 F4. G80 M5 G91 G28 Z0. M01 T3 M6 G0 G90 G54 X0. Y0. S2000 M3 G43 H3 Z.1 G98 G81 Z-5. R-2.9 F4. G80 M5 G91 G28 Z0. G28 X0. Y0. M30 %

You may be able to simply switch the output to an external file and then merge it at the end (that is if subout$ 3 is not already used in your post). Something like this should work ptooltable #Tooltable output extprg$ = 1 #Enable ext file and clear contents !subout$, subout$ = 3 #Save current subout setting and switch to ext sopen_prn, *t$, sdelimiter, pstrtool, sdelimiter, *tlngno$, [if comp_type > 0 & comp_type < 4, sdelimiter, *tloffno$, sdelimiter, *scomp_type, sdelimiter, *tldia$], [if xy_stock <> 0 | z_stock <> 0, sdelimiter, *xy_stock, sdelimiter, *z_stock], sclose_prn, e$ xy_stock = 0 #Reset stock to leave values z_stock = 0 #Reset stock to leave values subout$ = prv_subout$ #Switch output back to saved state and peof$ #End of file for non-zero tool pretract comment$ if stagetool = 1 & stagetltype = 2, pbld, n$, *first_tool$, e$ n$, "M30", e$ mergesub$ clearsub$ mergeaux$ clearaux$ mergeext$ #Merge in the tooltable info clearext$ #Clear the ext file "%", e$

That message occurs when you launch the debugger via it's executable rather than by posting to it from Mastercam. Your best bet is to click OK on that dialog and then go to the Help dropdown and select the User Guide. The guide contains everything you will need to know in order to use the debugger including how to enable it via the control panel applet displayed in the image in the prior posting.

I would recommend creating two axis combinations in the Machine Definition; one that includes a rotary axis and one that does not. This will allow you to select when you desire A output and when you do not in each operation.

Changing the output does not require post edits such as you have implemented. This is what the 'scase' initializations are for (among other things): #Machining position turret/spindle settings # Switch strings based on turret position top/bottom-left/right and cut type. # Turret position is based on the Mastercam settings (see lathtype). # Strings are re-assigned for output in the routine psw_str_mult. # The string variable sw_string holds the place position value to determine # how to assign the strings. Planes are relative to the view from Mastercam. # Assign the 17 digit string following the alpha columns below: # A - C axis, 1 = axis winds, 2 = axis signed, 3 = indexer, 4 = shortest direction # B - Spindle direction, 0 = normal, 1 = reverse # C - Plane 0 arc/comp, 0 = normal, 1 = switch # D - Plane 1 arc/comp, 0 = normal, 1 = switch # E - Plane 2 arc/comp, 0 = normal, 1 = switch # F - Plane 0, 0 = G17, 1 = G19, 2 = G18 # G - Plane 1, 0 = G17, 1 = G19, 2 = G18 # H - Plane 2, 0 = G17, 1 = G19, 2 = G18 # Decimal (required) # I - Plane 0, X axis, 0 = normal, 1 = switch sign from basic # J - Plane 0, Y axis, 0 = normal, 1 = switch sign from basic # K - Plane 0, Z axis, 0 = normal, 1 = switch sign from basic # L - Plane 1, X axis, 0 = normal, 1 = switch sign from basic # M - Plane 1, Y axis, 0 = normal, 1 = switch sign from basic # N - Plane 1, Z axis, 0 = normal, 1 = switch sign from basic # O - Plane 2, X axis, 0 = normal, 1 = switch sign from basic # P - Plane 2, Y axis, 0 = normal, 1 = switch sign from basic # Q - Plane 2, Z axis, 0 = normal, 1 = switch sign from basic use_only_tl : 1 #Use only Top turret/Left spindle settings (below) for #all Mastercam turret/spindle selections #When configuring for multi-spindle/turret set to 0 #Columns- ABCDEFGH.IJKLMNOPQ #Turret/Spindle #Path Type scase_tl_c1 : "10000222.000000000" #Top turret/Left spindle, Turning cut scase_tl_c2 : "11000012.000000000" #Top turret/Left spindle, Right Face cut scase_tl_c_2 : "11110012.000000000" #Top turret/Left spindle, Left Face cut scase_tl_c3 : "10010102.000000000" #Top turret/Left spindle, Cross cut scase_tl_c4c : "10000111.000000000" #Top turret/Left spindle, Y axis subs. Cycle scase_tl_c4 : "10000222.000000000" #Top turret/Left spindle, Y axis subs. scase_tl_c5 : "10000222.000000000" #Top turret/Left spindle, Multisurf Rotary #Columns- ABCDEFGH.IJKLMNOPQ scase_bl_c1 : "10000222.000000000" #Bottom turret/Left spindle, Turning cut scase_bl_c2 : "11000012.000000000" #Bottom turret/Left spindle, Right Face cut scase_bl_c_2 : "11110012.000000000" #Bottom turret/Left spindle, Left Face cut scase_bl_c3 : "10010102.000000000" #Bottom turret/Left spindle, Cross cut scase_bl_c4c : "10000111.000000000" #Bottom turret/Left spindle, Y axis subs. Cycle scase_bl_c4 : "10000222.000000000" #Bottom turret/Left spindle, Y axis subs. scase_bl_c5 : "10000222.000000000" #Bottom turret/Left spindle, Multisurf Rotary #Columns- ABCDEFGH.IJKLMNOPQ scase_tr_c1 : "10000222.000000000" #Top turret/Right spindle, Turning cut scase_tr_c2 : "11000012.000000000" #Top turret/Right spindle, Right Face cut scase_tr_c_2 : "11110012.000000000" #Top turret/Right spindle, Left Face cut scase_tr_c3 : "10010102.000000000" #Top turret/Right spindle, Cross cut scase_tr_c4c : "10000111.000000000" #Top turret/Right spindle, Y axis subs. Cycle scase_tr_c4 : "10000222.000000000" #Top turret/Right spindle, Y axis subs. scase_tr_c5 : "10000222.000000000" #Top turret/Right spindle, Multisurf Rotary #Columns- ABCDEFGH.IJKLMNOPQ scase_br_c1 : "10000222.000000000" #Bottom turret/Right spindle, Turning cut scase_br_c2 : "11000012.000000000" #Bottom turret/Right spindle, Right Face cut scase_br_c_2 : "11110012.000000000" #Bottom turret/Right spindle, Right Face cut scase_br_c3 : "10010102.000000000" #Bottom turret/Right spindle, Cross cut scase_br_c4c : "10000111.000000000" #Bottom turret/Right spindle, Y axis subs. Cycle scase_br_c4 : "10000222.000000000" #Bottom turret/Right spindle, Y axis subs. scase_br_c5 : "10000222.000000000" #Bottom turret/Right spindle, Multisurf Rotary Change the first value in the string (column "A") as needed to determine C output. If 'use_only_tl' is set to 1 as above, just change the bolded values here: #Columns- ABCDEFGH.IJKLMNOPQ #Turret/Spindle #Path Type scase_tl_c1 : "10000222.000000000" #Top turret/Left spindle, Turning cut scase_tl_c2 : "11000012.000000000" #Top turret/Left spindle, Right Face cut scase_tl_c_2 : "11110012.000000000" #Top turret/Left spindle, Left Face cut scase_tl_c3 : "10010102.000000000" #Top turret/Left spindle, Cross cut scase_tl_c4c : "10000111.000000000" #Top turret/Left spindle, Y axis subs. Cycle scase_tl_c4 : "10000222.000000000" #Top turret/Left spindle, Y axis subs. scase_tl_c5 : "10000222.000000000" #Top turret/Left spindle, Multisurf Rotary using these settings to match the desired output: # A - C axis, 1 = axis winds, 2 = axis signed, 3 = indexer, 4 = shortest direction

The 20601 lines will not tell you which axis combination is currently used. I would suggest using the syncaxis$ variable for this purpose. Each axis combination has a unique ID which is placed in the 950 line in the NCI file. This line is read by MP while processing and the value is automagically placed in syncaxis$. You should be able to look at the NCI file, determine the two unique values and base your output logic on them.

Cycle times need to be calculated based upon the distance traveled and the speed at which those distances are traveled. Mill.set linearizes arcs and forces long hand dill cycle output to break the motion into rapid and linear motion which can in turn be calculated for time estimates. It is not possible to do this while you are actively post processing a file for output. The best I could suggest would be to use a the ppost$ postblock to reprocess the NCI file using some kind of stripped down .set file and then to merge the results in to the NC file previously generated by the pst file (not for the faint at heart).

The Generic Fanuc 5X Mill.pst already contains clamping logic that is enabled when the use_clamp swtich is enabled. The logic was reworked 2 years ago to better handle clamping/unclamping for drilling and 4/5-axis style output. I would recommend taking a look at a post released since then and encorporating the changes if you are currently using an older post. I'd suggest sending in examples if you have specific cases where you wish to modify the clamping behavior beyond the default output. We should be able to tailor things by using cuttype, opcode$ or tool_op$ if need be.

Old wire posts generally require more work than simply running them through update post to get them to process correctly in X or beyond due to changes in MP processing over the years. I would highly recommend contacting your local reseller for help updating the post, he can always forward it on to us if needed or may have a more modern solution already available. It is unlikely that tinkering with CD settings is magically going to fix the issues I see in your sample code. This line alone: "O1 N100 G90 G95 N100 G92 X0. Y0. N100 G00 X0. Y0." tells me that you are missing e$'s on some post lines and that the rpd_typ_v7$ and tlchng_aft$ variables likely need to be modified which in turn require changes to logic using cstart$ and cend$ flags. The modifications required will take time and some bit of expertise to achieve.

rparsngl is a function used to convert string data to numerical values. It cannot be used to parse a string and return only a portion of a string as you are attempting to do here. What exactly do you need the axis combination name for? If you are looking for the name of the current axis combination used in an operation you will need to read the machine definition parameters rather than reading the 20601 lines (if the MD contains multiple axis combos you will have multiple 20601's). If you can give me an idea of what it is you are trying to achieve I should be able to give you the code you need.

Sorry folks, we're still finalizing dates for this training class. We're going to lock this thread and will create a new posting when everything is finalized.

http://mastercam.com/Support/Training/Default.aspx

The next Basic Post Training class in Tolland, CT will be in June. Currently it is scheduled for June 14-16 but the date may move a bit so it has not been posted yet. Our plan is to offer three classes per year here (Feb., June and Oct.) but the actual dates often vary due to scheduling conflicts (other classes, trade shows, reseller conference, etc...). We are also working on a plan to offer classes in other areas of the country (like we are doing In Seattle) when possible.

The maximum size for buffer records has changed since V9. In V9 (and earlier) a value of 80 in the 3rd parameter of the fbuf line defined the buffer as a string buffer. In X we added the 5th parameter to define the buffer type and increased the max value of the 3rd parameter to 256. In X4 MU1 we were able to increase the max value to 380. So, I would recommend changing the value to 380. i.e. fbuf 2 0 380 1 1 #Buffer 2

I'm not a local post processor guru but I can tell you that those parameters are not available. Sorry to be the bearer of bad news.

Contact your dealer, the download has been placed on our extranet (where it belongs). They can grab you a copy from there.

Email Josh... For those of you playing along, you will likely wonder what I did for Josh, here is the break down. The first thing Josh needed was to capture the operation number value from parameter data. In order to do so we need a user defined string variable to hold the data: sOpSeqNo : "" #Operation manager displayed operation number For simplicity, we place the new initialization at the top of the post where all of the other string initializations appear. Next we need the logic in pparameter$ to capture the value: pparameter$ #Read operation parameters #rd_params is used to call pparameter postblock and read the parameters of the operation specified in rd_param_op_no #"pparameter", ~prmcode$, ~sparameter$, e$ if prmcode$ = 15240, sOpSeqNo = sparameter$ #This is the operation manager operation number (I removed the additional parameter read he had for clarity here) Next we need to use that data for output. Josh was looking to concatenate strings to build a single string for error output. To do this I created the error strings as "global formulas". Global Formulas get their values at output which means that the sOpSeqNo value will be correct when the error message is used. #These messages are defined as global formulas so they can pick up the value os sOpSeNo as needed stoollengthoffserror = "Operation " + sOpSeqNo + ": TOOL LENGTH OFFSET DOES NOT MATCH TOOL NUMBER" stooldiameteroffserror = "Operation " + sOpSeqNo + ": TOOL DIAMETER OFFSET DOES NOT MATCH TOOL NUMBER" scoolantisoffserror = "Operation " + sOpSeqNo + ": COOLANT IS TURNED OFF" Now the information needs to be output. Josh had three lines of code containing 'mprint' functions to output the error messages based upon certain conditions. These three lines of code appeared in psof$, ptlchg$ and ptlchg0$ (start of file, tool change and null-tool change). Redundant logic like this is better handled by placing it in a user defined postblock, in turn called by the three locations.: ptlchg_errorcheck #Check for common toolchange errors if tloffno$ <> t$, [if mprint(stooldiameteroffserror, 2) = 2, exitpost$] #Diameter if tlngno$ <> t$, [if mprint(stoollengthoffserror, 2) = 2, exitpost$] #Length if coolant$ <> one, result = mprint(scoolantisoffserror, 1) #Coolant You will note that the mprint functions above include two styles. The first: "[if mprint(stooldiameteroffserror, 2) = 2, exitpost$]" displays two buttons, 'Ok' and 'Cancel'. The buttons return a value when pressed with 'Cancel' returning a value of 2. The logic above exits posting when a value of 2 is returned. The second: "result = mprint(scoolantisoffserror, 1)" simply displays an 'Ok' button. It just stops processing until the Ok button is pressed and then continues on. The calls to ptlchg_errorcheck are pretty straightforward with the exception of the call placed in ptlchg0$. ptlchg0$ is called in several conditions when the tool number has not changed. These include two operations sharing the same tool, depth cuts and multi-passes. For Josh's purposes we really only want the error messages to be output here if the operation has changed and we need to check for errors again. If we do not add additional logic, we will get redundant error messages any time an error appears in an operation with depth cuts or multi-passes. So in psof$ and ptlchg$ we just need a line like this: psof$ #Start of file for non-zero tool number pcuttype toolchng = one ptlchg_errorcheck #Check for common toolchange errors Note: For those of you using mpmaster based posts, you can place the above call in ptlchg_com and omit the calls in psof$ and ptlchg$ as they both call that common post block. In ptlchg0$ we need some additional logic like this: ptlchg0$ #Call from NCI null tool change (tool number repeats) pcuttype pcom_moveb pcheckaxis c_mmlt$ #Multiple tool subprogram call comment$ if op_id$ <> prv_op_id$, ptlchg_errorcheck #Check for common toolchange errors when the operation has actually changed op_id$ is the internal operation id number assigned to a given operation. The logic above simply checks to make sure that it has changed. Each numeric variable is automagically assigned a prv_ version when it is initialized. The previous value is updated when the variable is output or when we force the update if the variable is not used for output (as in this case) - this is called 'modality' (and that is as far as I am going in terms of explaining it here... We need to make sure that the previous value of op_id$ is updated at each tool change. This is easily accomplished by placing the following command either at the end of the psof$, ptlchg$ and ptlchg0$ post blocks OR at the bottom of the ptlchg1002$ postblock: !op_id$ #Force update of prv_op_id$ value without outputting the value to the NC file Note: I would suggest doing a search for !op_id$ before adding it, it may already exist in your post. Note #2: If you are interested in editing your own posts, I would highly suggest attending a basic post processor training class like the one offered here at CNC Software (Our training schedule is available here: http://mastercam.com/Support/Training/Default.aspx) or at your local reseller (if available). Two or three days spent attending training can make the difference between pulling the hair out of your head and having the confidence to make post edits easily and quickly.

No worries Josh, I'm sure Min will not mind. Just bustin balls

Check the peck deceleration value in your control definition. My guess is that the value has been changed somehow. The setting only affects long hand pecking (including chip break) drilling cycles.

You do not need them if you are not using them. .set files are used to create setup sheets or tool lists when they are enabled in system config. You can grab them off of your installation disk or I am sure your dealer can email new copies to you if you do decide that you need them.

"Do you mind if I post this email on emastercam?" LOL. Guess it doesn't matter if he minds or not eh? BTW, if you just read the parameter as a string (i.e. if prmcode$ = 15240, sOpSeqNo = sparameter$) rather than converting the string to a numeric value and then formatting it as an integer, you can just output it directly without the need for the no2str function. Would be cleaner if you are not actually using the numeric value for anything else.

Switch this to Tool plane if you want the work offset to increment. I'd suggest reading the help for a clearer explanation of the various settings available.

The original .nc file created in the posting process is automatically closed at the end of the peof$ postblock

ppost is a predefined postblock and must be followed by a $. It can be placed anywhere in your .pst file (although it likely makes sense to place it immediately following peof$) spathnc, snamenc and sextnc are also predefined (variables) that must be followed by a $... If you wish to have the renamed file open in the editor you will also want to add an additional line to the bottom of the ppost$ postblock: snewname # User defined string to hold the new file name sncfilename # User defined string to hold the NC program file name ppost$ # This predefined postblock is called after all files are closed at the end of posting sncfileame = spathnc$ + snamenc$ + sextnc$ # path + name + extension result = remove(snewname) # in case this filename already exists result = rename(sncfilename, snewname) # rename the NC file just created to the name specified in ‘snewname’ result = setncstr(2, sncfilename) # Add to edit list so file will open in editor # 2 indicates add, 3 indicates remove from list Obviously the above code is not going to work as is... You need to define snewname appropriately.