the gcode g2-g3 format problem.

Hi,

Currently working to use a interpreter like sai for 3d gcode.
In general i alway's end up with the same problem. Let your thoughts shine over this.

For example a g2 (cw) or g3 (ccw) arc, defined as usual :

• startpoint : {0,0,0}
• centerpoint : {50,0,0} (retrieved by i,j,k values)
• endpoint : {100,0,0}

Above G2, G3 then only works if the plane is in on of these :G17 - XY (default), G18 - ZX, G19 - YZ.

The above coordinates are colinair, this is in fact a math problem where the 3d plane cannot be calculated or defined.
The plane can be anywhere between 2*M_PI,
But that is strange, because it's a arc. So the gcode misses some data here.

For xyz gantry low level application's nobody cares about planes etc.Personally i think it's better to define a arc in gcode format as follows :

• startpoint : {0,0,0}
• waypoint : {50,50,0}
• endpoint : {100,0,0}

In this way the arc is defined in 3d. As a result of that, G17, G18, G19, G2, G3, are obsolete.

It's also that the arc calculation becomes 3d, instead of 2d using vector formula's, wich are quite compact and easy to handle :
github.com/grotius-cnc/arc_points_3d/blob/main/arcpoints.cpp

In the end, what is the best way to go?
I think the arc with waypoint describes it all. On top off that the gcode abc can be used to drive the euler angles if the machine
is a robot etc.













 

I'm not helping here but the TP only has one procedure which works in the XY plane. Axes are substituted when the procedure is called in the XZ and YZ planes. 

Trying to wrap my head around this...

How does defining the start, waypoint, and end define the radius (or curvature?) of the 3D arc?  Is it because the G2-ish (not G2 nor G3) is always an arc with those three point tangent to the arc?

So a 3D arc could be defined by:

G2-ish X0Y0Z0, X1Y0.5Z0.5, X2Y0Z0 Fnnn

Yes?  (forgive me if the values are off, but trying to plot a 3D arc in my head is fussy)

So how is a parabola defined?

Next thing I'm thinking is I don't want to pay for another post-processor!

Hi,

Yes, this is ok to define a 3d arc :
G2-ish X0Y0Z0, X1Y0.5Z0.5, X2Y0Z0 Fnnn

So how is a parabola defined?
en.wikipedia.org/wiki/Parabola


Then Point F & A are important. You need the power of the parabola curve, like : y = x2.
If you got one extra reference point like B,C,D or E,  (prefferred D) that's enough to define a 3d parabola.

Next thing I'm thinking is I don't want to pay for another post-processor!
Yes, i understand.

Below is a example of a 3d arc, that is a problem for cnc programs.

My personal opinion is that such arc moves should be possible for a cnc program.  Robot controllers
are used to interprete such moves.

The current way is that the cam program will create a linestrip, so it loses it's arc format anyway.
A mdi move is currently only possible if kinematic component will rotate the workplane first.

example :

https://github.com/grotius-cnc/dump/blob/main/screen.jpg?raw=true

Thank you.

This seems rather clever as the direction doesn't need to be defined with G2/G3, right?  Just one G command and the waypoint ensures the direction is always correct.

And this system would have worked years ago when controls weren't capable of 3-axis coordinated moves.  Wonder why the originators of G-code went with IJK (or R) instead of waypoints?

Trying to think if this scheme has complications related to cutter comp or lathe tool path generation (tip tangency).  Need more coffee.

Hi,

This is a old video doing such moves, with euler's poses on top :
user-images.githubusercontent.com/448801...814-1199550dd265.mp4

Wonder why the originators of G-code went with IJK (or R) instead of waypoints?
I don't know. For standard xyz, you don't need it.

You can offcourse expand the gcode language, but then the question is, will it be adapted or accepted by others.
I think when creating a gcode interpreter, the gcode interpreter can just read the new GXX code that defines the 3d arc.

This seems rather clever as the direction doesn't need to be defined with G2/G3, right? 
Yes, for me the best way of defining a 2d or 3d arc is using a waypoint. It's failsafe and no data get's lost, like the arc plane.

With a start point (current position) end-point (XYZ) and centre (IJK) the plane of the arc is well determined,
This is true, but ... so far i know lcnc uses it to create spirals instead of describing 3d arc's.
For g2,g3, the startpoint z=0, the K=1, the endpoint z=2. Seen from top plane will create a spiral.
Correct me if i am wrong.

as it is ambiguous which direction the plane normal points. (There may be a standard for this?)
I don't know if there is a standard for this. If you know the normal axis, it's ok.

Hi,

G2.1 & G3.1 sounds ok to me.

Three points define a plane, but the plane normal can point in either of two directions.
Yes, but that's no problem to define a 3d arc.

If you have arc start, way & endpoint, you can calculate the centerpoint,
and the center axis (neutral). Arc angle is then calculated, this needs a tiny if-else if output angle is negative. (not signed).

The opencascade lib has also 3d arc's, but they are computed quite complex.

This recent code solves a 3 point 3d arc, output is tested ok in opencascade :
github.com/grotius-cnc/arc_points_3d/blob/main/arcpoints.cpp