This is from an mpfan post. The logic is based on the misc value text below: 1. "Work Coordinates [0-1=G92, 2=G54's]"//2 There should be other logic in the post to catch the G92 case(s).

Steve, There are a couple of issues here: 1) the way you are writing to the buffer is not quite right (although the way you read the parameters back in corrects for this). You have correctly defined a buffer size of 3, as you are wanting to store the mr9$, mr10$ and t$ variables. When you write to a buffer using wbuf, the post will fill a complete row in the buffer. The proper way to fill the buffer would be: g10z = mr9$ g10x = mr10$ gten_tool = t$ g10z = wbuf(5,wc5) This way you are filling a single row with all the data necessary rather than filling the first entry in the buffer for three separate rows. Then, when reading back in, the code would look like: ptooloffsets # Output of Tool Offsets for G10 rc5 = 1 size5 = rbuf(5,0) " ", e$ "(TOOL OFFSETS)", e$ while rc5 <= size5, [ "DEBUG*******START OF OUTPUT*******DEBUG", *rc5, *size5, e$ #used for debugging g10z = rbuf(5,rc5) "G10 L10", *gten_tool, *g10z, e$ "G10 L12", *gten_tool, *g10x, e$ "DEBUG*******END OF OUTPUT*******DEBUG", *rc5, *size5, e$ #used for debugging ] " ", e$ The single rbuf statement will fill the g10z, g10x and gten_tool variables. 2) The post will pass through pwrtt$ for each operation, so you need to make the decision as to when you want to write to the buffer. Once per tool? Every operation? when the tool number changes? The reason you are having an issue in this specific example is because the post passes through pwrtt$ one final time at the end of the file (gcode$ = 1003), so you will need to add a simple if statement to avoid duplicating the last tool (modifying the code from above): if gcode$ <> 1003, [ g10z = mr9$ g10x = mr10$ gten_tool = t$ g10z = wbuf(5,wc5) ] You will need more logic added to the if statement depending on when you want to write code to the buffer. Let me know if you need any other help.

Ah, I forgot that you will need to define num_pts as a variable somewhere near the top of the post where other variables are declared: num_pts : 0 Also, ensure that you have spacing before the lines you've added (but not the num_pts variable declaration above). I believe you may have a single space, but you should try to keep the if statement inline with the rest of the post block.

As Allan mentioned, the ret_on_indx function is used to control full retracts in between different index positions. You can set this value to 0 and all home position moves (G91 G28 Z0) between different planes will removed, so use with caution (ensure your clearance planes are setup correctly). Regarding the issue with the Z value not being output after the first operation, this is actually related to the number of points that are selected in the drilling cycle. When a single point is programmed mastercam is not outputting the rapid move after the cycle is cancelled. If you uncheck the use clearance only at start/end operation, you will get a G98 output referencing the initial Z position. Another fix is to output the Z-axis retract after the G80 line. Since the issue is based on the number of points you would need to pull that information into the post: pparameter$ if prmcode$ = 15083, num_pts = rpar(sparameter$,1) Then you would need to output the motion in pcanceldc$: pcanceldc$ #Cancel canned drill cycle result = newfs (three, zinc) if drillref = 0, zabs = initht_a #Make the initht the modal Z value else, zabs = refht_a prv_zia = zabs !zabs ps_inc_calc prv_gcode$ = zero if cool_zmove = yes$ & (nextop$=1003 | (nextop$=1011 & t$<>abs(nexttool))), coolant$ = zero pcan if drillcyc$ <> 8, pcan1, pbld, n$, "G80", scoolant, strcantext, e$ if num_pts = 1 & zabs <> initht_a, <-- Add this statement and code below in brackets [ gcode$ = 0 zabs = initht_a pbld, n$, sgcode, pfzout, e$ ] pbld, n$, sgfeed, e$ pcan2

Crev, As per the forum policies please refrain from asking for posts here. If you are looking for a post a good starting point would be to contact your local masercam dealer.

We've done this for a couple of different machines...

