Welcome to the SeeMeCNC Community

I am trying to learn Gcode (just so I can read it) and was looking at 2 of the G parameters in marlin G2 CW ARC and G3 CCW ARC. elsewhere on the forum there is talk about problems with hole diameter and the reason being how the slicers cut things into segments. those 2 codes seem to imply a true arc can be cut. is the reason we cannot do this because we use steppers and not servo motors with feedback, and of course the small memory of rambo and ramps?

could you get better printing if you used servos and the appropriate drivers and motherboard?

thinking out loud here, I know there are some very intelligent people out there that probably have already designed a solution for this.

Tom C

It has to do with early controllers not being able to handle it, I don't know if many current ones even do. I know smoothieboard supports it.

It has nothing to do with stepper vs servo, all in the processing of the code. The small line segments is a problem of the slicer and the model, not of the controller.

When I create a STL in SolidWorks, I set the faceting tolerance ridiculously high so that my circles are approximated by at least 4 decimal places(.0001"), the small circle thing isn't only models, it has to do with material shrink, accelerations, etc.

STL files are made up of triangles, so no matter what you do there's no arc to generate G code for. That's why even with JFettig's method, you'll end up with a lot of little straight segments. (A circle is actually just a polygon with an infinite number of faces. )

g.

thanks guys,

Tom C

Marlin firmware claims to be able to decipher when a series of segments are intended to represent an arc and convert it to arc motion. It did seem to make nice arcs but I can't confirm that was responsible (and segmented delta math would get in the way of that anyway).

geneb wrote:STL files are made up of triangles, so no matter what you do there's no arc to generate G code for. That's why even with JFettig's method, you'll end up with a lot of little straight segments. (A circle is actually just a polygon with an infinite number of faces. )

g.

In the real CAM world, they approximate lines by arcs, it really shortens up the g-code files. It would be nice if they would implement something along those lines.

look-ahead or trajectory planning.

Basically rather than run to the end of a line then abruptly change direction (hugely speed limited limited by jerk and acceleration settings) they cut the corner to keep some speed up.

If a printer's controller firmware supported it and you opened up the tolerance a fair bit it'd speed perimeters and smooth things out. But it takes a fair whack of processing power which is why it doesn't appear on the 8 bit controller boards.

The new ARMs could probably deal with it, though.

JFettig wrote:

geneb wrote:STL files are made up of triangles, so no matter what you do there's no arc to generate G code for. That's why even with JFettig's method, you'll end up with a lot of little straight segments. (A circle is actually just a polygon with an infinite number of faces. )

g.

In the real CAM world, they approximate lines by arcs, it really shortens up the g-code files. It would be nice if they would implement something along those lines.

You typically don't feed a CAM system an STL file. (at least not in my experience) If you could slice an OBJ or IGES file, you probably would see arc commands emitted.

g.