this is just an idea I have used in the past. try extending the surface in all the directions before you trim it. sometimes the geometry is correct but the surface may not cross the geometry so it cannot be trimmed.

Our company used to do alot of rotation (G68) and we had no problem with the rotation, but inserted it by editing. All our machines our fadals. All our programming is done from the center of the part. I would insert the G68 as follows: G0 X0 Y0 E1 (program origin = center of part) G68 R0+90. X0 Y0 ( angle & rotation point) Z1.H1M8 this would then be followed by the normal program. One problem is an arc in the G18 or G19 plane cannot be done. As having to have all axis positions in every line I never did this, and never had a problem. Do not output arcs in the G18 or G19 plane. Never did try to output the G68 in the post so I do not know if this works right or not. In version 9sp1 I just use the transform function, it works very well.

oops!!, Iwas talking about the operational defaults, not any dfg. files.

does this happen why you are programming a job? if this is the case, mastercam only remembers the cfg. file for the toolpath on the initial call up of it, not everytime you use the tool path. So if the toolpath before had an incremental retract, the next tool path will also, no matter what. I just called up our reseller on this this morning.that is how it was explained to me. Hope this helps!!!

Our company uses the latest version of SDRC. We always have a parasolid file sent (ver.13) converts into MC9 very well. The only problem is if the SDRC part was constructed in an older version (ver7 or earlier) and brought into the newsest version you may have some conversion problems without migrating the construction up to date in SDRC.

I may have a simple solution to this problem. try putting the R-plane in at the G80 line, Or the initial tool height. We used to have this problem all of the time. This did correct the problem. Of course this would mean you would want to edit the post processor, or manually edit this move in on every drill cycle.

When looking at this file, the part on the right side the depth limits are set. The left side they are not set. turn off depth limits and it works fine. Hope this will help

Willy, thanks for letting me know that one. I guess the idea I had for our post is not going to work using the op_id.

Jim, maybe I misrepresented what is happening, the pocket toolpath with finish is o.k. but the next operation will come up as # 3 instead of #2 like the operation manager # is

I have a very extensive post for a fadal machining center, and Iam wondering if any one out there has tried to use the op_id variable in there post processor. the op_id would put in the operation # from the operation manager. the only problem I have encountered is any operation that has a finish pass, like a pocket toolpath, it adds one op_id to the # of operations. This would make the operation #'s not relate with the operation manager. I did contact our reseller, and they have not tried to do much with this command. does anyone have any ideas. Any help would be appreciated

this has been a problem since version 7 the tool path will only helix 1 time around then plunge the rest.don't know if this will ever be fixed. I have a couple of projects sent in to q.c. the best way around this is circmill or ramp contour.You could try to helix in the other direction, sometimes this will help.

try looking at this file hook1.mc9 on ftp site did a 3d contour then a shallow and a pencil. do not quite know if this is what you are looking for, so just take a look. may give you some more ideas.

the version 8 post is made for either with a G92, or fixture offsets E#'S. This does require the use of the misc. integers. and in version 8.1.1, the misc integers it would tend not to remember them from one tool to the other so you had to check the settings on every tool. this may be overcome by setting default misc integers in the configuration of mastercam.

I do have a post written for a fadal, but it has been totally customized to output the M94.1 function, along with many other customized features. It uses E#S. No rigid tap, will exit you from post. And the text file has been modified that goes with it. If interested here is my Email adress bmvogel@ bemis.com contact me if you woul like it.

I am using it right now . there are some problems with it inside version 9 it will lock out the "t" and the "alt+t" hot keys,(may be fixed now) and you will not be able to use mastercams verification, because metacut utilities will take over. so if you install it do not let it attach to the operation manager in mastercam as of yet. but do let it attach an icon to the menu bar since this does work well. it also has some problems reading the nci files. but posted files work fine.

Paul, to edit the post, go into the motion nc output area and edit in the following, this will give you a generic plunge rate in the z axis only. plinout ----- look for this in the motion area if feed = 0, feed = 2. put this in before anything else. I tried it and it does work. hope this helps.

Paul, you compressed the tool libraries when you converted them to version 8 and 9 and lost the plunge rates. Is this really what the issue is? If that was the case, I would go in and edit the tool library. The post could be edited, but I do not have the mpmaster post on my computer. I could help if I had the post. I only use a custom written post for fadal. I will download the mpmaster post and let you know.

Carl, On the line numbering, depending on how old the fadal machining centers are. The new machines will number the program as it is loaded into the pendant. So what I found is not to output line numbers. You may whish to consider to upgrade the software chips in the machining centers. Since the only cost is the travel time and installation time for the servicemen, the new chips have no cost.

you may want to try this out, I posted a file on the ftp site named dovetail1.mc8. what I did was create a series of slices off of the original surfaces. Then used a flowline toolpath.The toolpath would gouge due to the area that is noted in the file due to the sharp corners.So I went back and added a .255 fillet to the original geometry.You will not be able to produce a sharp corner where the fillet was added. The reason is that the flowline command forces the tool to fit in, and where the surfaces intersect, there is a sharp corner.Which will cause a gouge in the part. Look at the file this might help in what you are lookig for.

If this is version 9 you may want to look at the way the post outputs the rapid moves in the fadal post for example, the break rapid moves did not take care of this problem.( I had the same problem) if the post outputs somewhat like this after a tool change or beginnning of program *tlngno, pfxout, pfyout, pfzout try moving the pfzout to the line after to look like this *tlngno, pfxout, pfyout, e pfzout, e this will resolve the problem [email protected]

All I program for are Fadal vmc's, the post in version 9 seems to work well. I have not had a problem with the tool #'s or tool height #'s. The problem could be in the post, but highly unlikely. By the way, what format is the post output, 1 or 2 and do you use fixture offsets or work offsets. This could be helpful in solving your problem, since the post supports both formats for Fadal. [email protected]

I have tried to make the stepover smaller, just get an error that says "cannot determine a valid machining zone no toolpath created"

When using surface finish leftover (3d collapse) in ver.9, I have found that the larger the mold, the larger the stepover must become. On large molds this can be a problem because of a poor quality surface finish. I would like to know if anyone else is finding the same thing out, and if they have found a solution to this. I have already downloaded the patches available. [email protected]