Makes sense. Changed c9k to a different value and it did not affect the translated cycle, still posted out R9999. Another topic suggested that it could just be a bug with translated cycles. Thanks.

Could these values also affect drill cycle clearance planes? When translating/transforming drill toolpaths I would get z9999. and R9999. values in the translated drill cycles. Just curious, as that c9k value looks like it may be affecting it.

Correct. I only changed it within the chipbreak postblock. For G83 cycles I tested it and it still works, assigning IJK values to peck1$ and peck2$. Thanks, Martin!

-Update- I was able to make it work by re-assigning the address for peck1$ within the pchpbrk$ postblock. Here is my fix: pchpbrk$ #Canned Chip Break Cycle pdrlcommonb pcan1, pbld, n$, *sgdrlref, *sgdrill, pdrlxy, pfzout, pcout, pindexdrl, prdrlout, result = nwadrs(strq,peck1$), *peck1$, *feed, strcantext, e$ pcom_movea If this is not proper form or if anyone has a better way to do this please let me know. Thanks.

Good Morning I'm trying to edit our Haas post to use a Q instead of an I when posting out G73 drill cycles. It uses I,J,K values in G83, but when it posts out a G73 cycle it still uses the "I" address, with no J or K, and this alarms out the machine. Currently, this is where I am looking at the cycles: if haas, [ result = nwadrs(stri,peck1$) result = nwadrs(strj,peck2$) result = nwadrs(strk,peckclr$) ] pbld, n$, sgfeed, e$prdrlout #R drill position if absinc$ = zero, refht_a, !refht_i else, refht_i, !refht_apdrlxy #Drill XY coordinates if force_dpts, pfxout, pfyout else, pxout, pyoutpdrill$ #Canned Drill Cycle pdrlcommonb pcan1, pbld, n$, *sgdrlref, *sgdrill, pdrlxy, pfzout, pcout, pindexdrl, prdrlout, [if dwell$, *dwell$], *feed, strcantext, e$ pcom_moveappeck$ #Canned Peck Drill Cycle pdrlcommonb pcan1, pbld, n$, *sgdrlref, *sgdrill, pdrlxy, pfzout, pcout, pindexdrl, prdrlout, *peck1$, [if haas, *peck2$, *peckclr$], *feed, strcantext, e$ pcom_movea pchpbrk$ #Canned Chip Break Cycle pdrlcommonb pcan1, pbld, n$, *sgdrlref, *sgdrill, pdrlxy, pfzout, pcout, pindexdrl, prdrlout, *peck1$, *feed, strcantext, e$ pcom_movea I can see where it assigns the IJK addresses to the peck1$ and peck2$ variables at the top. My thought would be to have some logic where if it sees it's posting G73, to re-assign "Q" to peck1$ before, or possibly just re-assign the "Q" within the pchpbrk$ postblock. I'm still really green with all of this, having only been going through the MP Guide for a day or so. Any help is appreciated! - Frank

I do some wire stuff in 2017 occasionally, so I think I understand what you're trying to do with your thread points. What you can do is go to create your thread point geometry and hold down shift, then click on a line endpoint (or any point you would like to reference). This brings up the dynamic gnomon and you can then drag (or type in an exact distance) where you want to move your thread point, from that first point you're referencing. Hope this makes sense.

That makes sense. Thanks.

We have a Haas VF-5SS that we've been using for surface finishing parts. Do you use the control's smoothing settings at all? It's controlled by either the parameter setting (Setting 191) or the G187 P1, 2, or 3 in the program. We didn't notice much difference with it, I'm curious if anyone else has had success with it. Also, do you know if Haas has any high speed look ahead options for their controls?

This is the conclusion I have come to. We have many different makes of machines at our shop, mostly Fanuc controls, but we'll probably just have to experiment. A lot of parts had been programmed with Surfcam years ago and now that our newer parts are being programmed in Mastercam we're trying to get the most out the software. However, the machine will be ultimately what dictates what we can do. Thanks everyone for the input.

Thank you, that is what we strive for.

Negative, I work for Mega Arms in Centralia. Started as a button pusher almost 6 years ago and ended up in programming.

I understand that. I guess I wasn't sure how powerful the filter/smoothing settings were in Mastercam and maybe we just weren't using them to their full potential. I understand that there are limitations in each variable of the process (the software, the machine, etc.) but I didn't know if we were handicapping ourselves by not knowing how to best use those settings. I appreciate the help and, after seeing your signature, I thought you'd appreciate knowing we machine AR and other gun components!

Yes, and I do this a lot with 2D high speed toolpaths to really simplify the code. They're all newer machines, Fanuc Robodrill that is only a few years old, newer Haas VF5, brand new Okuma horizontal, etc. And this is probably where we don't completely understand the math going on in the background with the tolerance settings. We did end up getting some much smoother toolpaths going with 50/50 on the cut tolerance and arc filter/smoothing. We basically just adjusted the settings until the path became smoother than before. Some surfaces did better with 50/50 and other looked better with bias all the way to smoothing. The paths looked decent with the default .0005" tolerance and, by trial and error, we found .0025" to be a sweet spot. Is there a tolerance that you would recommend? The surfaces we're driving are all almost strictly cosmetic and, as such, we just need them to look as smooth as possible without insanely small stepovers. I hope I'm not missing your point, just trying to understand as much about this topic as possible from the more experienced users. You guys have a wealth of knowledge and experience and I'm just trying to understand as much as I can. Thanks again.

Hi everyone, At my shop we do a lot of high speed surface finishing on aluminum parts and we're struggling with the arc filter/tolerance fields to get the smoothest possible toolpath. What I would like to know is what settings other programmers have found success with? Right now we've figured out kind of a sweet spot with our total tolerance at .0025", arc filtering on and the sliders biased between 5-50% cut tolerance, and the right slider all the way to "smoothing". Are we not using this properly? We understand arc filtering for 2D high speed toolpaths but the surface finish with paths like scallop, blend, etc. are what's giving us the most trouble. I've uploaded a screen cap of what our typical settings have looked like. If anyone could offer better insight as to how these settings affect surface toolpaths it would really help out a lot. Our local dealer and most Mastercam applications guys haven't been much help to us. Thanks in advance.

Thanks Ron. I'm trying to get an answer from the applications guys as Mitsubishi right now. Talking to my boss, he said that it could be an option for the control so we'll see what I find out. Thanks for the help!

Hey everyone, I'm new to my programming position here at work but I've been working with CNC mills for the past 5 years and am fairly good with G-Code and all that good stuff. We just bought an EDM at work, a Mitsubishi MV2400S, and I've been working on the programming for our parts. Anyways, with our mills we typically program only the first part on the fixtures and use logic to move the program to the second, third, etc, parts. I'm trying to do the same with our EDM to keep the programming somewhat similar to the mills but when I load the program into the control it gives me a P32 programming error. Does anyone have experience with Mitsubishi EDM programming and code that could help me? Is there anything special about formatting logic with Mitsubishi controls? Any help would be greatly appreciated! -Frank