Is MasterCam ever going to fix the G76 canned threading cycle?

We don't have the very latest update, but aren't too far behind. Threading cycles haven't worked correctly in many years. I believe it was back in V9 that our reseller tried to work with MasterCam people to get the problem corrected, but here it is years later and still with the same problem. I get the impression lathe is a second class citizen as far as MC is concerned.

Anyone programming lathes knows exactly what I am talking about. Too bad MasterCam developers don't. Sorry if I come off a bit harsh, but 10 years (a guess) with the same issue can do that to you.

What is the issue?

Try using a G76 to thread and re-thread. The only way the program will come out right is if you use a 0 degree compound infeed. In the initial thread operation, set the first pass to something like .01 with a 29 degree compound infeed and a start position of Z.3. Copy this operation after re-turning/re-boring thread. In the re-thread operation, set MC to make one pass. Obviously this requires changing the Q and R (if used) outputs and any spring passes used as well.

Post and look at the Z-start positions. They will not be the same. Ergo a messed up thread. Only the re-thread will have Z.3. MC performs math on the first Z.3 and adds a value to it based on thread height and compound infeed. Sorry, but this is wrong. No math is needed on the Z.3. The Fanuc control will do the math. I know all variables we can put in MC have a number assigned to it for use with MC. Simply take the .3 assigned to this value and output it to the G-code program. Done.

Math should not be done on the Z-start position for a G76 canned cycle. Only on longhand output. As it is we have to subtract the extra value added to Z.3 to get the proper G-code output.

Not only that, but there is often a G-code output that I don't like. It will look something like this.

X1.03Z.3008
Z.3
G76.......
G76.....

All I want is

X1.03Z.3

I don't want or need that .0008 rapid move.

Well.....that didn't go very far. :rolleyes:

Have you reported the problem to QC?

No. Wouldn't know how. As I said in my first post, I reported it to our reseller. They communicated with the powers that be. Nothing ever got done about the problem.

There have been improvements in the lathe section. Also a step backwards, AFAIC. I used to be able to use Extend (on an angled line) to make the X-value be the same as material size when using Rough in the Canned Cycles. Now it withdraws on a 90 degree after the angled line. Extend the angled line too far and the final X-value is greater than the material size. And this is before the X-value of the angle line reaches stock size.....because MC wants to withdraw on that 90 degree. I never bothered to figure out what the set minimum default amount of the 90 degree withdrawal is. If I wanted a 90 degree withdrawal I would define a vertical line after extending the angled line the desired amount. As it is I modify the programs after posting.

So how long ago did you talk to your dealer about this. this a post issues?

G76 stinks anyhow

G92 FTW

Quote:

---

Originally Posted by generaldisarray

G76 stinks anyhow

G92 FTW

---

No thanks. G76 is much more versatile. If I need to control depth of each pass, I will use G32 so I can also use a compound infeed.....unless I don't want one, then G92 is okay. I'm thinking you don't understand how to use G76.

Quote:

---

Originally Posted by cadcam

So how long ago did you talk to your dealer about this. this a post issues?

---

Version 9 if I remember correctly. Although I've used MasterCam since at least V6, I only used it before V9 to save myself some trig calculations. Otherwise I manually programmed.

I use something like 9 different posts. Every one puts out the same error. Some I simply made small changes in the posts so it would output the correct format for different lathes. I could try a default post to see if the G76 output is the same.

Honestly this sounds more like a post issue. Can you share a zip2go?

Quote:

---

Originally Posted by your-cnc-specialist

Honestly this sounds more like a post issue. Can you share a zip2go?

---

I can try whenever I remember and have the time while at work. I am the sole programmer for 27 lathes. We have lost 5 people since a year ago last December (4 since this past January) and another has been out on disability with no time frame for coming back to work. None have been replaced. Since much of our work is repeat, I have been on the floor a lot setting up lathes. Needless to say I don't get many free minutes.

If it is a post problem, then it is a problem with every post we have...and we have a fair number of posts.

Hi. I think I know who you are if you work in NJ. PM me a zip to go that includes the post. I think I can take care of this and then you can blast it out to all other posts.
I agree with you, it should not calculate a new starting Z point if the X value of the thread is at the finishing point. It needs to just use the distance on the first page + the acceleration distance on the second page.

Not sure if it has been fixed on latest posts or not but I can check when I see yours. We can just take those values out and dump them in the code, and not use the ones sent by Mastercam to the Post. That should work.