Make sure that your tool is setup for the correct turret! This is crucial in telling mastercam which of the axis combinations you are using. The fact that you are having to change the same string in the post back and forth means that the post believe that all operations are for the upper turret, main spindle.

To check your tool settings, in an operation, right click and edit tools. Then select the setup tool button and ensure that the turret and active spindle are set correctly.

Just saw what Dan was programming. The issue is that he was machining in the same axis as he was trying to rotate about so the post had no way of knowing a rotation was necessary. I enabled the twisting option in his post with a few modifications and now he should be getting the right output. Just a solution update!

just sent you a PM with my email addy

Can you send me the file with your post and I will look at the programming/post to see what is going on?

I'm a little confused as to exactly what you are trying to do....whether you want the post to automatically rotate the part in the middle of a 3-axis operation or whether you've split the operation up into multiple operations.

The position of the rotary axis is controlled by the toolplane for these positional toolpaths. If you are expecting the toolpath to rotate the part in the middle of an operation, that's not going to happen on a 3-axis toolpath.

If you are repeating the same cut at the initial position, then repeating it 120 degrees away, you should just use a transform rotate toolpath (make sure you select toolplane rotation).

Otherwise just define a new toolplane that is a 120 degree rotation about Z of your original toolplane and program the next cut.

I'm assuming this is a 5-axis toolpath that you are trying to rotate. Did you try transforming by coordinate instead of toolplane?

Hard to say what the issue is without seeing the part.

Or follow Keith's....that works too...

At the end of the lsof, ltlchg$ post blocks you can add in the line:

result = force(ipr_actv$)

This will force out the G98/G99 at the start of every tool.

If you want it to be output at the first line of every operation (including when both operations use the same tool), you need to do a little more work. At the end of lsof$ and ltlchg$ you'll need to add:

!op_id$

Then at the end of ltlchg0$ you will need to add the following code:

if op_id$ <> prv_op_id$, result = force(ipr_actv$)
!op_id$

In the control definition, if you go to the feed page, there's a check box for convert rapid to maximum feed. If the box is checked, uncheck it and that should fix it up for you. Make sure you check both the mill and lathe feed pages for this.

To get in go through settings, machine definition manager, then select the control definition. This will ensure that the changes stick.

If this is not checked, let me know and we can walk through other options.

Sorry, I missed that this is actually a milling operation. The change needs to be in the mtlchg$ post block, not the ltlchg$. pspindle and prpm need to be moved above the coordinate output as shown below:

     ....
     pcaxis_on_m   #Postblock for mill transition
     pcan
     sav_absinc = absinc$
     if home_type > one, absinc$ = zero
     pbld, n$, pclampoff, e$        # Unclamp
     protretinc                        #Zero out the C-axis then redo the coordinate calculation
     pcom_moveb
     if millcc, pbld, n$, *sgcode, "C0.", [if y_axis_mch, "Y0."], e$
     else,
       [
       prv_gcode$ = c9k                  #change modality for forced output
       pbld, n$, `sgcode, pfcout, e$     #` used in case indexing mode
       ]
     pindex
     pbld, n$, pclampbrake, e$  # Clamp      
     pspindle
     prpm
     pcan1, pbld, n$, *sgcode, pfxout, pyout, pfzout, strcantext, e$
     pbld, n$, pscool, e$
     pcom_movea    #Update previous, pcan2
     ....

You are looking for this section of code in ltlchg$ (and possibly lsof$ if you are using an mplfan based post):

     if css_actv$,
       [
       if css_start_rpm,
         prpm # Direct RPM startup for programmed CSS
       else,
         pcssg50, pcss # NO RPM start - just output the CSS
       ]
     else, # Direct RPM was programmed
       [
       prpm # Output programmed RPM
       ]

This code will output the rpm value if the tool path is programmed in rpm, or the starting rpm value if programmed in css.

You will need to move this section of code above a line that will look something like this:

     pcan1, pbld, n$, psccomp, *sgcode, pwcs, pfxout, pyout, pfzout,
       pscool, strcantext, e$

The above line is the output for the coordinates and the rapid move. The line in your post may look a little different than this, but should contain the coordinate outputs (pxout, pyout, pzout, pfxout, pfyout, or pfzout) and the gcode call (sgcode)

HTH

Go into your control definition. Go to the files page. In the bottom left hand corner there is the "Posting error file" section. Set the keep error file box to "On fatal errors" and the message options to "All error messages to file".

These settings will eliminate the unnecessary err file.

I can confirm that this is correct, G43 for when the tool is vertical, G143 in all other situations. Don't ask me why they are running this way, but they are. I can also say that with G143 there are issues with some of the canned cycles as mgsanchez has indicated. These machines work this way, don't ask questions, it will only hurt in the long run!

By default the post has been setup to output the R value as an incremental distance from the clearance plane. In your case you are programming 0.25" as clearance and 0.1" as retract, so your output is 0.1-0.25=-0.15". It sounds like your control takes the R value as an absolute. If you are using the mplmaster post, there will a post block called prdrlout where you will need to uncomment a couple lines. Your post block should look like the block below with changes made to the final three lines:

prdrlout        #R drill position
     if mdrl_dir = zero,
       [
       refht_a = refht_z
       refht_i = refht_a - initht_z
       ]
     else,
       [
       refht_a = refht_x
       refht_i = (refht_a - initht_x) / dia_mult
       ]
     if absinc$ = zero, refht_a, !refht_i  <--remove # from the start of this line
     else, refht_i, !refht_a               <--remove # from the start of this line
     #refht_i, !refht_a            #Fanuc is always incremental from initial height <--add # to the start of this line

