Tom, It actually looks like you're probably picking the wrong drill cycle. You may be picking about the 6th or 7th drill cycle down in the drop down menu? Maybe try picking one of the top 4? Brett

Desmotom, I have done a part transfer on that machine before. I'm out of the office now but if you send me an e-mail I can help you with it next week. Brett

I think incremental with the filled format (less digits for decimals) will be the fastest. Brett

James, I'll take you up on the offer for the 31 manual. Please and thanks. Let's try the G5/G8 sometime soon. I have been told by a fairly reliable source that it can be done. The manual hints at this too but they aren't great with samples. Brett

Ron, Looks good. For the G08 P1 and the G05.1 Q1....yes, turn on the G08 P1 then call G5.1 Q1. Also, both must be activated before G43. With regards to the HPCC, I got this back from a local guy as well. G05.1 Q2 is auto filter (for arcs as I had mentioned earlier) and can only run in G5P10000 HPCC mode. So Q1 is not used with P10000 but if you've got the Q2 option you must call it inside the P10000. I guess the only thing left before testing is to figure out the accel/decel option (the other optional parameter on that line). Perhaps this is a machine specific thing (it's not in the books that I've got). Brett

All, I have been working on adding some of this functionality to mpmaster for everyone to use. I'll be sure to document everything very well so it can be used as a reference. I'm having a problem though.....I don't have a machine. If you've got some time to help, it will be beneficial to everyone. Here are a couple of questions that I've got: 1. Anyone here using the new HPCC G05 P10000? Looking for output format. Pg 78 of the 16/18i manual shows that it can be used along with G05.1. 2. I have seen several different formats for the G05.1 including the following: Q1 - I have been told that this is for simple interpolation Q2 - I have been told that this actually filters for arcs in the control and is an additional option. P/R - Either the P or R address used to determine the acceleration/decceleration characteristics (range from 1-10) Thanks for the feedback. I'll be adding the Mazak stuff as well. Brett

All, I have been working on adding some of this functionality to mpmaster for everyone to use. I'll be sure to document everything very well so it can be used as a reference. I'm having a problem though.....I don't have a machine. If you've got some time to help, it will be beneficial to everyone. Here are a couple of questions that I've got:

All, I just tried to make this work without much luck. Seems to be doable for canned rough and finish but when you start throwing all of the other cycles at it, it's tough. Strategy was to save out previous N values then force the new N to equal the saved N. Unfortunately, N is changing around like crazy because of all the buffering/streaming that's going on with the canned cycles. I suppose with MMT coming that will be the time to address this. Brett

MillingMan, If you send me an e-mail I'll provide you with the latest mplmaster post. There are no problems with two Ns on one line....that's for sure. As far as line numbers in general, they are unchanged from CNC's Fanuc 4-axis lathe post. The only thing that's been added is this: code: tseqno : 2 #Output sequence number at toolchanges when omitseq = yes #0=off, 1=seq numbers match toolchange number, 2=seq numbers match tool number So, if you'd like us to look into something please send it along. Remember that canned cycles and line numbering really don't play nice together....but we can try our best on it. Brett

Rich, You do need a machine def, but at this point, depending on where you're getting your post from, the actual configuration won't matter too much. I'd just use the default machine that allows you to do anything (3 rotaries). Brett

Yeah, that's what I thought...rapid over then feed at the new feed rate. quote: why would you want to do this anyway? Just want full support for the change at point menu if the user wishes to do so. Brett

All, Here's the question. Please help us out by letting us know how this would behave on your machine. G98 G83 Z0. R.1 Q.1 F50.95 X-.9277 Y-3.5448 X1.7993 Y-3.3274 F99. G80 For a change of F on the last line, would your machine actually feed over to that point at 99units/min and feed at 99 or would it rapid over then use 99 for the cutting feed. I always thought it was the later but have recently been told otherwise. Thanks, Brett

JimmyG, G28 is the ticket. Brett

MillingMan, You're looking for the pwcs call out of the ptlchg0 block. Brett

Richl, Why do you want to build a machine def for the evo? Brett

Larry, Download mpmaster from the posts page, take your programmed file in Mcam, post it with the HMC definition. Bang, you have working code to go against. Brett