You are trying to create a custom drill cycle, but you need to do it within mastercams preset operations and parameters. For instance, there are a total of 20 different drill cycles possible in mastercam, each one corresponding to a specific post block. The drill parameters text found at the bottom of the post and in the control def are linked to these specific post blocks: [simple drill] = pdrill$ [peck drill] = ppeck$ [chip break] = pchpbrk$ [tap] = ptap$ [bore1] = pbore1$ [bore2] = pbore2$ [misc1] = pmisc1$ [misc2] = pmisc2$ [drill cycle 9 - 20] = pdrlcst$ (drillcyc$ controls which cycle is actually being called) You will not need to define any new post blocks, just use those that are available already in the post. You will need to pick one of these cycles and customize it with the code you have for peck drilling. Most posts already utilize the basic drill cycles from simple drill to bore2, so I would recommend looking at pmisc1$ and pmisc2$ to see if there is any customization there, if not, this is where your code should go. Also the drill parameters in the text section of the post link to specific parameters: [misc1] 1. "Peck drill detail" 3. "" -> dwell$ 7. "Peck" ->peck1$ 8. "Initial cut" -> peck2$ 9. "" -> peckclr$ 10. "Runout distance" -> retr$ 11. "" ->shftdrl$ Use these predefined variables when outputting your cycle. You can set your custom variables equal to these values so you don't have to change the formatting: fmt "Q" 2 peck1$ #First peck increment (positive) <- Already a predefined mastercam variable fmt "D" 2 runout #Runout distance fmt "I" 2 initial #Initial cut runout = retr$ initial = peck2$ Hopefully this will help you understand how the post works. If you continue to have issues, contact your local reseller, they should be able to help you out with adding in this cycle.

When using G43.4 with a trunnion table typically you would output all your coordinates unrotated, the machines internal kinematics will work out the motion. With a C90 for the first two operations and a C0 for the second two and all motion in tool paths being along the X-axis, I would expect that motion in one of the tool paths to be incorrrect, which you have identified as the second two operations. So, without seeing exactly what you're cutting it looks like the calculated coordinates for your second two operations are incorrect and need to be changed in the post. Chris

Hi Paul, As per the rules of the forum, please refrain from asking for posts. You should contact your local mastercam reseller who I'm sure would be happy to set you up with a post for this machine. Chris

It appears as though you have your "convert rapid to maximum feedrate" option selected in the control definition. Open your control definition under the settings menu, select the feed menu and uncheck the appropriate box.

look in ptlchg$ or ptlchg_com depending on the post, there should be a variable *tlngno$, this is the output of the H1. Add a "G43" before the tlngno$ variable: pbld, n$, "G43", *tlngno$, pfzout, e$

To output the G49 you will likely be looking at the pretract post block, although the location for the retract may vary depending on the post you are using. You are looking for a line that contains "G28", sg28, or sg28ref. From here you can add either the sg49 string if defined, or add "G49". The resulting line would look something like this: pbld, n$, sgabsinc, sg28, "Z0", "G49", e$ HTH

I've seen a couple already and have rejoiced... Thanks Colin!

Hooray for X7!

I would think a script would be the only way...

This is actually a good question. The reason that you are getting the wrong address is actually an issue with the post that we need to address. The first operation in a file that you have program is likely in the top or front plane (for vertical and horizontal machines respectively). When this happens, this post is not setting the prefix for the rotary axis since it believes there is going to be no rotation. The post then uses the default value defined in the format statement as you found, before eventually changing the prefix to the value stored in the machine definition.

The control is certainly setup for longhand peck drilling. Since it is, you will need to use the mastercam defined drill cycle parameters (first peck, subsequent peck, peck clearance, etc). Even if these values are greyed out, they may effect your output. As grammin mentioned if you are looking for a canned cycle, you will need to enable that option in your control def and then modify the post to match your desired output.

As per the rules of this forum, please refrain from asking for posts here. Contact your local reseller and they should be able to set you up with a post.

