Resolution of Circular Interpolation (G2-G3)

Greeting,

When executing the G-code and the controller evaluates a G2 or G3 move what resolution does it calculate?

If I program with G1 a circle has many facets, depending on the number of points generated by the software.

LinuxCNC does seem to generate a nice smooth hole with the G2/G3 command.

Does G64 P 0.xxx have an influence?

Cheers,

Dave

The trajectory planner normally runs at the servo thread rate (nominally 1 ms)
so the corners of the facets would be a 1 ms apart in time.

The number of facets on a circle would be 2*Pi*R/P*V

R circle radius
P servo period (normally 0.001 seconds)
V velocity in machine units per second

As a simple example, if a circle is completed in 1 second, it would have 1000 facets
with a 1 ms servo thread

The above assumes the motion system moves at the programmed speeds between
servo thread invocations

G64 will not affect G2 or G3 but will affect blending to connected arcs or lines

Pcw has made a perfect comment.

To adress the differnce between the pc-monitor and the machine output, i have a little comment.
LinuxCNC does seem to generate a nice smooth hole with the G2/G3 command.

What you actual see on the screen is just the arc opengl resolution. This differs from the linuxcnc arc interpolation at runtime.

Most of time a nice opengl curve has about a max of 50-100 lines (this is coded as linestrip or lineloop), if you
have more segments, the pc will become slow when having 1000 arcs x segments to render.

You describe the trajectory planer as if its like a bitmapped image. Its not like that. Its more like a vector based image where a drawing primitive traces a path. It does not move to a location every millisecond, it follows a path and you can only sample its position every millisecond per the servo thread.

Step generation is a lot faster than the servo thread either in hardware on on the base thread (if using a parallel port)

If you wish to explore arc behaviour, I have an experimental branch on my git hub that allows you to explore the arc radisu and a lot of other data. Go to this pull request that explains what it is doing and follow the link to my repo
github.com/LinuxCNC/linuxcnc/pull/900

Its still a bit of a work in progress and I have not got back to it to finish of some revisions.

You describe the trajectory planer as if its like a bitmapped image. Its not like that. Its more like a vector based image where a drawing primitive traces a path. It does not move to a location every millisecond, it follows a path and you can only sample its position every millisecond per the servo thread.

Its definitely not like a bitmapped image (as that is limited in spacial resolution) but the TP is limited
in temporal resolution because many of its calculations are done every servo thread. That is, it does not
provide more than one waypoint per servo thread invocation. At one time the TPs calculation rate could
be specified separately (normally slower for low powered CPUs) but AFAIK this is no longer possible

PCW wrote:

At one time the TPs calculation rate could
be specified separately (normally slower for low powered CPUs) but AFAIK this is no longer possible

It would be useful if the TP was modular like TASK and IO. I think thats supported in Machine Kit but I don't think Linuxcnc allows that. I've yet to dive into the TP code to really find out but it is on the agenda. It would be nice to be able to be able to create a custom TP for certain classes of machines (like plasma cutters)

tommylight wrote:

rodw wrote:

It would be nice to be able to be able to create a custom TP for certain classes of machines (like plasma cutters)

Radius's, circles and corners slow down ?

No I think I've got what I need there. I just said something in another post.
But I was thinking more about S curve/jerk limited acceleration profile that ignored any spindle synchronisation stuff and only worked in the XY plane. I've got some ideas but it will be a while before I get into it!