You cannot create Control or Machine definitions when updating "X" posts. That ability is limited to updating pre-X posts.

if smachinepath = "P:\MASTERCAM MACHINES\MACHINES\V-MAX800 3AX.MMD" | smachinepath = "P:\MASTERCAM MACHINES\MACHINES\V-MAX800 3AX.MMD-5", # V-Max 800, G95 to start rigid tap mode

Using a router post like MPRouter or Generic Fanuc 4X Router.pst should work fine. You will want to make sure use_oal is enabled: use_oal : yes$ #Scale coordinates to tool length with Aggregates This will allow the post to shift the X,Y and Z based upon the defined tool length and gauge length (pivot point to collet face - if set in component definition in MD). You will need to be aware of this setting to determine how you will set your height offset: set_g43_vert : 2 #Aggregate - set height offset register with tool in vertical position? # 0 = No, set in horizontal position # 1 = Yes, set in vertical position # 2 = Set in horizontal if right angle aggregate, vertical if tilting aggregate Your attached .zip file contains an .mcx file which is using MPFan. This post is not going to work for you as it does not contain any logic to map or scale the coordinates.

I installed it on my D: drive at home (1TB drive) because my C: is a small 60 GB SSD. I have not had any issues with it. (Win 7 Pro 64 bit OS). Not sure why his initial installation went bad but I know it does work for me.

You guys didn't download the version that corrupts the system registry did you?!?

I can do better than that Keith, you already have the information in your computer, you just need to look. Open up the McamX4_NCI_Parameter_Ref.pdf file (most likely located in C:McamX4documentation or C:McamXdocumentation) and do a search for rparsngl. Our doc guy (the amazing Rob Bernobich) has done a fantastic job explaining it and all of the methods for extracting parameter data (much better than I can do in a forum reply). To quickly answer the first question however, the difference between rpar and rparsngl is that rparsngl will return to value for a single item, using rpar requires you to initialize an 'implied array' of variables to get to the same information if more than one item appears on a parameter line. For example, in this case you would need to initialize three variables in a row in order to get the value you are looking for (the third item on the parameter line). Using rparsngl requires only a single variable (MUCH simpler).

That addresses the single axis rotation error but it is not going to address the missing variable initialization(s) in your post. These errors: 16 Sep 2010 02:54:55 PM - <2> - PST LINE (585) - Label has not been defined[20] 16 Sep 2010 02:54:55 PM - <2> - PST LINE (673) - Label has not been defined[9] 16 Sep 2010 02:54:55 PM - <2> - PST LINE (676) - Label has not been defined[9] 16 Sep 2010 02:54:55 PM - <2> - PST LINE (953) - Label has not been defined[9] 16 Sep 2010 02:54:55 PM - <2> - PST LINE (956) - Label has not been defined[3] 16 Sep 2010 02:54:55 PM - <2> - PST LINE (981) - Label has not been defined[11] 16 Sep 2010 02:54:55 PM - <2> - PST LINE (983) - Label has not been defined[11] Tell you exactly where to look to determine what is missing. For example, the first error: 16 Sep 2010 02:54:55 PM - <2> - PST LINE (585) - Label has not been defined[20] tells you to look at post line number 585, column 20. This will be the beginning of a variable. Chances are, all seven of these errors likely point to the same variable, which has not been initialized or formatted. I'm sure that if you post the entire line for each of the errors here one of the many post experts here will be able to tell you how to fix it.

Use: code: if prmcode$ = 20007, oa_len = rparsngl(sparameter$, 3) #Grab Tool OAL from 20007 line Make sure you format oa_len for output... ie. code: fmt "TOOL OAL: " 2 oa_len #Tool overall length

The drill block needs to be modified in the Machine Definition and the operation will need to be regenerated using the new block. It would be easiest to simply have your dealer download the correct post/MD from our extranet.

