Hey guys Hopefully not a stupid question- there are many ways to accomplish what I want to do in my CAD package via native or equation-driven functions- but I cant find one in MC. Im looking to create a pattern for use in texturing a surface. The pattern I want is a series of nested circles. Scale works fine for one approach- where you are increasing or decreasing diameter of each instance, but the limitation seems to require this to happen in the implied direction (the radius multiplier requires that a <1 value means circles are nested internal to the initial geometry etc). Im looking to do a hybrid, where for example an initial circle of 1” dia would be patterned such that the next might be 1.1”, then 1.18, then 1.24, then 1.22, etc, where the pattern is expanding in diameter on net, but the increase in radius in real terms is decreasing for each instance. Is there any simple way to create a sequence of geometry like this, where the true radius is changing (I don’t want to just replicate a curve of a fixed geometry- I need each curve profile to have a shared focal point)? I can do this manually, but it would take a lot of time, and adjusting the pattern to suit the surface it will be applied to would be hellish. Best

Hi Colin That does seem to have fixed the problem in play here. So, firstly, let me say thank you for your time and insight; it is not the first time you come to the rescue- and it is appreciated. I do pay it forward- Im just not qualified to do that here. Secondly, although the comment assigned to this call in the post seems innocent enough, are you aware of any implications this change may cause that might lead to trouble? Hard to imagine this would be used in some conditional check and eliminate the Y axis lol. But it seems strange this would be omitted by default- since I cant see a reason to not use it 'if' the system is defined as 4+ axis. To the others that commented on this thread- Yes, the system did output A values for any operation that had any A change in that block of code. So, if later in an op the table rotated, the system would generate an A0 for the initial positioning. It simply neglected to do so if there were no operations that leveraged an A move. This isnt normally a problem, but it became a problem where I had broken out a multi-op process into separate files to permit the selection of some conditional feature which had to happen in sequence. And in that, often the rotary would be offset, and it was easy to miss that, or for an operator to assume the table would return to A0 if they canted it to attach a component etc. Best to all-

Hey guys Hopefully an easy question. Using MPMaster uner MC2017 on a 4axis VMC. For whatever reason, it isn’t outputting an A0 for initial positioning after a tool change. I get the X/Y/Z values, but no A if the value of A is 0. So, if there is an A-axis bias from a prior op, then problems… I have tried a few things I have found via search here- for example frc_cinit : 1 Just wondering if there is a basic codeblock that perhaps I need to uncomment, or if there is a pass parameter, etc. Ive not had luck pecking at this, so I though perhaps someone here with far better knowledge of the post might be able to point me in the right direction- Any help is appreciated, as always. Thanks guys- enjoy the week

Yes, I did read your comments in the other thread- I appreciate that post and your response here. As I mentioned above, the issue I face is not (conventionally-speaking) a function of order of different operations. It is that for a given continuous-motion toolpath on an organic surface, I don’t really have option to break down motion without a huge amount of effort. Even that would be less a burden relatively if we were running 10K parts, but we do prototyping, and 10-20 parts of a given type is a lot for us. Putting limits in the MPMASTER does seem to work in catching moves that violate the output, but that isn’t helpful except for a notification. It throws a warning, and seems to cull the offending (remaining) maneuver(s) from the output even though they are machinable if the trunnion simply moved the other direction for repositioning. The basic sim wont catch it regardless, and the advanced sim strangely will show ‘proper’ motion if you set it for manual limits (as with the video Giang posted on Youtube for a 5-axis problem which is similar- which seems strange- the logic for repositioning properly exists in a bolt-on sim but not in the toolpath generator?). Hence my question- where Giang opted for the generic Haas 5-axis post. Was just hoping MC has enough smarts to realize that a violation on a rotation limit in one direction on an A rotation in only one of two possible rotational solutions doesn’t mean you abort that operation, but that you cut what you can, and then continue on for an extension of that cut once it becomes kinematically possible by rotating the table within the constraints defined. Just really hard to understand how that is not native to MC, since that move might involve entry-exit paths which the post is not going to manage well absent significant effort, and where this concept exists for even basic 3D 4-axis machining with concepts like containment boundaries and check surfaces- which can require significant modification of the toolpath in 4-axes by the MC engine. Best CW