All, An update for Mpmaster has been placed on the posts page. New work includes: removal of pstop AB, then XY, then Z pgear location convert rapid to high feed only for moves with a linear component Thinking of adding roughed in support for look-ahead and shape comp (eg. G08 and G05.1 on Fanuc, G05 P2 and G61.1 on Mazak) Let us know how we're doing. Brett

It will be up soon. We've decided to rework the pstop block also as it's a bit redundant and people always miss that one when editing posts. Brett

David, No Z output on keep tool down between multiple passes when I try. You could send me your file if you like. All, I definitely agree that it should be broken up so have done that for you. So in ptlchg0$ it changes from: code: if fmtrnd(prv_cabs) <> fmtrnd(cabs), [ if lock_codes = one & not(index) & rot_on_x, pbld, n$, *sunlock, sunlockcomm, e$ pbld, n$, [if not(index), sgabsinc, pwcs], pfxout, pfyout, pfzout, pfcout, e$ if lock_codes = one & not(index) & rot_on_x & cuttype = 0, pbld, n$, *slock, slockcomm, e$ ] To this: code: if fmtrnd(prv_cabs) <> fmtrnd(cabs), [ if lock_codes = one & not(index) & rot_on_x, pbld, n$, *sunlock, sunlockcomm, e$ pbld, n$, [if not(index), sgabsinc, pwcs], pfcout, e$ if lock_codes = one & not(index) & rot_on_x & cuttype = 0, pbld, n$, *slock, slockcomm, e$ pbld, n$, pfxout, pfyout, e$ pbld, n$, pfzout, e$ ] The second portion of the block remains unchanged. Note the call to pcout isn't all that necessary but left in if an update is req'd and to output or calcualte anything extra that may have been added. code: else, [ pbld, n$, sgabsinc, [if not(index), pwcs], pfxout, pfyout, pfzout, pcout, e$ ] If you're using ret_on_indx note that the same change is made in pstop. From this: code: if lock_codes = one & not(index) & rot_on_x, pbld, n$, *sunlock, sunlockcomm, e$ pcan1, pbld, n$, *sgcode, [if not(index), sgabsinc, pwcs], pfxout, pfyout, pfcout, *speed, *spindle, pgear, strcantext, e$ if lock_codes = one & not(index) & rot_on_x & cuttype = 0, pbld, n$, *slock, slockcomm, e$ To this: code: if lock_codes = one & not(index) & rot_on_x, pbld, n$, *sunlock, sunlockcomm, e$ pcan1, pbld, n$, *sgcode, [if not(index), sgabsinc, pwcs], pfcout, *speed, *spindle, pgear, strcantext, e$ if lock_codes = one & not(index) & rot_on_x & cuttype = 0, pbld, n$, *slock, slockcomm, e$ pbld, n$, pfxout, pfyout, e$ You get an extra output line of the coordinates if you're using ret_on_indx and you change planes with an xform. We may rework this. Update to appear on the web very soon. Thanks everyone. Brett [ 01-08-2007, 02:56 PM: Message edited by: Brett Thomas ]

All, Been working hard on it and it is very far along....just haven't gotten it up on the web yet. Maybe this is the push I need to get it up there. That will probably happen at the end of the month. For now, if you want it, please just drop me an e-mail. Brett

Jack, Is that a custom kit on an SSR? That looks amazing. All, You guys want it as a switch or seperate by default and user of post must modify otherwise? (We try to avoid too many switches to keep the post looking pretty) Brett

All, That's great feedback. ptlchg0 would be the only spot affected by this. Note that the post goes through ptlchg0 on depth cuts, multiple passes, xforms, and between 2 operations with the same tool. I guess the assumption is that the user is programming with safe clearance heights. At this point we're handling it the same way as was done in v9. We'll run some tests and look into making the change permanent. Thanks Brett

David, Go to the pcirout block and remove the result = force statements for full arcs. Brett

OK, Setup the M00 M01 refresh in a block called prestart. Seems to work quite well. Couple other very minor updates also...update on the web shortly. Thanks so much everyone. Brett

code: wcstype : 2 #0 = G92 at start, 1 = G92 at toolchanges, 2 = G54, 3 = Off Go into your post and flip the switch. Brett