Bug in gcode firmware?

In my experimenting, I have uncovered what seems to be a bug in the gcode firmware. I think it's actually two bugs.

In inches mode with relative positioning, I issued a command: "G3 I2.5 J0 X0 Y0" Which should inscribe a 5" circle. There are three problems with what my machine actually did:

1. The figure it drew is 2.5", not 5". This is probably a bug in the firmware, and could be fixed somewhere in "process_string.pde"

2. The figure is squished along the diagonals to only ~2.2" on the diagonals. This is probably a problem with the trigonometric functions supplied by the avr library.

3. The motors are extremely jerky, and thus noisy, while drawing that figure. A circle should be a smooth thing to draw. It really needs to pre-calculate the dda stuff and queue it, and use a interrupt routine to process the queue and actually move the motors. I don't know how much of a problem this would be with the line segments of the circle being precalculated on the host. I have noticed that there is a noticable "hitch" in the movment when I give it a command like "G0 Z4.5G0 Z.25". So there would be at least some remaining jerkiness even with the host doing the trig.

May I suggest some variant of [en.wikipedia.org] ? You can test for x=target and y=target for your stopping point as long as you step at least once. That algorithm given is for an eigth of a circle, but should be generalizable. It would also give circles with a resolution down to the step size of the positioning system.

Fixing this probably isn't urgent though. Enrique's gcode generator doesn't use these gcodes right now, though it would result in more accuracy if it could.

It seems unlikely at this point that arc drawing codes will be used for filament deposition. This is due to the fact that STL models are inherently faceted, and an extra line-segments-to-arc processing stage would be required to generate curves. There's no real need to do so right now.

The arc drawing stuff has therefore not been exercised or tested (or even looked at!) by most people, and nor will it be. If you felt like correcting it and submitting a patch though, feel free

I can't remember who submitted the original arc drawing patch, or I suggest you could chat to them.

Ru, I disagree. While it is true that arc drawing codes aren't used right now and certainly don't need to be, I don't think that they're necessarily useless. For example, Enrique's script has a corner-filleting option that would be a natural fit for the arc codes. Implementing them properly would decrease the number of serial messages sent, at the very least.

Also, standards compliance is useful because I can see the gcode firmware being adopted in the wider hobbyist CNC machining community if it works well.

Chris Meighan wrote it, I've used it with pretty good results.

Quote

Ru, I disagree. While it is true that arc drawing codes aren't used right now and certainly don't need to be, I don't think that they're necessarily useless.

Nor do I.

Quote

Enrique's script has a corner-filleting option that would be a natural fit for the arc codes

That's an interesting thought that I hadn't considered. You are of course quite correct.

Quote

Also, standards compliance is useful because I can see the gcode firmware being adopted in the wider hobbyist CNC machining community if it works well.

You think so? It doesn't seem to offer anything like the power and range of features that, say, EMC2 generating stepper pulse trains via a parallel port could offer. SUch a setup is likely to be cheaper too, as you don't need to purchase a controller board, just some opto isolators and a suitable cable.

Our rasterising algorithms (vector to x-steps, y-steps) need to be relatively simple because the arduino is quite dumb. Not very fast, and no hardware floating point. Getting the host computer to do the awkward maths, even in a terribly slow and badly implemented way, is going to be orders of magnitude faster than the arduino.

I believe Forrest does the rasterising on his PC, and transmits a pre-digested instruction stream to his controller electronics. This has the handy knock-on effect of reducing the memory requirements of a part, which is why he can store hours of print instructions in a fairly small storage device.

Anyway.

I think being able to do arc drawing is a good thing, but to make full use of it we need a different part representation (or at least the ability to fit curves to STL facets). The results should be more pleasing to the eye, and potentially more useful for other sorts of parts (say, a syringe barrel and plunger), and the amount of communcation required between host and controller will be much less.

I note with interest this new page... [reprap.org] which identifies (presumably small) circular (and circle-segment) features and does a small amount of magic by converting them from connected line segments into a curve. This is done for other reasons than smooth parts and reduced communication, but if the technique works it could be used to further these aims too.