Ah, then you do not need the incremental value, you need the absolute value inverted. In that case, I would format two new variables for output: code: fmt X 2 probe_x #Probe X position output fmt Y 2 probe_y #Probe Y position output and then use this in the postblock: code: if drillcyc$ = 9, #Probe bore diameter or boss and reset fixture offset [ pdrlcommonb probe_x = xabs * -1, probe_y = yabs * -1 #Probe values are from current location back to origin pbld, n$, prorefht, e$ pbld, n$, "G320", diadwell, zbossdep, [if proappr > 0, *proappr], [if wcsupdate > 0,*wcsupdate] *probe_x, *probe_y, e$ pbld, n$, "G0", *proinitht, e$ pcom_movea ]

You need to change the xabs and yabs in the nwadrs functions to xinc and yinc.

Try this: code: if drillcyc$ = 9, #Probe bore diameter or boss and reset fixture offset [ pdrlcommonb sav_absinc = absinc$, absinc$ = 1 #Force incremental output result = nwadrs(strA, xinc) #Change address character to A result = nwadrs(strB, yinc) #Change address character to B pbld, n$, prorefht, e$ pbld, n$, "G320", diadwell, zbossdep, [if proappr > 0, *proappr], [if wcsupdate > 0,*wcsupdate] pfxout, pfyout, e$ pbld, n$, "G0", *proinitht, e$ result = nwadrs(strX, xinc) #Change address character back to X result = nwadrs(strY, yinc) #Change address character back to Y absinc$ = sav_absinc pcom_movea ] sav_absinc should already exist in your post, if it doesn't you will need to add an initialization for it: sav_absinc : 0 #Saved absinc value

Just thought I should point this out since it appears in all of our posts (and I believe Inhouses posts since they are based on our posts) since X was released. If you look at the comments at the top of the post you will find the following comment: code: # - Variable initialization with CD_VAR are read directly from CD. Changing these initial values # in the post will not effect output. These values are only processed during the update post routine. This relates directly to many of the variable initializations you display above. Like: code: sub_level$ : 1 #CD_VAR Enable automatic subprogram support breakarcs$ : 0 #CD_VAR Break arcs, 0 = no, 1 = quadrants, 2 = 180deg. max arcs arctype$ : 1 #CD_VAR Arc center 1=abs, 2=St-Ctr, 3=Ctr-St, 4=unsigned inc., #5 = R no sign, 6 = R signed neg. over 180 do_full_arc$ : 0 #CD_VAR Allow full circle output? 0=no, 1=yes helix_arc$ : 0 #CD_VAR Support helix arc output, 0=no, 1=all planes, 2=XY plane only arccheck$ : 1 #CD_VAR Check for small arcs, convert to linear atol$ : 0.01 #CD_VAR Angularity tolerance for arccheck ltol$ : 0.002 #CD_VAR Length tolerance for arccheck spaces$ : 0 #CD_VAR Number of spaces to add between fields omitseq$ : no$ #CD_VAR Omit sequence numbers? seqmax$ : 9999 #CD_VAR Max. sequence number nobrk$ : no$ #CD_VAR Omit breakup of x, y & z rapid moves The next note at the top of the post expands on this and relates to variables that are set by MD or CD parameters: code: # - Variable initialization with SET_BY_MD or SET_BY_CD are overwritten in this post by parameter or # variable settings from MD or CD. These refer to initializations like: code: vmc : 1 #SET_BY_MD 0 = Horizontal Machine, 1 = Vertical Mill rot_on_x : 1 #SET_BY_MD Default Rotary Axis Orientation #0 = Off, 1 = About X, 2 = About Y, 3 = About Z rot_ccw_pos : 0 #SET_BY_MD Axis signed dir, 0 = CW positive, 1 = CCW positive index : 0 #SET_BY_MD Use index positioning, 0 = Full Rotary, 1 = Index only ctable : 5 #SET_BY_MD Degrees for each index step with indexing spindle use_frinv : no$ #SET_BY_CD Use Inverse Time Feedrates in 4 Axis, (0 = no, 1 = yes) maxfrdeg : 2000 #SET_BY_MD Limit for feed in deg/min maxfrinv : 999.99#SET_BY_MD Limit for feed inverse time maxfrinv_m : 99.99 #SET_BY_MD Maximum feedrate - inverse time stagetool : 0 #SET_BY_CD 0 = Do not pre-stage tools, 1 = Stage tools use_frinv : no$ #SET_BY_CD Use Inverse Time Feedrates in 4 Axis, (0 = no, 1 = yes) Hope this helps stop the head bashing some

