You seem to have a number of questions, I would recommend talking to your local reseller to get these modifications done.

You have pounded out the comment$ call, which is where all the comments are output from operations/manual entries. This means if you have two operations using the same tool, and the second operation has an operation comment, it will not be output. If you are using a manual entry, why are you selecting it in the transform operation in the first place if you only want it output once? You can likely restrict the comment output if you really want to by putting the logic in front of the comment$ block call: if op_id$ <> last_op_id, comment$ This will only output comments if a new operation is called, which in during a transform doesn't happen.

You likely will need to put in a condition on that output that will only output the comment if the current operation id # doesn't equal the previous (op_id$ <> last_op_id). If you look in mpmaster there is a plast post block that will set last_op_id = op_id$ at the end of every toolchange/null toolchange. Based on your code I'm assuming you're using transforms? When using a transform the value of xform_op_id$ doesn't equal the op_id$ value, when programming without transforms, these two values are equal. HTH

psgcode would reference a post block or a variable defined as psgcode. If it has not been defined as a variable, this will error out. If this is trying to refer to a post block named psgcode, putting a * in front is bad syntax and does nothing. The problem you may find with simply putting in *sgcode is you may get lines that only contain the G-code, with no coordinates after. One way to get around this is to compare the formatted version of the current coordinate to the formatted version of the previous coordinate or check to see if the incremental value is non-zero (but this tends to be less reliable) if fmtrnd(xabs) <> fmtrnd(prv_xabs) | fmtrnd(yabs) <> fmtrnd(prv_yabs), etc or if fmtrnd(xinc) | fmtrnd(yinc) etc

Canned cycles are a whole other can of worms (no pun intended!). The work to get these sequence numbers output correctly is a little more involved than the steps to get the sequence numbers output in the fashion you wanted for regular tool numbers. Your reseller should be able to help with making this modification.

This is a little more complicated. Setting tseqno to 1 will output only a single sequence number at the start of the tool change. When tseqno = 1, the post is actually using the n$ variable to count the tool changes. Since you want to keep outputting sequence numbers through the operation, you will need to create a different tool change counter. Forget about tseqno, it's not setup to do this. Set tseqno to 0, define a tool change counter, and just set the sequence number equal to the tool change number * 100 at the start of each tool change (in ltlchg$ and mtlchg$). Try something like this: toolchng_cnt : 0 ltlchg$ ... if not(synch_flg & tool_op$ = 67), #Suppress tool output if cutoff during part xfer [ toolchng_cnt = toolchng_cnt + 1 #Increments tool change number seqno$ = toolchng_cnt * 100 #Sets current sequence number to tool change number * 100 n$ = seqno$ #sets sequence number for output if omitseq$ = 1 & tseqno > 0, [ if tseqno = 2, n$ = t$ pbld, *n$, [if home_type = -1, *sgcode], *toolno, e$ ] else, pbld, n$, [if home_type = -1, *sgcode], *toolno, e$ ] mtlchg$ ... toolchng_cnt = toolchng_cnt + 1 seqno$ = toolchng_cnt * 100 n$ = seqno$ if omitseq$ = 1 & tseqno > 0, [ if tseqno = 2, n$ = t$ pbld, *n$, [if home_type = -1, *sgcode], *toolno, e$ ] else, pbld, n$, [if home_type = -1, *sgcode], *toolno, e$ Then all you need to do is make sure your sequence numbers are being output in the control def, and set the sequence number increment to the appropriate value (looks like 2 for you). HTH

The local reseller should always be the first point of contact. You're in capable hands!

I've attached a post that should address some of these issues. I've added two new switches, hsmcancel and g05output. The g05output should be set to 1 if the user has the option to output the G05 and set to 0 if it is not supported on the machine. The hsmcancel is set to 1 if you want to cancel the G61.1 along with the G05. If set to 0, the cancel will only happen at the end of the file. I made these switches rather than misc values as it seems like something that would be set once for a machine and then never touched again. Let me know if there are issues or further functionality needs to be added. mpmaster.zip

you've been PM'd!

what version of mpmaster did you start with? If you send me the post through PM I can take a quick look, should only take a couple minutes to setup...

The reason you are not getting A-axis output is likely because you are not programming any tool paths at positions other than A0 (remember that if the tool plane and wcs plane are the same, there is no rotation). As a result, the rot_on_x variable is not being set as the rotary axis information from the machine definition is not being passed to the post. With that being said you can override the settings in the pset_mach post block by commenting out where the rot_on_x variable is set and hard coding the rot_on_x variable to 1 (for rotary about X-axis) or 2 (for rotary about Y-axis): pset_mach #Set post switches by reading machine def parameters rot_ax_cnt = 0 rotaxerror = 0 rot_on_x = 0 #Turn off rotary axis unless it is detected in machine read - supresses rotary output in 3 axis machines ... #We only need these set at toolchange (and start of file). No need to set them each time a user may call rd_md #if sav_rot_on_x = zero, rot_on_x = zero <--Comment out this line #else, rot_on_x = rot_axis <--Comment out this line rot_on_x = 1 <--Add this line HTH