Hey guys Sorry for what may be a stupid question. Im running 2017, and I just acquired a 4th axis trunnion for my rotary table. In the past, I had no trouble with the standard MPMASTER post. But, with the trunnion, there is the issue with rotation limits. I have been able to implement base limits in the machine def, and that works as regards the post (it simply will not post any operation that MC has generated an excessive rotational angle to achieve). But that doesn’t help much- ops are omitted, and I cannot simulate natively since the omitted ops are only in the .nc code output… My understanding is that the logic for this is typically found in a 5axis post, but from a MC perspective, I would have thought defining limits in the machine def would tell it how to position the table (what angles to generate as NCI before the post even looks at it). That way, I can simulate motion/travel natively. And that would seem to be more a function of a 5axis toolpath parameter set than the post… So, do I stick with my 4axis MPMASTER post, and tweak the rotational limits in the operations themselves, or is there some interplay between MC and the post where MC will use logic in the post for figuring out how to position the table (as with native simulation etc)? Sorry- just a bit confused, and any clarification would be much appreciated. I did do some searching here, and found some references, but mostly they were in regards to physical limits of the trunnion (trunnion table crash with the column, etc), and not about preventing an undesired rotation of the table for what is a 4-axis toolpath. There is a forum entry just below which is similar, but again, that is more about hard limits and less about having MC figure out how to deal with complex 4axis surfaces within a single op (i.e. not taking shortest path, but not simply cropping code either). Best CW

Well, first just wanted to thank you for this help- the level of detail in the response made the approach very easy to apply. On first glance, it seems to do what is needed. Ill have to run a few different toolpath types at it (seems my controller has weird requirements on G17/G18 for peck drill vs arc motion, even though it can only move in X/Z). I didn’t apply the code change elsewhere, just in the case it might end up spitting out a G17 or G18 at some tool change, or a null change, etc. I understand that the Post is generic, and that edits are required. Because Im using a strange controller which is based in LinuxCNC, there are some unconventional approaches and some limitations especially as regards canned cycles. And that has required a lot of minor changes, and just simple stuff via the Machine Control config. But some of the stuff (like the plane change thing) is just a little outside of my comfort level, given the potential unintended consequences. If I see anything weird, Ill post to this thread the operation data and related code output. Thanks again- have a great weekend CW

Hey guys Hopefully a relatively easy question- Im running MPLMASTER. It is not outputting any plane selection code in the file (no G17/18/19 anywhere). It is a simple Lathe Rough/Finish sequence on a spherical test part, so lots of arc moves are output. My controller defaults to G17, and it seems my current post settings default to G18 (but implied, not as posted). Is there a way via MC to force a G18 output at beginning of file, or do I need to edit the post? Any guidance on how to get this implemented is appreciated. Regards

Hey guys Yea, my controller is a Dynomation Kflop (really neat implementation, 8axis full integration, DSP/FPGA based so you get well-coordinated motion even at 500IPM). But, the front end is just running LinuxCNC, and the team behind that has sort of an internal conflict brewing about G17 vs G18 for lathe drilling. Some in the project insist G17 should be required for peck drilling on an X/Z lathe, and some see this as a useless approach that will only choke on legacy g-code… But the G17 side won out. I’m hesitant to alter the post to just blitz the G18 references to G17. Im not familiar enough with the post to enforce this replacement only for peck drill ops. I just don’t know the implications of that for other canned cycles- threading etc. I switched to long-hand for peck drill, and that works well enough. But I had hoped that maybe there was a switch in MC to tell MPLMaster to use G17 in place of G18 for these types of ops. I cant seem to find any reference to that in the post or in published docs. Not critical- long hand is working- but if anyone happens to know a method to do this via a switch or how to create a conditional replacement just for say a Peck drill op based on some constant I create in the definition section/header, Id appreciate any guidance on it. Thanks guys- enjoy the weekend-

Hey guys A bit of a problem, hope someone is more familiar with it that I am. Just tried to post for a LinuxCNC-based lathe, and I get this error: “Y value unspecified in xz plane canned cycle.” (CENTER DRILL - .5 DIA.) G55 N116 T11716 G18 G94 G97 S1300 M03 G0 X0. Z.25 G83 Z-1.5 R-.15 Q1000 F3. My understanding is that G18 is a problem for some controllers operating a peck cycle on an X/Z lathe. If that needs to be G17, is there a simple edit to the post (Im using MPLMASTER here) that will allow for this without causing too much trouble in ways I haven’t thought about (I cant think of any on a 2-axis machine- no helical entries etc)? Or maybe there is a switch in Mastercam? I can probably just bypass this with a forced longhand instead of the G83, but Id rather try to get this figured out in case it might affect other similar stuff. Thanks for any help-

