Circular interpolation behavior

How do most reprap users expect G02 and G03 to behave?

Most of the G-code I have written, for the old Dos program I have requires the use of G17,G18 or G19 to select which plane to draw the circle in. This program also does not allow the circle to cross quadrants. G90/91 also affect the I and J offsets.

I took a look at the existing firmware, which implements these with floating point, root and trig tables. Triff's 20100204 code does not implement these.

A search through my old textbooks and online documentation indicates that the behavior of these codes is highly machine dependent. I ran some of my old code on a KCam3 simulator, and there were some significant differences between how incremental and absolute mode handled the I, and J word offsets.

Given how many variations on drawing circles with Cartesian coordinates, I am quite surprised this has not been done. This site for example has a rather promising algorithm which does away with the square roots.

I had been considering using cubic to draw the arcs, like in postscript. This results in vectors which change in size and do not keep the feed rate constant. The cubic method also requires setting up and calculating quite a few tables.

The STL object format stores a set of triangles. Since these convert to a set of straight lines when sliced, we don't really get arcs from them. That's why I haven't even tried to implement arc code.

If you want me to, and find me some fast integer approximations for arcs, I can put it in

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware

Since we're starting from STL files, in which curves are approximated by a series of flat triangles, we never use curves, just a series of short straight lines.

Curves or circles would be better, yes, but you're going to need a better file format than STL to work from then. And that's a whole new can of worms.

But it would be great. One of the problems I'm having right now is that lots of short gcodes segments around curved holes causes my bot to slow down, and deposit too much plastic.

Wade

Triffid_Hunter - take a look at the code examples in the comp136 link in the root post. Not exactly integer, but could be done with fixed point.
-julie

circles can be done Bresenham style. No fixed point is necessary. Only trick point is determining start and stop positions for arcs.

The site referenced above seems to be a somewhat more inefficient than the standard midpoint circle algorithm, which mimics Bresenham's line algorithm applied to circles; and in fact, both of these gave me the basis for the stepwise splines, polynomial, and other curve following computations that I use that change the formula to a simple sequence of sums to compute (which means it can be performed even on CPU's for which multiply is very expensive or not available.)

Edited 1 time(s). Last edit at 02/11/2010 01:52PM by BeagleFury.

Thanks, I was looking for that algorithm, which I have used in the past. I forgot the name. Interesting that none of my search terms found something so obvious.

Now the trick would be to find the spline curve Y for every step on the X axis. A non trivial solution, as the curve can cross over itself, and make almost infinitely large loops.

I will take another look at your spline curve blog entry.

-julie

Yeah, the spline curve algorithm I use uses an arbitrary 't' or time dimension, rather than stepping along one or the other axis. On the negative, this means that you don't always get one step per tick on one axis. On the positive, this allows you to get built in acceleration and velocity on all 5D axies automatically as you follow a curve.

My task is an M18x1, through 12mm. Can anyone give me the .txt? On a Fanuc M0.
(My experience here is poor.)