You're getting a Wire post error message from MPMaster doing a Mill pocket? I'd say you got problems there mister...

Email me the post and I'll fix it. Do a zip2go and email it to [email protected] Attn: Paul

Tom, you've got mail.

The faulty error message string is coming from this declaration in the .pst file: svers_limit_msg "This post is designed to function with Mastercam V9 only!" Feel free to edit that if you wish to. The only difference between the X and X2 Generic Fanuc 5X Mill (or Router) posts is the change in the version check (which is located in the .psb), a modification to the string above and an update of the version information in the header section of the post.

You only need to run your X post through the X2 updatepst chook if it is a 5-axis post that has a version check in it (like in this case).

Most likely due to your rpd_typ_v7$ setting. Try setting it to 0.

quote: Also, I am wondering why the fstrsel function in V10 rtequires the numbers at the end. They are not present in V9 posts, nor is it mentioned in the V9 post ref. The first number looks to be number of elements in the array, the second number, null? The new parameters are explained on page 7 of the MastercamX_Post_Parameter_Ref.pdf The .pdf file is located in the documentation folder and a shortcut is added to it in your Start-All Programs-Mastercam X folder. I personally would keep all of the logic needed for a probing cycle in the drilling postblock used for that cycles output.

You guys really need to learn to use the error log to help figure out post issues. The problem here is that contour_type is NOT a pre-defined variable and therefor should not have a $ appended to it. This also means that the variable has to be initialized like any other user-defined variable. It will then have to be "set" in some way somewhere in the post. You're going to have to do some more detective work in the old post to determione exactly how the variable was set and used if you wish to use it in the same fashion. Chuck - A line like: code: if tool_op$ = 74 & contour_type <> 0, n$, "M15 P1", e$ is ok. No need for brackets. I would suggest scrapping the few lines of code that you have and trying the logic Roger put up for you.

Ok, I didn't bother reading the entire thread but I do have the solution to the original posting. Please read THIS as I am way too lazy to retype the entire explanation. It explains exactly what is wrong with your V9 lathe post when you update it.

fmt 3 gcode # Format linear G-code selector for modality only Somehow I doubt your feedrate is coming from "gcode"... You'll need to look at ptap to figure out exactly which variable is being used to output the feedrate value. You can then modify the appropriate fs statement or change the fs used for the variable. The change will need to be made in either the FMT line or the newfs line if one is being used to change the output from that variable for that operation (look for something like: result = newfs(two, feed)). If there is a newfs being used you may simply be able to comment out that line (which is my guess).

code: if drillcyc = 8, #Serial Number Engraving [ "(SERIAL NUMBER ENGRAVING)", e pdrlcommonb pcan1, pbld, n, *sgc9, "P1", pxout, pyout, pfzout, *peck1, *peck2, *feed, "(" while drl_prm1 > 0, [ 035 #Output a pound symbol drl_prm1 = drl_prm1 - 1 ] ")", e pcom_movea ]

This generally occurs when you open a machine definition (like the default definition that you get when you update a V9 post) and start deleting things you don't need (like rotary axis components). If you change the component tree in your machine def. you will need to go in to make sure your axis combination(s) are still valid.

Why not just output t$ in pretract? Seems like an awful lot of work to output something that is already available... Then again, what do I know...

Change the line to "( Program Date - ", month$, "-", day$, "-", year$, ")", e$ Alternately, look in one of the X posts (i.e. Generic Fanuc 4X Mill.pst) in pheader$. They contain several options for date output. Should be easy enough to cut and paste some stuff from there.

Changing the direction in the MD is not going to have an effect unless you are using a new X post that reads those parameters. You may want to let your reseller have a look at your post if it doesn't have the rot_ccw_pos initialization. I am guessing that this is an older post that is not based off of MPFAN (which a lot of the 4-axis posts including MPMaster are based off of). They should be able to make whatever modifications are required for you.

Contact your reseller.

Set rpd_typ_v7$ : 0 in the post (it is most likely a 1 or 2 currently).

Rick, Aside from John's Ungodly misunderstanding of how control definitions work, the answer is actually very simple (but I am going to write a book to try to explain everything as best I can - so that he will get a clearer understanding as well). If you update a post (V9 or earlier) to X using the updatepst utility, a control definition is created in the process. The settings in this control definition reflect some of the variable initializations in your post processor (as well as the settings from the numbered questions at the bottom of the post which are no longer used). For a quick example of which variables are now set in the CD, open any of the posts provided with X. Each has a CD_VAR tag in the comment next to it if the variable is now set in the CD (these are the variables read in the update process). If you open the CD created in the update process and click the "Existing Definitions" button, you will see that there are two control definitions created. The first is a definition that does not have a post processor associated with it. This is labeled Default. The second is associated with the post processor that was updated. Both share identical initial settings. Generally what will happen now is that an individual will go in and start playing around with the various settings found in the CD that is associated with their post. Note that the "Default" control definitions settings are totally seperate and do not change when the settings in another control def are modified. If another post processor is added to the .control file, creating another control definition, the settings from the "Default" control definition are used to populate the various pages. The settings ARE NOT read from the post processor. This only occurs during the update post process. So, where am I going with this? Well, if you renamed you post and added it manually to a control definition, the initial settings in that control definition came from one of two places. If their was a "Default" control definition for that product type, the settings came from it. If on the other hand there was no "Default" control definition, then the initial settings in the new CD came from system defaults. In either case, all you have to do is to right click in any control topic and import all pages from the control definition that actually holds the settings you wish to use (the one that was associated with the post processor before you renamed it). As to the second issue (post text sections), whether you delete the sections yopu no longer need or not is really up to you. Leaving unneeded post text sections will not hurt anything but I tend to delete them if they are not needed. The only thing to remember is that like the CD, if there is a "Default" post text section, it will be used when a new control defintion is created. If this "Default" section no longer matches the section that was used before you renamed the post (i.e. you added a new misc integer option) then you will want to import the post text from the post in the same manner as you did for the CD settings (right click, import all, from post, select post, select the section you wish to import from, click ok). With all of that said, my personal recommendation to everyone is that they spend a few minutes reading the documentation and watching the videos available on the Multimedia Page of the Mastercam website. The videos and documentation go a long way toward explaining the concepts behind Control Definition, Machine Definition and the common issues end users face with them. As always, your local reseller should be able to help you with any issue you face.

I would suggest opening the product.set file that is installed with X (i.e. mill.set. lathe.set, router.set or wire.set). Copy the entire pprep$ postblock out of the new .set file and paste it into your .set file. This postblock contains the typical overrides for the CD settings needed for output from a .set file. You will also need to update any parameters that have changed between 9 and X. Refer to the Post Parameter Reference.pdf file that installs with X for more information. Of course you could just contact your reseller and ask for help too...

Most posts have this at the top of pcomment2$: scomm$ = ucase (scomm$) This forces all comments (manual entry, operation comments, etc...) to uppercase. (Remove the $ for V9 and earlier)

You cannot simply rename the files. Please visit the Multimedia pageon mastercam.com. Download the "Working with machine and control definitions" pdf file and watch the videos. They will explain everything much better than I possibly could in a forum posting.

Take 10 minutes to read the transition guide and getting started guide. This will save you a lot of time and frustration. Also, check out the videos and information on the multimedia page of mastercam.com.

Initialize cc_1013 : 1 (or yes$) This will allow cc_pos$ to be read when the 1013 line is read in the nci (which means the value will be available in psof$ and ptlchg$).

This is the section I was talking about: code: #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 # 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

Try adding sav_spc = spaces$ in ptoolcomm above the spaces$ = 0 line