Weird! After some quick test I actually got the best result by setting brklinelen$ = 0.00001. I'm not sure what all your tolerance settings are in the control def, but changing brklinelen$ has some unexpected results for me. Everything worked as expected when it was set to 0.1,0.01, and 0.001. Setting it to 0.0001 (which should be the value to break up as you want it), the post broke up the Z moves correctly, but failed to break the XY motion. I changed the NC precision and general math function tolerance to 0.00001 in the control def and set the brklinelen$ to 0.00001 and it seems to be break the lines up to the appropriate length. I'm also assuming you are outputting more the 4 decimal points for your linear axis as you would need to in order to break up a line that is moving in more than one axis at time (eg G91X0.0001Y0.0001 has a longer motion than the required 0.0001). HTH!

No problem!

Glad you go this sorted out! For future reference to define the post block above you would just copy and paste the block of code into the post following the structure and layout of the post.

Good catch! This is something that actually needs to be edited in the pcom_movea postblock. The problem is during the tool change the post is calling pcan2 twice, so you need to add the if statement to pcom_movea as shown below: pcom_movea #Common motion preparation routines, after prestart if not(toolchng), pcan2 <--add if statement if abs2incflg = 1, [ absinc$ = 0 abs2incflg = 0 ] pe_inc_calc HTH

My guess is that you need to eliminate the pspc value if you are using mpfan. I don't believe that post block has been defined. Alternatively you could add the pspc post block in by adding the following code: pspc # Creates spaces based tool level setting if sav_spc = one & omitseq$ = no$, " "

This code can be found in the mpmaster post which I'll just show here for simplicity. First you need to create a buffer near the top of the post, somewhere around all the variable declarations: # -------------------------------------------------------------------------- # Buffer 5 - Min / Max # -------------------------------------------------------------------------- b5_gcode : 0 b5_zmin : 0 b5_zmax : 0 rc5 : 2 wc5 : 1 size5 : 0 fbuf 5 0 3 0 0 #Min / Max Now let's define the variables for output and format them. There should be a list of variables all with a similar structure that the following can be added to: fmt Z 2 min_depth # Tool z_min fmt Z 2 max_depth # Tool z_max Then, in the pwrtt$ post block, add the following code to write the max and min values to the buffer: b5_gcode = gcode$ b5_zmin = z_min$ b5_zmax = z_max$ b5_gcode = wbuf(5, wc5) Now all that's left is to read the buffer after the tool change and output the max/min values. To do this you will need to create a new post block: preadbuf5 # Read Buffer 1 size5 = rbuf(5,0) b5_gcode = 1000 min_depth = 99999 max_depth = -99999 while rc5 <= size5 & b5_gcode = 1000, [ if rc5 <= size5, b5_gcode = rbuf(5,rc5) if b5_zmin < min_depth, min_depth = b5_zmin if b5_zmax > max_depth, max_depth = b5_zmax ] Then call the new post block in both ptlchg$ and psof$ since you are using mpfan. This should go right after the post line with the M06 (either sm06 or "M06" in the code): preadbuf5 if (opcode$ > 0 & opcode$ < 16) | opcode$ = 19, [ n$, pspc, scomm_str, "MAX - ", *max_depth, scomm_end, e$ n$, pspc, scomm_str, "MIN - ", *min_depth, scomm_end, e$ ] That should be all there is to it! If you are having trouble setting this up, have a look at the mpmaster post which has the functionality built in as a reference: Mpmaster Download

In mastercam, in the menu bar select the Settings Menu, open the Control Definition manager. Ensure that the post you are using is selected from the post processor drop down. Select the Machine Cycles option from the left hand list with the pink question marks. I'm assuming you are wanting to enable lathe turning canned cycles, so select the Lathe Canned Cycles option. Then select any of the boxes that are not currently selected for operations that you would like output as canned cycles. Make sure you save the control definition before exiting and reload the machine definition through the operation manager in any existing mcx files in order to have the changes take effect. Default posts typically support this feature, if not, the post will need to be configured for the correct output. HTH

The problem with this is that you can use the same tool in multiple operations, some using cutter comp, others not. The tool table will only output the first instance of the tool, which may or may not have cutter comp applied. In order to do this properly, you'd have to run through the code and save out the cutter comp values.

The documentation on installing the HTML setup sheet with all the necessary files has now been posted on eMastercam here: X5 HTML setup sheet installation

You should also watch for result = force(feed,feed). This will force out the feed rate the next time the feed variable is encountered in the code, regardless of whether or not there is a * in front of the variable. If you hunt down all the *feed and result = force(feed,feed) lines of code you should be able to remove these outputs.

