Peter, Add this to your ptlchg0 postblock code: sav_rev = rev * m_one right before the code: pcom_moveb about 20 lines down in that block. You're done. The post keeps track of your current "rev" and makes decisions accordingly. It uses sav_rev for axis sub paths and sav_rev only gets set at the toolchange. If you want the same behaviour at a toolchange you need to set code: frc_cinit : 0 #Force C axis reset at toolchange I'll look into adding this as an option with switch to mpmaster and update the post on this site. Also, it looks like the sign of this expression is incorrect in the ptlchg1002$ block which I'll look into BTW...the feed rates don't look bogus to me....they look correct. Brett

Peter, Older version of Mpmaster should also be fine. Perhaps describing the situation will help a bit. Are you doing axis sub with depth cuts or multi-passes or something? Brett

Peter, Try downloading mpmaster from this page and give it a try. The post automatically keeps track of your current "rev" and will not reset itself unless you have the one_rev switch set to a 1. Brett

Another thing to go along with that. You really want t lot of code in changes of cut direction and change of axis angles. I receommend use of angle point generators to tighten up the code. Do not add linear generator as you do not want a lot of code down straight lines with little to no change in direction and change in axis angle.

Phil, Whether in G93 or G94 you should be getting a calculated feed rate on pretty much every line when running simultaneous 5-axis. Is that the case in your program? If you've got the G93 option on the machine I'd try that out first. If not, G94 will be ok provided the feed calc is correct. In G94, it is generally not sufficient to just output a linear feed rate. You need the rotary component hence a new value on almost every line. Brett

Gcode, The force_output switch should be right at the top of the post, just below all the commented out header information: force_output : 1 #0 = Modal G code output at toolchanges, 1 = Force output of all G codes (see also force_wcs) Chris

Ocean Lacky, I've been told that the Matrix control can handle any Gcode from G0 to G3 inside G61.1. I can't find the info in the Fusion control though. You need it to force high feed? CNC Apps Guy, Looks like the sg49 string was missed. It would be nice to keep that as part of the hsm post blocks so it's definietly modal on a restart. So I've got: code: N150 G49 N160 G94 N170 G05.1 Q1 N180 G43 H263 Z125.9772 What's the deal with the G90? I'll work on updating the tapping to the 21st century next. Brett

Thanks for the feedback guys. Just got back from Westec and will look at this stuff soon. Brett

Post is supporting control high speed mode functionality. Look at the .doc file on the mpmaster X2 page for more info.

Does your 9 post do everything you need it to do? If yes, then don't bother. This just has some basic new functionality and fits in a little better with the machine and control def.

All, Updated Mpmaster and high speed machining notes on the mpmaster page. Changes include: Control def uses the same tolerance for NC precision as the output format statement. We had it tighter for arcs in previous versions but that causes helix issues (Z motion of .0001). Arc checks are working fine as are currently set. safe_index (mi4$) has been added to allow the user to pick the order of indexing for 4-axis machines. force_output has been added to force the output of modal G codes like G94/G95 etc. High speed machining support for Fanuc and Mazak controls with mr1$ and mr2$. See the notes on that page for this as well. Thanks to everyone for your help and feeback on this one. Particularily James Meyette for the high speed stuff. Brett

The current version of mpmaster that's on the posts page has this line at the bottom of ptlchg_com code: if not(convert_rpd$), result = force(ipr_type,ipr_type) remove that to get rid of the forced G94/G95. We've switched to a new style with a switch called force_output to force out modal G codes for restarts. Expect to see this very soon. Brett

John, Are you using that post that I sent you the other day? Brett

Hey guys, We've been using the paths (swarf incl.) and have had success. For swarfing, the key is to pick specify number of cuts, put in a margin so it doesn't calc right at the surface edge, then use the axial shift to drop the tool back down. Works mint! Brett

The Canadians, although not partial to anything in particular, also like all that TRORI and COMPCAD stuff. It works dynamite for simultaneous machining! Brett

John, The new X2 version of mpmaster definitely outputs the speeds correctly. There may have been a time where the post was between revision and the max_speed and min_speed parameters were still being read in via lookup tables. Quickest thing would be a file compare to eliminate the max_speed and min_speed variables completely. There would also be one if statement that would need changing in pspindle. Delete this line: if maxss$ = zero | maxss$ > max_speed, maxss$ = max_speed and change this line: if speed < min_speed, speed = min_speed to this: if speed > maxss$, speed = maxss$

Just wanted to put some minds at ease: "MPParam Output Corrected (All Products) MPParam has been modified to output correct spindle speeds, lathe turret parameters, and tool changer parameters. MPMaster-derived post processors may need to be updated." After some quick tests it looks like mpmaster posts that ran originally in X2 will NOT need to be updated to run in X2 SP1.

All, We've had quite the debate over the past while as to how users wish to approach the parts. We've always had it as CXY S_M03 Z but were asked by several users to change to C XY S_M03 Z now we're being asked to change it back! Having several approach options is possible but we'd like to avoid making a mess of the post. Your feedback would really help us out. Brett

Couple of ways to do this... if wcstype = two | wcstype > three, [ sav_frc_wcs = force_wcs if sub_level$ > zero, force_wcs = zero if sav_mi9 = 1, workofs$ = sav_workofs if workofs$ < 0, workofs$ = 0 if workofs$ <> prv_workofs$ | (force_wcs & toolchng) | sof, [ g_wcs = workofs$ (or + 1 if you want a work offset of 0 to equal H1) *g_wcs ] force_wcs = sav_frc_wcs !workofs$ ] At the top of the file change this: fmt G 4 g_wcs #WCS G address to this: fmt H 4 g_wcs #WCS G address With this you still need to select your work offset in mastercam as you were before, it's not tied to the angles.

Ha ha, thanks for the plug Greg. My colleague, Brett Thomas, is actually already slotted to look after the post for this machine.

An updated mpmaster post has been put up on the web (for version X and X2) The change is to force the reset and output of the arc plane (G17) after G18/19 were used in previous operation.

Dave....you are my hero!

Yeah, I got the stuff from James.....everything aside from HPCC (which we've done on the Makinos). Going to run an HPCC test at a customer then add it all in. That will include the Mazak stuff too. Watch for it soon. Brett

All, We have reworked the posts page on this site emastercam posts and added a download page for our new mplmaster (mill-turn) post. This post is based off of CNC's Generic Fanuc 4-axis post. The mplmaster post download comes with several part transfer files and some transfer notes. The posts are only made better by your feedback so please let us know how it's working. Thanks to Chris McIntosh for his dynamite work on the page. Brett

Henry, I've worked with Okuma to develop posts for a number of their machines. If you do have any issues in the future and you're trying to find a post, don't hesitate to give me a shout.