As a user of both Mastercam and Volumill this saddens me deeply. Especially considering we purchased volumill last year after IMTS. Like others have said the mastercam toolpaths and the volumill toolpaths are much more compliments to each other than competitive. Personally I will keep an installation of x4mu3 with volumill running alongside x5 if volumill stops working after the next maintenance release. Sorry if I am late to the conversation but I just learned of this as I was checking the volumill site to see if there was a new release of volumill available.

Not quite sure how to ask about this without giving what we are doing as an example to make it clear so here goes. When we make a program for our Makino A-55e for our OEM bike parts, we do it using incremental subprograms. The subprograms are stored in a folder that pertains to the part we are running, while the main program is separate, it controls changing the tools, spindle speeds and location then calls up the subprogram to run the part. Well today the programmer was creating a new size and was adjusting his subprograms. He decided to make a change in mastercam and repost that one subprogram, which caused a crash because he forgot to delete the reference return g-code. Now I know we can probably set up our posts so that when we are creating subprograms it will not put things like the tool calls, lengths, ref return codes, etc. But the way it is now he has all his paths in one file and then has to go through and post them out individually and then go through and edit out all the crap not needed. I guess what I am asking is there a simple way of handling subprograms and their creation in mastercam? Is he going about the right way he is doing it now or is there an easier way so that he can contain the main and the subprograms in a single mastercam file and then post it out correctly? Sorry for the long read and I hope you guys can understand the point I am trying to convey. Thanks Jon

Everything I have posted is from our original post not the one I have saved to modify. And yes I think this is a version of the mpmaster. The thing is I am sure some of the post was modified by our reseller and some by an engineer who is no longer here. I don't want to send it to our reseller because I don't think this should be too complicated, but with all the mods that may have been done already it doesn't appear to be an easy task. Plus it could have been the reseller who have done the commenting out of the lines which has only made it harder to understand. I've asked my boss about sending me to the basic post editing class and he seems interested in doing so, but at the moment we are swamped with work and behind so no time to make a trip. Either way I will look at this more when I have some time.

Unless I am mistaken I am thinking the # denotes a comment. Here is our posts' section of what you are talking about. quote: pfcout #Force C axis output if index = zero & rot_on_x, [ if use_rotmcode & cabs <> prv_cabs, *sindx_mc if absinc$ = zero, *cabs, !cinc else, *cinc, !cabs ] pcout #C axis output if index = zero & rot_on_x, [ if use_rotmcode & cabs <> prv_cabs, *sindx_mc if absinc$ = zero, cabs, !cinc else, cinc, !cabs ] From what little I understand it seems that we are using the pindex component to output the Indexer position. So should I take the pindex out and replace it with pfcout? Looking at it further it appears to be checking the current position against the previous position and if they are equal it does nothing. So should I remove this statement here: if use_rotmcode & cabs <> prv_cabs, *sindx_mc

Ok adding the pfcout didn't work. Here is what our toolchange section looks like: quote: ptlchg$ #Tool change pcuttype toolchng = one softc = 1 if wcs_mode = one, #G92 block output (on EACH tool) [ pfbld, n$, sg92, *xh$, *yh$, *zh$, e$ ] if prog_stop = 1, pbld, n$, *sm01, e$ if prog_stop = 2, pbld, n$, *sm00, e$ pcom_moveb pcheckaxis pbld, n$, *sgcode, *sgplane, scc0, sg70, sg80, *sgabsinc, e$ n$ SG08 e$ c_mmlt$ #Multiple tool subprogram call ptoolcomment comment$ pcan result = newfs(15, feed) #Reset the output format for 'feed' pbld, n$, *t$, sm06, e$ sav_absinc = absinc$ if wcs_mode = two, absinc$ = zero if opcode$ = 3 & nextdc$ = 7, #Check for rigid tap [ tap_dir = fsg1(-ss$) tap_speed = speed pcan1, pbld, n$, *sgcode, *sgabsinc, *tap_speed, sm05, "M90", pwcs, pfxout, pfyout, pcout, strcantext, e$ pbld, n$, *sgtap_prep, e$ ] else, [ pcan1, pbld, n$, *speed, *spindle, e$ n$ scoolant, e$ pbld, n$, *tlngno$, pwcs, pfxout, pfyout, pfzout, pindex, e$ # pcan1, pbld, n$, *sgcode, *sgabsinc, *speed, *spindle, pwcs, pfxout, # pfyout, pcout, pgear, strcantext, e$ ] #pindex # pbld, n$, *tlngno$, pfzout, scoolant, pstagetool, e$ absinc$ = sav_absinc #pcom_movea toolchng = zero c_msng$ #Single tool subprogram call I noticed the pindex which I am assuming is a sub-program callout. And here it is: quote: pindex #Index output if index & rot_on_x, [ if softc = 1, [ if (prv_indx_out <> fmtrnd(indx_out)) | (prv_cabs <> fmtrnd(cabs)), [ [if use_rotmcode, `sindx_mc], *indx_out !cabs, !cinc ] ] else, [ if (prv_indx_out <> fmtrnd(indx_out)) | (prv_cabs <> fmtrnd(cabs)), [ if rot_lock, pbld, n$, *sunlock, e$ pbld, n$, [if use_rotmcode, `sindx_mc], *indx_out, e$ !cabs, !cinc if rot_lock, pbld, n$, *slock, e$ ] ] softc = 0 ] Hope this makes sense to you guys because I am lost.

