Welcome to the SeeMeCNC Community

I come from a CNC background, programming with Mastercam is my job. I'm pretty good at reading and when pushed writing my own, so when I see samples of the code for these machines, it saddens me to not see G2 G3 moves. As I understand it, this is because most (all?) of the files are based off using a .STL file which is purely triangles. Is there a slicer that can "read" other file types that would allow output of arc moves (.IGS which is surface based, but still, .X_T, even .SLDPRT)? It would greatly reduce the size of our files (it would take a maximum of 4 lines of code to define any arc as opposed to up to thousands of facets for a large arc), and even give the user a chance to predict what the print head is actually doing.

It is not a slicer issue more than it is the firmware in the printer does not support those G2 and G3 functions. It only supports linear moves. So it will not do you any good to find a slicer that can output them.

Dale

3d printing is still very primitive, even Stratasys uses STL files still. Some slicers did convert to G2/G3 arcs in the past but firmware wouldn't support it. I'd love to see slicers come close to what good CAM software does but nobody will pay for it.

Thanks for the replies, guys. I'm guessing it's just part of being on the cutting edge... I can't wait to see how this grows!

How would you test this out?

According to RepRapWiki, Repetier and smoothie both support G2 & G3 moves.

http://reprap.org/wiki/G-code#G2_.26_G3 ... d_Arc_Move" onclick="window.open(this.href);return false;

Yes both do, repetier just breaks G2/G3 down into small linear moves internally. I've never looked at what the smoothie code does, I assume the same, since I believe it was originally based on GRBL.
You'll find even on cartesian bots if you try and do long arc moves too quickly the printer will pause at points throughout the move, and the CPU is overtaxed.

The issue is that most slicers will only read STL files which contain no arcs, STL files are just about the simplest file format you could imagine dealing with IGES files natively would be a lot harder.

what about amf format?

Outside of XML being a horrible basis for a 3D file format, the mistake is that it's still geometry based, rather than like most of the CAD formats that describe the construction history.
If you want to use G2/G3, you have to know your geometry was constructed from a circular arc parallel to one of the primary planes.
If you want to support arbitrary curves, you either have to tesselate them and your back to might as well use STL files or you have to support them in the firmware, then you get into what sort of curves does your software or firmware support polynomial subdiv surfaces etc etc.

As an amusing somewhat ironic aside side many highend CAD motion controllers approximate combinations of linear moves as high degree polynomial curves with some given error tolerance, to increase the speed they can be machined at while retaining the Acceleration and Jerk constraints of the machine. (in this case I mean Jerk in the mechanics sense, not the 3D printer firmware sense)

JFettig wrote:3d printing is still very primitive, even Stratasys uses STL files still.

I totally agree that "3d printing is still very primitive" But I think "additive manufacturing" is making some ground breaking advancement.
I've been interested in this file question since bringing my Max v1 online. I read extensively about "additive manufacturing" back then. IMO here is where I think a distinction between the needs of file formats exists.

In FFF/FDM like we do with our filament machines the geometry/code is more akin to classic tool paths. Thus the need for more typical code to describe an exterior surface/mesh with some arbitrary infill layer by layer. But what if your machine is capable of depositing/joining discreet "voxels" of material? Like the SLA or material jetting, then you get the ability to describe your part in terms of single drops or particles. How do you tell the machine to deposit a "cadmium red-Shore D durometer-ABS particle/drop" -next to a "binder particle/drop- next to a "bright white-Shore A-elastomer particle/drop"? I'm personally very excited by some of the research being done controlling volumetric solids this way.

http://matter.media.mit.edu/tools/detai ... p-printing" onclick="window.open(this.href);return false;
http://www.engineering.com/3DPrinting/3 ... ygons.aspx" onclick="window.open(this.href);return false;
http://3dprintingindustry.com/2013/04/3 ... el-method/" onclick="window.open(this.href);return false;
http://3dprintingindustry.com/2013/05/2 ... d-part-ii/" onclick="window.open(this.href);return false;

This is an interesting voxel based modeler that seems to be gaining some traction: https://www.3dslash.net/index.php" onclick="window.open(this.href);return false;

It will be interesting to see how this .amf vs. .3mf file format resolves itself too.

~edit- Just saw this: http://3dprint.com/77424/atom-precise-nanobeacon/" onclick="window.open(this.href);return false; How mind boggling is that?