Hi Orvie- I didn’t have the ‘force tool change’ enabled here, and removing comments uncheck didn’t alter the output from the Post at all. But perhaps this would help for some circumstance- so I thank you for the ideas- Colin- Thank you for the guidance. Im an aero engineer learning Mastercam/Post coding as time and migraines permit, so Im not all that clear on which instances in the Post to alter (there are two Pretract subsections (Pretract and Pretract0), and within them, some conditional logic with their own SG28 references. I did modify them to a condition I felt was reasonable. Following is the output for the first couple of passes. Can you let me know if this is more or less what you would want to see? N120 T186 M06 (5/8 INDEXABLE FLAT ENDMILL) N130 (MAX - Z1.) N140 (MIN - Z.5) N150 G00 G17 G90 G55 A0. X.54 Y.9047 S3101 M03 N160 G43 H186 Z1. …cut commands N230 Z1. F50. N240 G00 G90 G53 Z0 N250 G00 A-60. X.54 Y.9047 … cut commands N330 Z1. F50. N340 G00 G90 G53 Z0 At present, the machine still homes Z between rotations of the table, but it doesn’t home the table- which is a big win. Is that just a function of where my machine controller defines G53 to be? Thanks again for the help in this- Regards

Hey guys- Hopefully a quick question- Im doing a simple 4th axis op (basically, just cutting bar into a hexagon, for custom preload nuts). Im leveraging the ‘transform/rotate about origin’ functionality, so that I can just do a contour/face path and then repeat per 60 deg rotation in A. Problem is, my post (MPMASTER 2017) is setup to export a G28 on completion of an operation. It seems the Transform/Rotate is literally just a ‘Copy selected ops X times’ function, along with the translation/rotation commands it inserts. So, I end up with a G28 in 6 cycles here. Yea, I can hack the post to prevent that, or manually edit the code, or even just setup a G53 type thing to limit travel, but it seems like this should be a native option (to prevent retracts until the end of a program, not just end of op, when you have a Transform/Rotate op). And, it may, so perhaps it is in the Misc Integers, or some manual entry I can add between ops in the Toolpath tree. But, I have not found a reference to best practices here, and I would be grateful for any guidance. Kind regards Rob

Coming at this from a software-engineering background, I think it is a mixed blessing. Commenting code is indispensible, especially if you are collaborating. Formatting helps also. But the way this language is structured, with some strangeness with formatting variables and managing inline functions, the paradigm takes some getting used to. The code works- I revised the retract speed to a minimum value or a factor based on federate, whichever is higher- to permit increases in the process speed. Ran the code on a 6061 aluminum plate 0.75” thick with a form tap at 10-12 full-depth tap ops/minute, 240 holes total, with zero problems. No dwell was needed given the retract height, but because of the clutch in the tap head, never hurts to have a little buffer there in case the back-out takes a little longer than normal. The only FYI I might suggest for anyone using this approach is to slightly decrease the feed to RPM ratio (maybe 1-2%), so that you have some margin if the tap doesn’t engage smoothly. This will allow the mechanism a little extension- well within the Tapmatic range before the reversal, in the case you have a slight imbalance in your head travel vs RPM process. Appreciate the feedback guys- if anyone sees errors or has ideas for improvements, Im happy to make the changes/test/post the updated code.

Hi Clarence- Thanks for the tip- that helped a great deal. As Im not familiar with the rules of inline functions with the postprocessor, I put together some fairly brutish code that seems to do what I need. If you get a spare moment, could you have a gander and let me know if I have missed something terrible? I dont expect to use incremental mode for this system- so I didnt even look into the 'if' aspect for this. Obviously, I hard-coded the rapid retract for the reversal gear, and maybe that is better done with some logic (a minimum value of X or retract value *1.2, whichever is greater)- I dont want to have to pass in additional variables/parameters, as they are too easy to omit . Likewise for the distance to rapid retract- but perhaps that could fit in using a peck cycle with that value as the 'peck' distance; Im less likely to forget that! #Use this postblock to customize drilling cycles 8 - 19 pdrlcommonb #if drillcyc = 8, pcan1, pbld, n$, pdrlxy, pzout, pcout, pindexdrl, prdrlout, dwell, if drillcyc$ = 8, [ sub_prg_call = peck1$ pcan1, pbld, n$, *sg00, *sgabsinc, pfxout, pfyout, pfcout, pindexdrl, strcantext, e$ pbld, n$, "M98", *sub_prg_call, e$ ] if drillcyc$ = 9, [ #Define tap position n$, *sg00, *sgabsinc, pfxout, pfyout, pfcout, pindexdrl, strcantext, e$ # calculate the exit feed required for the 1.75x reverse RPM drl_exitfeed = feed*1.75 # define tap depth and feed rate n$,*sg01, pzout, *feed, e$ #command a rapid reversal to Z-.15" to engage reversing gear zabs=zabs+.15 n$,*sg01,*zabs,"F20",e$ # feed out at 175% of cut feedrate to reference height, and pause if defined in Dwell zabs=refht_a n$,*sg01,*zabs, *drl_exitfeed, e$ if dwell$, [ N$,sg04,*dwell$,e$ ] ] else, "CUSTOMIZABLE DRILL CYCLE ", pfxout, pfyout, pfzout, pfcout, pindexdrl, e$ pcom_movea

Hey guys Running X8 with MPMaster for post. Im trying to setup a simple approach to using a Tapmatic auto-reversing tap head for an older mill. There are a couple of challenges- the reverse federate is 1.75x that of the forward federate To engage the reversing gear/mode, you need to retract some distance (specific the head- in my case, 0.15’) as a rapid, and then revert to the reverse feederate above. Needs to be some pause in the process- so that the tap can have time to retract in the case there is some clutch slipping on retract. I setup a new drill cycle as cycle 9, and did my best to figure this out. Looks fine in the GUI, but having strange problems with output- for example, user variables showing up as both a label and also as a value sequentially (i.e. a variable created called drl_exitfeed is defined, and then assigned a value of feed*1.75 in cycle 9. When I include a line like “G1”, drl_exitfeed,E$ just as a test, I get “G1 drl_exitfeed x.xx”, where x.xx is the correct retract value, but the label name is oddly showing up as if it were quoted text…) I don’t know if this is best done as long code, or canned. Likewise, not clear if Im better off with a variation of a tap cycle or drill/bore, where perhaps the tap feed/speed calcs help on the entry side but complicate things on the retract side. I have looked at some sample codes some of the gurus have posted here, but still pretty blurry-eyed. Any help in the form of links or code would be truly appreciated- Regards Rob

Hey guys Sorry if this is overly simple, but I cannot find any references online or in the help files. I have a female mould project which has a 45” x 4” 3D cavity. My 3-axis machine travel limits will not permit this without moving the workpiece. I don’t see any simple way in Mastercam X4 to permit me to just limit machining operations to a subsection of an object (which does not have split faces, etc). This seems bizarre, as there are a number of scenarios where one might want to remachine just a subsection of a part (i.e. TIG a small gouge from a tool break, or just cleaning up a section with a finish not up to what was anticipated, etc). It is easy enough to just slice up the master part, and setup several separate projects. I guess I could use STL output from verify as input to sequential operations, etc. But all this just seems more complex than it should be. Is there really no way to just draw an ‘area’ for machining which is not dependent on existing geometry/edges, and then just update the coordinate system for each section? Again, maybe this is just so simple as to be implied, but I cant find a single instance/example anywhere of its implementation. Kind regards for any thoughts on this-

Hi John Presumably, the code for a single hole (X/Y positioning omitted) would be something like: G90 G00 Z.04 G01 Z-.30 F12.5 G01 Z-.05 F75 G01 Z.250 F21.8 So for a 4-40 tap at 500rpm, you feed at 12.5, then at bottom you do a rapid retract of .25" to engage the reverse gearing, and then retract at 1.75*(initial feedrate)- so that at 500rpm spindle speed, and 875rpm tap speed, you are retracting at the appropriate rate (21.8 in this example). So ideally there would just be additional fields to define the reversal retract distance (i.e. .25"), and also the gear ratio for reversal (some are 1:1, others are 1:1.75) for the basic tap operation. Mark- yea, Im 100% sure. If I use a simple bore cycle with feed rate for retract, the head will retract faster than the spindle, and disengage the gearing. The tap motion stops until the spindle retracts another .25" at which point the gear engages, etc. This is not good for the head's internals, and it makes for an ugly thread. There are several models that have this 'feature.' In concept, it is very helpful for machines that do not have tight speed control on the spindle, as long as the code leverages it correctly. Best, Roland

Hi Im running X2 with the MPMaster post, and am looking to run a Tapmatic tap head (auto reversing) on an older mill. Problem is, some Tapmatic types have a modified gear ratio on retract to allow for a faster cycle time. Typically, that is 1.75x the cutting feedrate. The suggested feed on the head is: (1) tap at whatever speed is appropriate for defined RPM/pitch, (2) do a rapid retract of approx 5mm to engage the reverse gearing, and (3) retract at 1.75x the feedrate in #1. I imagine that I can use a feed override for retract (not sure of the control supports that), but rapid retract phase in (2) is not something I know how to implement. Im hoping someone has a post mod for this already that I can incorporate, or use as a guide, as my post coding skills have been limited to much more simple tweaks. Best, and happy holidays- Roland