Cannot say that I've ever run into this issue before, this might be best handled by the tech staff at your local reseller.

Looks like the post is already setup to handle the toolpath group comments. Just take the # symbol away from the front of this line: #if stpgrpname <> snull, pbld, n$, pspc, scomm_str, "TOOLPATH GROUP - ", stpgrpname, scomm_end, e$ Becomes: if stpgrpname <> snull, pbld, n$, pspc, scomm_str, "TOOLPATH GROUP - ", stpgrpname, scomm_end, e$

This is a bit of a cheat, but you can always just output the 10000 if the calculated feed is 0. In pfclc_deg_inv: if cuttype = three, cldelta = sqrt((x$-prv_x$)^2+(y$-prv_y$)^2+(z$-prv_z$)^2) if inversefeed$ = 0, frinv = fr_pos$/cldelta # 1/min else, frinv = fr_pos$/(60*cldelta) # 1/sec if frinv = 0, frinv = 10000 <-- ADD THIS LINE if rot_feed & opcode$ <> 3 & opcode$ <> 16, [ if frinv > maxfrinv, frinv = maxfrinv if frinv < minfrinv, frinv = minfrinv feed = frinv ]

Details details details, but you're right, needs to be defined, I was just being a little lazy.

if you shoot me a z2g I can look at the issue, but really going to be post/mcx specific.

My apologies, 20018 is the parameter, not sure why it wasn't coming out in the other post I was using. This is what happens when you lose touch So to answer the question just add this code into the pparameter$ post block if prmcode$ = 20018, stpgrpname = ucase(sparameter$) Then output stpgrpname where ever you want the tool path group name output, likely ptlchg$, ptlchg_com or ptlchg0$

What's the tool path you are running? Chances are the calculated line length is zero, so when doing the math things break. Are you getting an error when posting out saying dividing by zero or not?

That's the machine group name, not the tool path group name is it not? When I post out all parameters I don't see the tool path group name at all...

Craig's explanation above is correct for CNC based posts. If you are using an in-house based post (ie mpmaster, mplmaster, etc) the setting will be using the tool_table variable. Setting the variable to 1 will output the tool table: tool_table : 1 #Tool table, 0=no, 1=yes, 2=Predator VCNC, 3=MetaCut View

There are a couple of things it could be. Some posts have a switch in the top called "rigid_tap", set this to 0 to disable rigid tapping (which is the M29 output). Other posts use a drill parameter in mastercam to indicate floating or rigid, in which case you would need to look at the parameter label to determine the setting. I believe it is typically 0 for floating, 1 for rigid. If you are still having issues shoot me a PM with the post and I'll clear it up for you.

Interestingly enough I'm not 100% sure that it is possible to output the toolpath group name. The control definition settings allow for the output of the machine name and the machine group name, but not the toolpath group name. Searching the nci parameter reference it looks like the parameter that was used for this was stripped out in X3, so I'm not sure that it is possible at this point...

Glad to hear that you finally are getting the results you wanted!

This needs to be addressed with your post supplier and/or reseller. I can't stress that enough as a developer. We need to know what is going on in order to get the machine to operate correctly. That being said, we have a VTM post, which is basically a Multus flipped up on its end (or so I've been told). The macturn and multus are similar configurations, though the macturn has a lower turret.

In the control definition you need to select the tools menu and then select the "enable staged tool routines" check box. Then in the post you need to make sure that the next_tool$ variable is on the same line as your tool length compensation: pbld, n$, "G43", *tlngno$, pfzout, scoolant, next_tool$, e$

I think your best bet is probably to make a flag so that once the high speed has been turned on, the post knows. That way when you are retracting, you will only turn off the high speed if it's actually been turned on. So if operation 1 has it unchecked, operation 2 is checked, operation 3 is unchecked, it would turn on in ptlchg and when you go to retract, the flag would tell you it needs to turn off. phsm #High speed machining on if mi5 = one & hsm_flg = 0, [ *"G49", e *"G5.1Q1R",*shsms, e hsm_flg = 1 ] phsmoff #High speed machining off if hsm_flg, [ "G5.1Q0" hsm_flg = 0 ] Hopefully this isn't too convoluted, let me know if it is and I'll try to explain a bit better, but the bottom line is this method only turns the function off if it's been turned on. Since turning on the hsm happens at the start of the operation, you can use the current mi5 value and then you don't need to worry about it until the next time you want to enable it. Just keep in mind that every time phsmoff is called after the hsm has been enabled, it will cancel the code, so only call phsmoff when you want the hsm turned off which usually ties the code to pretract.