Mpmaster is meant to be generic, so flavouring the post to account for each of these brands is not necessarily the goal. We're trying to provide a platform for users to build off of. That being said, please let me know what changes you would like to see to the high speed functionality (or any other changes for that matter) and we can assess and implement the changes that make sense given our goal.

There is a built in switch in the mplmaster and mpmaster posts called tseqno. Set this variable to 1 or 2 (depending on whether you want the sequence number to indicate the tool change number or the tool number) and you should get what you're looking for. If you aren't using an mplmaster/mpmaster based post, you can download the post and follow the logic in the post by searching for tseqno. Then just apply the logic to your post.

I can't speak on behalf of CNC software, but we at In-House have only two generic posts available for free, mpmaster and mplmaster. We have generic engine posts that are available for purchase at a reduced cost compared to the posts developed for specific machines.

A couple of questions. You said you wanted to move the Z3 up in code, but the desired output does not have this move, do you just want the Z3 line removed? Also I'm not sure how you've set up the probing cycles in the post. In mastercam I'm assuming there are two separate operations used to produce this code (since there are two different probing cycles used). Can you please confirm?

This is dependent on the post. Some post will actually have a switch built into that will allow you to change between the two styles of output. Your best bet would be to contact your reseller with the request for the modification, they will know what is needed for your specific post.

Totally agree with Colin! I tend to just do my editing through the post since it's open anyways...

It sounds like the control file may have become corrupted somehow??

That's in the control definition on the Files page. In the bottom left hand corner there is a "post error file" section. Ensure the keep error file section is set to on fatal errors and message options should be set to all error messages to file.

Hmm, never run into that one myself. Did you try starting from a blank mastercam file, loading the machine def and then making the change? Alternatively you can change this text at the bottom of your pst file. If you open the pst there should be a section called [CTRL_MILL|DEFAULT] (or generally CTRL_PRODUCT|CONTROL NAME). Change the misc value text here and reload the machine def in mastercam and you should be good to go!

Forgot, feed needs to be pulled from a parameter in the null tool change, the fr_pos$ variable doesn't update until in the operation. I've sent you the updated post.

you can call pfcalc just before the feed line is output to ensure it is being set... if you still have problems, send the post over and I'll take a quick look, should be something straightforward.

I'm assuming the feed is being output in the ptlchg0$ post block. Without looking at the post, the one thing I would suggest is looking at the pfcalc post block. There may be a conditional statement that is preventing the update based on the current gcode$ value: pfcalc #Feedrate calculations, gcode 0 does not evaluate if gcode$ <> zero, [ #if not(use_frinv) & (abs(fmtrnd(cabs)-prvcabs) <= 0.001 | index | not(rot_feed) | opcode = 3), pfcalc_u_min # G93 rotary / G93 linear if (abs(fmtrnd(cabs)-prvcabs) <= 0.001 | index | not(rot_feed) | opcode$ = 3), pfcalc_u_min # G93 rotary / G94 linear else, [ #if cuttype = one & (cutpos2 <= one), #Proposed change if cuttype = one & (cutpos2$ <= one | cutpos2$ = four & (opcode$ < 5 & opcode$ > 12)), pfcalc_u_min else, pfclc_deg_inv ] if ipr_type <> prv_ipr_type, prv_feed = c9k ] If you pound out the gcode$ if statement you may get what you're looking for. You could also look at the pxyzcout block and see if it is setting feed there for instances in which no rotary axis is present: pxyzcout #Map coordinates if rot_on_x, [ if cuttype = zero, pxyzcout0 #Toolplane Positioning if cuttype = one, pxyzcout1 #Axis Substitution if cuttype = two, pxyzcout2 #Polar Conversion if cuttype = three, pxyzcout3 #Simulatneous 4 axis (Multi-axis) if rot_ccw_pos = one, csav = -csav if mr_rt_actv <> two, [ pcoutrev if index, pindxcalc pfcalc ] else, feed = fr_pos$ ] else, [ xabs = vequ (x$) feed = fr_pos$ <---THIS LINE NEEDS TO BE THERE! ] Again, with out knowing what you started with for a post or looking at the post, these are just guesses....

If you look in the pretract/pretract0 post blocks you should see a line similar to this: pbld, n$, sgabsinc, sgcode, [if gcode$ = 1, sgfeed], *sg28, "Z0.", [if gcode$ = 1, feed], scoolant, e$ Comment out this line by putting a # in front of it: #pbld, n$, sgabsinc, sgcode, [if gcode$ = 1, sgfeed], *sg28, "Z0.", [if gcode$ = 1, feed], scoolant, e$ Since the safety zone will add extra moves in the nci, this should be the only change that's needed. You may or may not have a G91 G28 Z0 at the start of the file as well, if you would like that removed, look in the psof post block for this line and comment it out using a #: #pbld, n$, sgabsinc, *sg28, "Z0.", e$ HTH

Our post uses the tool plane to calculate the c-axis rotation when your tool is parallel to the machines axis of rotation. So if you have a C-axis (rotation about Z) and your tool is vertical (along the Z-axis), any C-axis value is technically achievable. So we built in a function to allow the user to control the C-axis rotation based on the rotation of the plane. If you take the top plane and rotate it 90 degrees, the post will identify this and rotate the C-axis 90 degrees. In our post this is enabled through a switch called "use_twist".