I just had an operator crash the machine because our post does not put the A(indexer) position with each tool if it is not changing. The operator started up in the middle of the program and just plowed my thread mill into the part. Is there a simple change I can make to our post to fix this? Any help is greatly appreciated.

The blend mill toolpath is pretty nice. I just hope they get the WCS fixed in X5.

Sent it off to them. Figured a work around by creating blend path in top wcs so it would come out right. Then saving the toolpath as geometry and deleting all the z moves. Then go into my created wcs and us those lines to drive a contour toolpath with no compensation. Pain in the butt but will do until something like this can be fixed.

Its the WCS, I created a new WCS where I wanted the origin to come from. Which the way I brought the part in was in the state it should be for 2nd Op. So I flipped the part upside down and created a new WCS on the bottom left hand corner of the stock. But its like the blend tool path is still trying to reference the TOP WCS. Its driving me nuts. I think this is a direct software issue, so should I bother calling our reseller or go directly to CNC Software?

Ok here is the problem I am having. I brought in my part into Mastercam, created a new WCS where I want the offset to be. Created the lines to control the blend tool path. When I created the tool path the result is pictured below.

Thanks Robert that worked, it was a little more complicated than I wanted due to the part being at a slight angle as well. Where do we make a request at for features in Mastercam as it would be nice for the verify options for stock to be just like the stock setup.

Mastercam X4 Here is the problem we are having. We create our regular stock in one file cut it in verify and save the cut stock as a stl file. We then put that stock in another file(second op file) using the stock setup. Mastercam shows the model in the correct position but when we use verify the stock shows up in a different position. Apparently the stock origin for the stl file is tied directly to the Origin of the wcs used for the toolpaths themselves. So when we use verify it puts the origin of our stl file on the origin of our toolpaths, which puts the stl model in the wrong place. The origin used for the toolpaths in the first op file is the corner of the stock. While the origin used for the toolpaths in the second op file is the corner of the fixture used for holding the rough cut part from the first op. Any help is greatly appreciated. Jon

Ahh ok we are still waiting for our reseller to get back with us on the quote for that specific post. Hopefully we will get a post before maintenance is finished going through the machine.

no problems with them doing it, John, personally I don't think any of us engineers here should be trying to tweak it anyways as none of us have had any classes on posts. Although it is something I would like to learn, just don't have the time to do so at the moment.

Me either, could be them being a little upset because we are asking for a specific post from someone other than them. The only two posts that are on this site, that I know of, are the mpmaster and mplmaster, which are non specific as far as I can tell.

One final question, our reseller said that the post we get from In house is locked and if we need any changes made we will have to go through In house. Can we customize it here or will we have to go back to In house for tweaking?

Thanks Greg, I am looking forward to see it cut. We have quite a few Titanium and Stainless Steel parts that I would like to see how aggressive we could get and how much time we can shave. I will tell the engineer who is handling this to ask for that post.

^^ Should say first Okuma mill, we have many fadals and 4 Makino's.

The MPMaster Okuma post works as is for this particular machine? Without modification? The only thing that scares me is that we have no experience with the Okuma mills we have a few Okuma lathes but this is our first mill.

We just bought one, we don't have a post for it yet but we have talked to our reseller about it. I was just wondering if anyone has this machine, are you using a specific post or is there a generic one that works? We really have no idea what the programs for this type of machine look like and our reseller is asking about a program so they can set up a post for us. Thanks Jon

Sounds like something I need to check on then. Thanks

Its a Makino A51b. Professional 5 controls. I'm not sure if has dynamic compensation or if we even have it turned on if it does.

That is what I was afraid of, we use rotary zero and absolute programming. Just wish there was a way to mass modify all the parameters(like adding .300" to all retracts, feed plane, top of stock and depth).

Well I tried that and it didn't really seem to help the z, when I program I use absolute instead of incremental so I am not sure if that would change anything or not.

We've been running some parts on regular vise jaws, when we recently decided to use a different set of vise jaws to help prevent pulling the part out. The new jaws move the part over in the x direction around .500" and up in the z direction around .300". How can I change this in mastercam and repost without having to reprogram everything? This can't be done with fixture offsets alone as there are 4 axis tool paths. Using X3 MU1. Thanks Jon