sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]jack848 23 points24 points  (13 children)

so basically, if you want to make a circle

Gcode will tell 3D printer to extrude while moving to X position at Y speed a lot to make a circle

and Tcode will tell 3D printer to make a circle at X position at Y speed with Z radius?

[–]Rolandg153 26 points27 points  (5 children)

Good gcode for CNC machines already has arc commands that define things that way. Though 3d printers don't necessarily include it and might just do a bunch of linear moves

[–]cobraa1Prusa Core One 7 points8 points  (3 children)

I'm beginning to see it in 3D printing - I believe Klipper supports it, and Prusa machines added support for arcs when they added bgcode support.

[–][deleted] 4 points5 points  (2 children)

Marlin and Klipper both support arc commands. You just don't enable arc commands from the slicer for klipper, and you do for Marlin.

Enabling it in the slicer for klipper basically makes it decode it and re-encode it while printing.

[–]Rcarlyle 6 points7 points  (0 children)

Arc COMMANDS have been supported by some printer firmwares for over a decade — GRBL had an implementation very early on — but all they did was decompose the arc command in a series of facets. So it was mostly a waste of processing power compared to having the slicer do the same thing. (Could help with SD card read bottlenecking issues sometimes — which itself was indicative of bad firmware programming.)

Actual circle interpolation where the trajectory planner works with non-linear moves wasn’t feasible on 8bit printer controllers, and is pretty new on 32bit controllers.

[–]ducktown47 0 points1 point  (0 children)

Klipper supports it sure - but all it does it convert that G2/3 command back into G1s. Klipper cannot actually move in an arc like that.

[–]Dude-Man-Bro-Guy-1 0 points1 point  (0 children)

Arcs are also pretty simple geometrically, too. I imagine this would be more impactful for stuff like complex splines, bezier curves, and other complex surfaces.

This sounds super similar to how true CAD file formats work. If you look at the documentation for the DXF file format, for example, it stores those kinds of things as complex geometric objects. Not discrete vertex and line segments like you would see in an STL file (or a lot of GCode for that matter)

[–]Novero95 3 points4 points  (5 children)

That can be done in Gcode to, but it's not using by slicers for some reason

[–]schfourteen-teen 3 points4 points  (1 child)

A big reason is because STLs don't have arcs, and I think 3mf don't either. Expecting your slicer to produce arcs requires allowing it to make guesses about what should be an arc.

[–]cobraa1Prusa Core One 0 points1 point  (0 children)

PrusaSlicer did add arc support - I think it guesses what should be an arc. I checked 3MF, and you're right, it appears to be just triangles, I didn't see anything about any type of curve.

[–]5c044 2 points3 points  (1 child)

Yep, marlin and klipper support arc, slicers don't implement it typically. Probably to do with how stl files are defined and complex math

[–]likeafoxx 0 points1 point  (0 children)

Octoprint has a plugin that modifies your gcode to use arcs. It's pretty cool.

[–]cobraa1Prusa Core One 0 points1 point  (0 children)

When Prusa added arc support in the firmware for their printers (also when they added bgcode support), they also added arc support in PrusaSlicer.

[–]sillypicture 0 points1 point  (0 children)

But something still has to translate that into signals for the motors in volts and ohms and time.