the drillcyc$ variable is used to indicate which drill cycle you are using. Assuming you are using the standard G83 and G73 in mpmaster, you would need to add logic saying: if drillcyc$ = 1 | drillcyc$ = 2, [ pbld, n$, "S5000", "M4", e$ pbld, n$, "G4", "P1", e$ ] Note that this method is hard coded, so anytime the drill cycle is cancelled, you will get an M4 output regardless of the direction of rotation for the drill. If you want you can look at the spdir2 direction to determine the current direction of travel: if drillcyc$ = 1 | drillcyc$ = 2, [ if spdir2 = 0, pbld, n$, "S5000", "M3", e$ else, pbld, n$, "S5000", "M4", e$ pbld, n$, "G4", "P1", e$ ] Again, this will output every time the G80 is output which I believe is not quite what you are looking for.

if you are looking for a more general solution, there are two variables, scomm_str and scomm_end which are output at the start and end of every comment. If you change these variable from "(" and ")" to "'" and "'" respectively, you would match the output from your sample code.

Mpfan should use the format I've described above, let us know if you have any other questions.

This really depends on the post that you are using. Some posts will have a misc value that you can set that will turn off the ref return for each individual operation. For a more permanent solution in the post, you can search for the pretract post block. Generally the line outputting these reference returns are found here and are output using an sg28ref variable like this: pbld, n$, sgabsinc, sgcode, *sg28ref, "Z0.", scoolant, e$ To disable the retract except for at the end of file you would add a condition to output only when nextop$ = 1003, like this: if nextop$ = 1003, pbld, n$, sgabsinc, sgcode, *sg28ref, "Z0.", scoolant, e$ You should also add an else statement to handle the output of coolant to be thorough: if nextop$ = 1003, pbld, n$, sgabsinc, sgcode, *sg28ref, "Z0.", scoolant, e$ else, pbld, n$, scoolant, e$

There are a couple of different gcodes you need to look at. 1005 is output for manual entry as comment, 1006 is for as code, 1007 is for as comment with no line return, 1026 is for as code with no line return Mpfan has this all setup for each of the different comment gcodes which should give you a starting point: pcomment2 #Output Comment from manual entry scomm$ = ucase (scomm$) if gcode$ = 1005, sopen_prn, scomm$, sclose_prn, e$ #Manual entry - as comment if gcode$ = 1006, scomm$, e$ #Manual entry - as code if gcode$ = 1007, sopen_prn, scomm$, sclose_prn #Manual entry - as comment with move NO e$ if gcode$ = 1026, scomm$ #Manual entry - as code with move NO e$ if gcode$ = 1008, sopen_prn, scomm$, sclose_prn, e$ #Operation comment if gcode$ = 1051, sopen_prn, scomm$, sclose_prn, e$ #Machine name if gcode$ = 1052, sopen_prn, scomm$, sclose_prn, e$ #Group comment if gcode$ = 1053, sopen_prn, scomm$, sclose_prn, e$ #Group name if gcode$ = 1054, sopen_prn, scomm$, sclose_prn, e$ #File Descriptor

Looks like there are a couple of issues with your post...the error file shows details about the update itself: 29 - 01 Nov 2012 03:02:02 PM - PST LINE (380) - The variable/string declaration is a duplicate the line number of the issue is found in the bracket and after the dash is a description of the the issue. Duplicate declarations are not an issue, the illegal characters maybe. Some of the parameters numbers have also changed since version 9, which is why you are getting these errors: 47 - 01 Nov 2012 03:02:03 PM - PARAMETER DATA - - Possibly incorrect parameter number detected: 10200. Please check the parameter number. If you are unable to work in the post file to fix the issues and the posted code is not good, I would contact your reseller to help you with the update.

Yes, you can use the update post chook to update the old post to X4. By selecting version 9 the update should automatically create a default machine and control def for your post. Just make sure that the post and text file are both located in the same directory when updating. You will not be able to use all of the new functionality brought about by the new machine and control def, but if the post runs fine the way it is that shouldn't be an issue.