That will get the output to P5 as long as fs 4 or fs2 4 is setup as integer output ie. fs2 4 1 0 1 0 #Integer, not leading You will also need to multiply dwell$ * 100 in the drilling postblock to get it to output as P500 ie. dwell$ = dwell$ * 100

Um. No. You're not going to get anywhere trying to set a postblock call = a variable. Easiest solution (without having any idea what the logic in your post looks like) would be to use the nwadrs() function to change the address character of xabs and yabs for output and then to change them back. To do this you will need four string variables for X,Y, A and B. i.e. strX : "X" strY : "Y" strA : "A" strB : "B" Then in your drilling postblock where you are calling pfxout and pfyout you need to add result = nwadrs(strA, xabs) #Change address character to A result = nwadrs(strB, yabs) #Change address character to B ...then the output line where pfxout and pfyout result = nwadrs(strX, xabs) #Change address character back to X result = nwadrs(strY, yabs) #Change address character back to Y

You've clearly hit the secretly defined limit of 1,256,768,000 redo/undos... The locking of the icons is a safety feature meant to protect expensive CNC machinery from individuals that (obviously) cannot get things right the first time... Ok, I have no idea why they are grayed out...

We have had this ability since we released X ( or was it XMR1 or MR2... ) in any case, what I gave you (and what you have above) should work without error in any version since then. Edit - I just went back and tried it in X-MR2 and it works fine.

That's really not needed. You can format the variable for output like this: fmt "D#" 4 tloffno$ #Diameter offset number

If I had to guess I would say that the problem is most likely a rd_params$ command without setting rd_param_op_no$. Do a search in the post and comment out the command if it exists, that should fix the problem. As to why the error says zero, it is because the default value for rd_param_op_no$ is zero and it is an error because there is no such thing as operation zero.

http://www.benz-inc.com/products_wood.php?view=detail&ID=20 Tell Paul I said hello

In ptlchg0$ you'll want to change the logic to: if mi4$ = 1 & op_id$ <> prv_op_id$, n$, "M31" "(CHIP AUGER ON)", e$ #(added misc. int for auger 12/22/08) Then you will want to make sure the previous value is updated at the bottom of the psof$, ptlchg$ and ptlchg0$ postblocks by adding a line like this: !op_id$ #Update prv_op_id$ value This way the M31 line will only be output if the operation changes (while still using the same tool) and the new operation has mi4 set to 1. Shoot me over a zip2go if you still can't get it to work and I'll take care of it for you.

I'd recommend contacting your local dealer for help. It is unlikely that I will be able to help you via an internet forum.

Can you launch the debugger stand alone? (ie. double click the executable: c:McamX4MPDebugClient.exe) Are you getting an error message when it launches?

Deadhead, I can't guess as to why you are getting the A0. Shoot me over a zip2go and I'll take a look. toddm, this sounds like a misc. value issue. Again, I cannot say for sure without seeing the file and post (my crystal ball is foggy today). Dave, the section you pasted above is from the X4 MPFAN or MPROUTER post, I know it is because I just added the read_md switch for X4 When it is set to no$ (as it is above), the settings in the MD are NOT read, the variable initializations are used. Setting it to yes$ reads the MD settings (the ones with the SET_BY_MD label like vmc and rot_on_x) and ignores the variable initializations. Updated X3 posts will not have the read_md switch. If the posts are updated Generic Fanuc 4X or MPMaster based posts, changing the rot_on_x setting will have no effect.