Coordinate System Rotation And Planes problem!

[amir_nop]

Hi guys!
I wrote a macro using coordinate system rotation (g68) and planes (g17,18,19) but I get this error:
Illegal Plane Selected!

Can anyone help me?

#1=0;

G01 X16 Y0;
Z-10;
WHILE[#1 LE 90] DO1;
G18;
G03 X36 Z-10 R10;
G02 X16 R10;
G17;
G01 Z1;
#1 = #1+1;
G68 X0 Y0 R#1;
G01 X16 Y0;
Z-10;
END1;

Similar Threads:

• Coordinate rotation problem on MORI SEIKI TV40 MSC-802m
• Need Help!- G68 Coordinate system rotation.
• Need Help!- Coordinate System Rotation G & L NumeriPath 8000B
• Need Help!- G68.1 Coordinate System Rotation Help
• G68 Coordinate Rotation System

[RCaffin]

Exactly what are you trying to do here??????
A pic might help.
Cheers
Roger

[amir_nop]

1/4 of this shape. (0 to 90 degrees)

[RCaffin]

Blimey!
OK, guessing (because I do not know your controller): the rotation command g68 usually only works in the XY plane. Having issued a g68 command, trying to change the plane away from the XY one is illegal. You will have to program it a different way.

Cheers
Roger

[amir_nop]

the control is Fanuc Oi-MB, and i'm changing plane then use g68 on XY.
Step 1: G02/03 on XZ plane
Step 2: Change Plane to XY
Step 3: Rotate coordinate system

Does this mean that i am rotating XZ plane!??

[postwrtr]

Where you from Amir? What country do you live in?

[christinandavid]

Does your machine have the option to arc in three axes? If it does, you may need to add another argument to the G2/G3 to define the midpoint.

If not, the best way may be to produce the shape in G1 line segments instead of arcs. Just use two more while/do loops inside the existing loop, to travel back and forth.

Removing the arcs also means you won't have to change the working plane.

DP

[amir_nop]

Where you from Amir? What country do you live in?

Iran, Why?

[amir_nop]

Does your machine have the option to arc in three axes? If it does, you may need to add another argument to the G2/G3 to define the midpoint.

If not, the best way may be to produce the shape in G1 line segments instead of arcs. Just use two more while/do loops inside the existing loop, to travel back and forth.

Removing the arcs also means you won't have to change the working plane.

DP

Thank you for your answer, but i have a few questions,
How do I know that my machine has the option to arc in three axes?
and logically my code doesn't use three axes unless the machine conclude itself that our main purpose is moving around three axes.
look, I move into XZ plane, then change plane, move on the XY plane, not three axes in a same time. right?

and about dividing arcs to straight lines yes I could do that but not a good idea, I need clean code. that is what satsfies me

[RCaffin]

How do I know that my machine has the option to arc in three axes?
You don't. I suggest you assume it can NOT unless you find an explicit statement that it can. I don't think NIST g-code allows it, and it would be hell for the older controllers to implement. Read the manual.

look, I move into XZ plane, then change plane, move on the XY plane, not three axes in a same time. right?
But the controlled point WILL be moving on all 3 axes. Anyhow, I am not going to continue arguing the point.

Once the machine has executed a single g68 command (without a matching g69), then the machine knows it has entered into coordinate rotation. Once it has entered into coordinate rotation, a change of work plane is not permitted. That is what the error message is trying to tell you.

Do any controllers permit a change of work plane once you have entered into coordinate rotation? I don't know, but I don't know all controllers. I do know the maths would be fairly complex, and I tghink that you would need a PC-based controller for this, not an older hardware-based unit.

Cheers
Roger

[christinandavid]

Thank you for your answer, but i have a few questions,
How do I know that my machine has the option to arc in three axes?
and logically my code doesn't use three axes unless the machine conclude itself that our main purpose is moving around three axes.
look, I move into XZ plane, then change plane, move on the XY plane, not three axes in a same time. right?

and about dividing arcs to straight lines yes I could do that but not a good idea, I need clean code. that is what satsfies me

I assume program will run without error if the G68 is removed?

DP

[amir_nop]

I assume program will run without error if the G68 is removed?

DP

Yes it works well without G68.
Also works by removing G18.

[RCaffin]

Well, there you go. You can NOT mix G68 and G18.
Cheers
Roger

[amir_nop]

How do I know that my machine has the option to arc in three axes?
look, I move into XZ plane, then change plane, move on the XY plane, not three axes in a same time. right?
But the controlled point WILL be moving on all 3 axes. Anyhow, I am not going to continue arguing the point.

Isn't this moving on all 3 axes????
The machine does it easily!
What's the difference?

[amir_nop]

Well, there you go. You can NOT mix G68 and G18.
Cheers
Roger

ARE YOU SURE??
or you are just guessing?

[RCaffin]

Yes, the hardware can do it. So can mine.
But the controlling SW (Fanuc, Mach3 or whatever) can NOT do it via G68 and G18. It was too hard for the SW writers.
In effect, you can imagine more than they could write.

Cheers
Roger

[dharmic]

Be interesting to know if kmotion, uccnc or one of the others out there could cope...

[vmax549]

Mach3 cannot do it Mach4 cannot do it UCCNC cannot do it. The problem is tha the controllers cannot do the G18 arc in rotated space. M3 and M4 TRY to do it but starts teh arc in Rotated space BUT it always ends teh Arc in NON rotated space and teh second arc will be totally in NON rotated space.

Could it be made to work SURE it can IF they wanted it to BUT I dought you will ever see it done (;-).

Now that said I believe that Fanuc can do it as it should support a midpoint Value BUT you would have to rewrite teh code and use Arc with IJK not radius values.

(;-) TP

[RCaffin]

Interestingly, the g68 command is not even in the latest NIST standard (RS274/NGC) for g-code. Why - I do not know. It may have existed in a previous version.

Part of the problem is that g-code was being defined starting in the 60s, and the problems of implementing coordinate rotation in the electronics we had back then were beyond imagination. So the mathematical facilities were very limited. Getting that into the latest versrion of the NIST Standard could be a long battle.

There is an alternative to g-code - well, actually, there are quite a few alternatives, mostly unique to a single vendor. In additin, a group of slightly mad enthusiasts are developing STEP-NC as a 'modern equivalent', but the code is mind-bendingly complex, consumes MBytes of space where g-code uses a few kBytes, and cannot be hand-written. Nut cases, definitely, way out of touch from the real world.

Dead end idea. Face reality and use the tools you do have.

Cheers
Roger

[amir_nop]

I tried mid point value ( I J K ), didn't work either.