rpd_typ_v7$

Set it to 0

rpd_typ_v7$ : 0

By default, when a comment string contains only numbers and optionally the symbols ”.”, “+” or “-“ it is automatically converted from the text string into a numeric value and placed in the commvar$ variable. When this happens, the scomm$ string is cleared (which is why nothing is output as a comment). This allows the post writer to use the numeric value contained in commvar$ if so desired.

Prior to X, if you did not want a numeric value but rather a string containing numbers, you had to convert the value in commvar back into a string and then output it (and this had to happen in the pcomment0 postblock).

In X, we have added the ability to disable the commvar mechanism by initializing commvar$ to -1.

commvar$ : -1 #Disable automatic conversion of numeric comments

The v9.1 Post Processor Reference Guide has an example of the logic you can use to capture the value and convert it the old way (do a search for commvar in the 119 Comments.pdf file).

Take a look at the pq postblock. Many posts modify the format statement for arc output there:

pq              #Setup post based on switch settings

You'll need to change the two or three to match the oputput you desire.

Gcode is correct, MR1 has not been officially released. My guess is that Prosin Molds will want to reinstall MR1 when it is released as what they have now must be a production candidate version. We're doing all we can to get this thing buttoned up as quickly as possible. Please continue to be patient (as my boss would say).

[ 03-22-2007, 06:41 PM: Message edited by: Paul Decelles from CNC Software ]

Find this line in pretract$:

if nextop$ = 1003 | tlchg_home, pbld, n$, *sg28ref, "X0.", "Y0.", protretinc, e$

Just change the X value to whatever you want.

Do a zip2go and email it to me at [email protected]. I'll have a look and pass it on to Roger if I need to. Make sure the zip2go contains the .mcx, .pst, .control and .wmd files (I really don't need the other files).

Gee, I wonder what the update post chook is for?

Gregg,

Send me the post and I'll have a look. [email protected]. Should be a quick modification.

What I put above is exactly what you need. Do this for me. Delete whatever it is you have in the post (in terms of variable initializations and logic for this prompt) and put this in (cut and paste) overwriting your pheader$ line:

fq 55 scoordsys "coordsystem name"  #Define post question 

Save the .pst and post a file. Once you see that it works, remove the pound characters from the beginning of the "if mi3$ =1,", "[" and "]" lines so it looks like this:

fq 55 scoordsys "coordsystem name"  #Define post question 

The "fq" and variable initialization lines MUST start in the first column (all the way to the left). The logic inside of the postblock MUST be indented.

fq 55 scoordsys "coordsystem name"  #Define post question 

Most modern posts do not output the actual value held in refht$ so there is no prv_refht$ value to look at (it will always be 0) so the logic above (Tim's first inline logic statement will work fine) always results in output. You'll need to add a !refht$ to populate the prv_refht$ variable.

The placement of the !refht$ is really dependent upon the logic in your post. You may be able to add it to the first hole post block (i.e. pdrill$, ppeck$, etc...) or you may be able to place it in a block like prdrlout (MPFAN based posts). Impossible to say without seeing your post.

Actually, you may want to go with a 'carrot' symbol in the format statement:

fs2 18 0^3 0^3t # Format for dwell

rather than

fs2 18 0 3 0 3t # Format for dwell

This tells MP to omit the decimal if a 'whole' number is encountered and to output a decimal point if a 'real' number is encountered.

This is what resellers are for. Both SFA and MacDac are more than capable of fixing this in 2 minutes.

Make sure you have the "Write NC Operation Information" check box checked in the Files topic of your control definition (local copy and then disk copy to make it permanent).

This pretty much says it all: http://www.black-blades.org/video.htm (requires sound, safe for work).

I guess I will need to post every time someone begins a thread like this. X2 has a bug in the parameter output for the Milling spindle min/max speed settings.

They are supposed to be:

17605 min_speed #Minimum spindle speed

17606 max_speed #Maximum spindle speed

and are coming out as:

17608 min_speed #Minimum spindle speed

17609 max_speed #Maximum spindle speed

Changing these values will fix the issue until the X2-SP1 release. Then you will have to go back in and change them back to 17605 and 17606.

In reality however, these checks are not really needed at all as it is impossible to program outside of the specified range in Mastercam.

You may want to just modify the pspindle postblock, removing the min.max check altogether to something like:

pspindle        #Spindle speed calculations for RPM

Change pfxout, pfyout to pxout, pyout

Change this:

pfr_l           #Format feedrate for lathe

To:

pfr_l           #Format feedrate for lathe

You need to change the Coolant settings in the Machine Definition (General Machine Parameters) to use V9 coolant options. X coolant options are canned text based and do not work like V9.

Why not just use the Clearance height (G43 line) and retract height (your G1 line immediately following) so you can take advantage of the absolute/incremental options with those fields in the drilling dialog? All I see there is a long hand drilling cycle, no need for anything special.

Use either the GENERIC FADAL FORMAT_1 4X MILL.MMD or GENERIC FADAL FORMAT_2 4X MILL.MMD (depending on the format output you need - use the MM version is you are running metric) they both come with your installation and both are already set to output signed direction (like the Generic Fanuc 4X Mill.pst, the posts read the Machine Definition parameters so you change the output there, not in the .pst file).

pip,

Did you try running the X-MR2 post in X2 without updating it? Updating should not be required unless it is a MPGen5X based post (which contains a version check in the .psb portion) or another post with similar logic (in which case you'll likely have to contact the post developer to update it).

I'm going to guess that you are using a post derived from MPMAHOYZ. That post uses a scalex initialization to flip the output:

scalex$    : -1.0    # Scaling of .NCI at input - x,y,z,i,j,k

You will have to set fastmode$ = 0 in pprep$ as the scaling factors are ignored when fastmode$ = 1. Add this into your post near pheader:

pprep$          #Pre-process postblock - Allows post instructions after the post is parsed but before the NC and NCI file are opened.

Scaling is not recommended in Mill, Router or Lathe post files. If you want to flip the axis output, you are better off creating a new variable or set of variables (x_mult, y_mult, z_mult for example) and using those settings in pxyzcout (mpfan based posts). Remember that you will also need to flip i, j and/or k depending on the axis you flip (you may want to look at MPRouter from V9 or Generic Fanuc 4X Router.pst from X, they are both set up to use x_mult,y_mult and z_mult).

Just put a 400 clearance in the 2nd op to match the first op and you will get exactly what you are looking for. The post is outputting exactly what you are handing with the settings you currently have in your operations.

34, smcname, 34, e$