The long hand drill should be output as long hand drilling, not as a canned cycle as you have indicated. If you go into mastercam in the settings menu -> control def manager, under the machine cycles menu, select lathe drill cycles and ensure that the peck drill check box has been unchecked. This will output the peck cycle as a long hand cycle.

While still in the control def, going to the text menu and selecting lathe drill cycles, remove the double quotes from the subsequent peck and peck clearance cells to enable those fields.

Please let me know if you have any further issues. I'm going to look at the master on the server and see if the longhand has not been setup correctly.

You need to set the peck clearance variable in the peck drilling parameters. If the value is greyed out, in the control definition you can enable the variable by going to the text section, selecting the lathe drill cycles and removing the double quotes from the peck clearance value for the peck drilling operation. Then, in the drilling operation, make sure that you set a value for peck clearance and you should see the change in the longhand code.

Your best bet would be to download the mplmaster for X5 from here: Mplmaster for X5

In the post there is a switch called tseqno, set this value to 2 in order to have the sequence numbers match the tool numbers and you're done!

In mplfan you would need to turn off sequence number output in the control def, then in the ltlchg$ and mtlchg$ post blocks set sequence number equal to the tool number (n$ = t$). After setting the sequence number force it out by putting a star in front of it where you would like the sequence number to be output(*n$).

HTH

This is really a user preference. The post can be setup either way, either you need to compensate for the offset when you're positioning and programming the part or you can have the post developer setup the post to account for the 80mm shift and you wouldn't have to worry about making that 80mm shift in your program.

If you aren't using your work offsets, how are you setting the part up at the machine? I would recommend figuring out the datum tracking on the machine (usually G54.2) then you can set your part where ever you'd like and just set the vector on the machine that indicates where your program is referenced from.

If you are using delta start to center as your arc output type (as set in the control def), is it possible that the IJK values for the arcs are just round numbers that don't need 5 decimal points?

If you want to always have 5 decimal points output, you would need to add a "t" at the end of the format statement to force out the 5 decimal places:

fs2 2 0.5 0.4t #Decimal, absolute, 5/4 place
fs2 3 0.5 0.4td #Decimal, delta, 5/4 place

This would output I0.25 as I0.25000.

The other thing that could be happening would be setting the format in the code. By default in the parc post block the iout, jout and kout variables are set to format statement 2 or 3, but someone could have changed that on you. Also make sure that iout, jout and kout are in fact set to 2 or 3 in the post.

Right, that's why I assumed you were going after the number of lines in the sub-program. Some controls have a limitation on the number of lines that can be output in a given nc program. Physical file size limitations often force people to trickle feed the programs to the controller.

Sorry there's really nothing we can do on this one...

I'm assuming by size that you mean the number of lines versus memory size.

In order to do this, you would need to do this you could do one of two things:

1) either start a line counter, and every time a line is output increment the counter by one until you have finished the sub program, then copy the sub either into a file to be merge or it's own unique directory.

2) write out the subprogram to an external file, after that's complete, read the output file in as a buffer and check the buffer size to determine the number of lines (this is the preferred method). Then make your decision based on the size whether to copy the sub into a file to be merge later, or leave it in it's own separate file.

Using either method I believe you will need to delay the output of the sub call (M98/M198) as the call will be dependent on whether or not the sub will be merged later and you won't know this until after the sub has been output. Unfortunately in this case, mastercam will output the call to the sub prior to actually writing the sub.

I may be over thinking this one but I'm guessing those are the only ways to do it and either way will require some knowledge of how the post can manage files. This may be a more complex modification than you realize...but perhaps someone here has done it before and can offer up the appropriate code snippets....

HTH

maxss$ pulls the maximum spindle speed from the operation, not from the machine definition. So if you are programming a part on the sub-spindle, maxss$ will still be the correct variable and the post will apply this to your sub-spindle assuming that you have selected the sub-spindle as the working spindle for the given operation.

For mplmaster based posts this would be done by selecting the correct axis combination and ensuring that the stock has in fact been transferred to the sub-spindle.

The generic 5-axis post that comes with Mastercam is setup to handle all different configurations of machines, it just needs to be setup correctly.

All the settings to control this are handled at the top of the post file itself, not the machine definition.

So yes, it can be set up for a table/table configuration.

Looks like you've been doing a little post editing in the ptoolend$ post block!

This is a function of the pattern repeat cycle that is passing through the ptoolend$ post block twice per operation with a null toolchange. The nci file gives the post this direction.

You need to add logic in the ptoolend$ post block to look after the repeat instances. I would suggest using op_id$ to try and limit the output in ptoolend$. A quick test has this get the correct output, though it may need to be a little more sophisticated to deal with the specific operation type rather than all operations.

       else, #Null toolchange
         [
         if op_id$ = prv_op_id$, 
           [
           #if n1_posttype <> posttype$, pcan1, pbld, n$, pnullstop, strcantext, e$
           pbld, n$, *sall_cool_off, e$
           pbld, n$, pnullstop, strcantext, e$
           coolant_on = zero
           toolno = t$ * 100
           if home_type = -1,
             [
             prv_gcode$ = c9k
             #pbld, n$, `sgcode, toolno, e$
             pbld, n$, "G00", "T0100", "U0.", "W0.", e$
             ]
           else, pbld, n$, "G00", *toolno, "U0.", "W0.", e$
           else, pbld, n$, "G00", "T0100", "U0.", "W0.", e$
           pbld, n$, "M01", e$
           ]
         !op_id$
         ]

yeah, it's a struggle with some of these things unfortunately....

If you don't typically use sub-programs in your programs, my suggestion would actually be to use the subout$ function to output the code to an external file, then, as you are posting the code, write the tool diameter information to a buffer. Finally, after the processing has been completed at the end of the post, set your subout$ back to the nc file, write the tool table using the buffer information and merge the external file with the nc file.

HTH