G03 should be G02 & vice-versa

[K2csq7]

Hi Everyone,

Had some lathe code with mixed up G02's and G03's. Operations are clean when posted, but the code comes out bad. Regenerating the CLEAN operations makes the code come out correct. Anyone see this before? I don't even know where to start looking? Gonna make a zip to go and send it into QC...

[Goldorak]

does your tool plane get inverted in some operation ?

[K2csq7]

No planes here, just top top...(lathe VTL)

[K2csq7]

Here is a zip to go if anyone wants to take a look. Extract the files, select operations # 60, 61, & 62, post just those 3...

Now regen those 3 CLEAN ops and repost. You will see the g02's & g03's get swapped

[Dtm]

Here is a zip to go if anyone wants to take a look. Extract the files, select operations # 60, 61, & 62, post just those 3...

Now regen those 3 CLEAN ops and repost. You will see the g02's & g03's get swapped

 

I'm at home now, so I can't look at your file, but right click the tool, and in the tool set-up make sure the turret is set to top. I had this problem one time.

[Mr. Wizzard]

I've had problems where the default turret would switch from lower to upper and the same code would be reversed as you described. However, I had to go in to each op and select lower turret to get the code output correctly. If yours switches without changing any parameters, just by regen-ing, then that is way weird.....

[K2csq7]

Way weird.....

[K2csq7]

Here is what I found, thanks to CNC for the help.

The op should have been marked dirty (in my opinion) but wasn't.

The lturret$ variable was showing a bad number in the NCI file, once the CLEAN operation was regenerated, the variable showed correctly in the NCI file.

I use a self-modified MPlmaster post.

The post was using the bad lturret$ variable which caused the switching of my G02's & G03's. Once the CLEAN op was regenerated, the G02's & G03's came out correct.

CNC says that variable should not be used by the post.... or something like that. The NCI file was showing the correct gcode (2 or 3) for the arc moves all along.

Therefore (in CNC's opinion) the post is the problem, not Mcam.

In my opinion, if the NCI comes out different after regeneration, then the operation should have been marked dirty.

Since it is an inhouse post, CNC won't look at it. (<<<<<<<<<<can't blame 'em)

I have called inhouse before, while you wait to speak to someone the automated recording tells you that you will have to pay to talk to someone, so I hung up.(<<<<<<<<<<can't blame 'em)

My company has an unwritten rule that if you can't fix it and need to pay for help, you should just try harder !

So I debugged & searched until I found this line in the post...

  	lathtype = lturret$ + spindle_no$ * two

I commented out that line and all seems good for the time being. (i.e. the post is not using that variable)

 

I've had problems where the default turret would switch from lower to upper and the same code would be reversed as you described. However, I had to go in to each op and select lower turret to get the code output correctly. If yours switches without changing any parameters, just by regen-ing, then that is way weird.....

Mr. Wizzard,

Inside the tool definition, left turret was checked all along, but the lturret$ variable in the NCI showed right turret, until the operations were regenerated.

 

Please do not interpret this the wrong way, The gentleman at CNC was nothing but professional and helpful. And I did not even try to contact inhouse about the post because I am well aware the posts are "use at your own risk", and I got it for FREE so I am still a happy guy.

[Surface]

An excellent post to bring closure to the problem.

[Mr. Wizzard]

Very good info, Keith. Thanks for posting what you found out.

[Paul Decelles]

It is not that lturret$ should not be used in the post, it is used in most of our lathe posts and is an important variable for proper processing when more than one turret/spindle needs to be handled.

The problem you ran into is that the value in the NCI was incorrect. Your machine has a single (right) turret and is limited to a single axis combination which defines the value that is supposed to be written into the NCI (and subsequently loaded into lturret$). What you ran into occured when you redefined the tool as being mounted in the left turret (which does not exist) after the operation had been created which then (and here is the bug) incorrectly wrote the turret info to the NCI. Regenning the operation after this re-implements the axis combination setting which in turn corrects the value in the NCI (which is why you get proper output in the end).

Apparently the bug has been found and corrected for X6, I'll make sure to check on it to ensure it is addressed before release.

[K2csq7]

Thanks Paul....

What you ran into occured when you redefined the tool as being mounted in the left turret (which does not exist) after the operation had been created

Actually (just FYI) if you will be digging into this and I don't know if it makes a difference, but the tool was created and defined as a left turret tool (which I don't know if I should be doing) inside the tool manager before the operations were created. I dug back in my backup files and found exactly were the lturret$ got the bad #. In the tool manager before the ops were created I had the same tool in there as a right turret tool... copied and pasted that tool and gave it the left turret designation. Then created the operations and noticed that the offset # was correct, but the tool # was not what I wanted. When I changed the tool # is when the problem occurred.

(P.S. I have that file if you want it.)

 

Also here is some clarification as to what exactly CNC was saying to me about the lturret$ variable should not be used by the post.... my bad

Just to clear things up a bit, when I said that the lturret$ variable should not be used in the post, I explicitly meant your post, because you only have one turret.

 

I don’t want other people on the forum thinking that they do not need lturret$ when they actually do.

 

Machines with multiple turrets do in fact need the lturret$ variable.

 

Should I have all my tools defined as "right turret"?

[Rocketmachinist]

I had a similar problem one time with my lathe post but I think I fixed the problem by having the post output in arcs instead of I's and J's. I was doing a part that had an ellipse on the front of it and when I put it into the controller it called out an over travel alarm. I changed it to arc moves and it fixed my problem.

[Guest SAIPEM]

I had a similar problem one time with my lathe post but I think I fixed the problem by having the post output in arcs instead of I's and J's. I was doing a part that had an ellipse on the front of it and when I put it into the controller it called out an over travel alarm. I changed it to arc moves and it fixed my problem.

 

Ummm.... G02 & G03 with I&J are arcs.

 

I think you mean using R-words. ;-)

 

In any event Paul D. has already acknowledged the issue is corrected for X6.

[Bluechips]

Mine was doing the same thing so I went into the post and found were that was and changed around the post then it worked fine. It took a while to find though.

[K2csq7]