circle will be upside down on G18 (XZ) plane

[anagy]

I’m relatively new to the option file generator (1 year). I’ve been using creo (pro engineer) for 25 years.

I’m using #14 fadal VMC15 profile. I found that for a G18 (X-Z) plane certain G2 and G3 gcodes are mixed up when I export the tool paths.

The rest of the gcode maintain the proper coordinate system direction. If I test the gcode with https://ncviewer.com/ the circles will show up upside down

So I’m looking for a setting that will swap G3 output for G2 output eventually switching the direction of the Y axis in the XZ plane (G18)

I tried checking in/off the CIRCLE/cmd translation – among others with no avail.

Any help/suggestion is appreciated. thank you!

[KenFarley]

When you say your arc paths are "upside down" do you mean it's giving you the opposite of what you expect, like it's trying to cut 270 degrees instead of the 90 you need to go around a corner?

Are you defining your G02/G03 paths using vectors (I, J, K) or a radius? If the radius, I'd suggest switching to the vector nomenclature, it takes a lot of the misinterpretation out of the process.

If it's not such a simple thing as that, I'd have to check what is the correct normal  direction for G02 versus G03 and check out the math on the paths to see that they concur. There might be an option to ensure the post processor handles things right, I just haven't had to deal with it in the past. Sometimes it's the program checking software that is doing things strangely. I recall having troubles with Camtasia in the long ago when I'd use it to check code. I'd get some funny looking things sometimes that weren't my NC code's fault.

[anagy]

Ken. thanks for the suggestions. Here is the part of the code in question: 

N64 G18

N66 G2 X5.15 Z-5.65 I5.15 K0.

N68 G1 Z2.

N70 G0 X-5.15

N72 G1 Z-7.45 F100.

the picture attached show the difference, the creo translator should output G2 moves but it outputs G3 moves. 

for the G18 - XZ plane it outputs I and K correctly. I have an old fryer cnc mill running anilam 5500M that uses old school g code. 

[KenFarley]

Have you messed about with the settings in the Option File Generator?

In the screenshot included here (I hope) I've circled the likely culprits. Hopefully if you change this it doesn't mess up any other code you generate. If you're getting consistently wrong output you might want to try toggling the one that affects G18 (the X-Z one?) and see if it fixes the problem.

[anagy]

thank you Ken. I already tried the bottom option (G18-ZX) with no avail. I'll give a try to the others. 

[anagy · Accepted solution]

Ken. thanks again for the suggestion. I tried the middle option "circular move from +X to +Z is counterclockwise" and it worked. it'll swap the G3 move to a G2 move in the G18 (X-Z) plane. the other planes (G17 & G19) are working fine. I wonder why this is an outlier for the old school anilam system. 

[KenFarley]

It's one of the many reasons there's a unique post-processor for each type of machine, sometimes different models from the same manufacturer. You should see how much fun it is to get 4th axis angles to be output in the proper fashion for a particular rotary table.

It's also another classic example of me seeing those options and thinking "I wonder what those are for", then later finding out they can be a lifesaver.