When the slicer software for a 3D printer model files into GCode, it’s essentially creating a sequential list of connected line segments, organized by layer. But when the features of the original model are dense, or when the model is representing small curves, slicers end up creating a proliferation of teeny segments to represent this information.
This is just the nature of the beast; lots of detail translates into lots of teeny segments. Unfortunately, some printers actually struggle to print these models at the desired speeds, not because of some mechanical limitation, but because the processor cannot recalculate the velocities of these segments fast enough. The result is that some printers simply stutter or slow down the print, resulting in print times that are much higher than they should be.
Enter Arc Welder, a GCode compression tool written by [FormerLurker] that scrutinizes GCode files, hunts for these tiny segments, and attempts to replace contiguous clusters of them with a smaller number of arcs. The result is that the number of GCode commands needed to represent the model drop dramatically as connected clusters of segment commands become single arc commands.
“Now wait”, you might say, “isn’t an arc an approximation of these line segments?” And yes–you’re right! But here lies the magic behind Arc Welder. The program is written such that arcs only replace segments if (1) an arc can completely intersect all the segment-to-segment intersections and (2) the error in distance between segment and arc representation is within a certain threshold. These constraints act such that the resulting post-processing is true to the original to a very high degree of detail.
This whole program operates under the assumption that your 3D printer’s onboard motion controller accepts arc commands, specifically G2 and G3. A few years ago, this would’ve been uncommon since, technically, 3D printing and STL file only requires moving in straight line segments. But with more folks jumping on the bandwagon to use these motion control boards for other non-printing applications, we’re starting to see arc implementations on boards running Marlin, Smoothieware, and the Duet flavor of RepRap Firmware.
For the curious, this program is kindly both well documented on operating principles and open source. And if [FormerLurker] seems like a familiar name before–you’d be right–as they’re also the mind behind Octolapse, the 3D printing timelapse tool that’s a hobbyist crowd favorite. Finally, if you give Arc Welder a spin, why not show us what you get in the comments?
Thanks for the tip [ImpC]!
Too bad the outer perimeters weren’t processed in that benchy as those are the ones that would actually effect print quality the most.
No, wait, nevermind, I was looking at the skirt.
If you look carefully you’ll see that the skirt was also optimized, but probably didn’t fit so well in the curves.
Few years ago i’ve implemented very similar feature called “ArcFit” in bCNC. But it is meant to be used mostly for 2D g-code shapes: https://github.com/vlachoudis/bCNC/
That is a very neat implementation. A few decades ago I was part of a team that looked at a similar issue with files being fed to industrial sized wood CNC gear. If you can start with the original mathematical curves and not have to “fix” a stream of segments it is possible to look at all 2D curves as a series of elliptical quadrants or parts thereof. This came up as we were deciding how to write the code for custom commands to extend AutoCAD to suit the businesses specific needs. The first step is easy to visualise, just cut the line whenever it crosses a vertical and/or horizontal.
Obvious comment:
Why don’t the slicers do this from the beginning? I know the STLs don’t have arcs, but the one image shows the bottom layer as a spiral, and I’m sure the wavy infill would benefit as well.
Sure, some printers won’t support it, but that can be an easy check box somewhere “Use Arc Segments”.
Might as well ask why we are using lossy STL files to slice, when depending on the program and its default settings (cut into x number of line segments, but show the user a smoothed on screen version).
Other option might be having native Gcode plugins and generating gcode from the primitive data.
On a positive note, this is really a hack XD
So looking at the Github, this appears to me to be a plug in for Octoprint. Is there a stand alone version or plugin for Cura? I personally prefer to print from a SD card for reliability reasons. Or maybe someone could share a compelling reason for me to use Octoprint?
Thanks
I guess it is kind of a personal work flow decision, but I couldn’t see myself going back to SD cards. All 3 of my printers are on Octoprint and it is super convenient to be able to see and control them from anywhere, and have AI monitoring my printing with The Spaghetti Detective.
“it is super convenient to be able to see and control them from anywhere…”
Also, if the printer fails, it’s cool to see from anywhere how the whole house gets burned down.
SD Card: insert SD card into USB adapter, insert USB adapter into computer, Save g-code file to SD card, remove USB adapter from computer, remove SD card from USB adapter, walk over to printer, insert SD card into printer, go through menus and select correct g-code file, hit print, walk back to computer
And this assumes you don’t misplace the SD card on your desk or forget to retrieve it when you pull the print off your printer and have to go get it.
Octoprint: Send g-code file to octoprint, sip tea
Rather… open marlin menu, detach media, write gcode to SD, attach media, print. Printer stays attached to PC via USB.
Or in Smoothie just save gcode to SD and print :)
On Smoothie the SD card is exposed to PC all the time. I am stunned that Marlin still doesn’t have this feature even on 32bit boards and Smoothie had it years ago.
+1, I’d never go back to a card unless it was for a very compelling reason… Especially with an Octoprint plugin for Cura – just slice, hit ‘print’, and you’re done. You can watch the printer cam / etc right in Cura without even opening a browser to pull up octoprint. I’ve never had a reliability issue with Octoprint.
There is a console version (see the FormerLurker/ArcWelderLib repository on github, and check the actions for binaries), but you really should check out OctoPrint.
There is. Instead of using the Github repository, open Cura and click Marketplace. You’ll find Arc Welder in the Plug-ins section. After adding it, you’ll need to restart Cura. Then the option(s) will appear under Special Modes.
Similarly, Stefan at CNCKitchen has found that overwhelming your printer with many small moves can cause bad printing artifacts. https://www.cnckitchen.com/blog/removing-zits-and-blobs-on-your-3d-prints-adjust-your-slicing-resolution
I feel like we are on the cusp of a big step forward with slicing and gcode handling.
Except that the most common firmware (Marlin) just turns it back into line segments, usually with worse resolution, which is visibly worse. Which is why I never tried to do this in Cura when I wrote the engine.
(Oh, and also, Cura does already do the above segment removal to optimize that there are not too many tiny segments)
The video is precisely about the Cura settings that control this.
Did you expect that firmware would remain stagnant, never improving? If the most common slicer doesn’t output curves, why would the firmware need to handle them better?
I had introduced an early implementation of this in Slic3r since 2011, as an experimental feature available under the “G-Code arcs” option.
But it was not promoted too much because -at least until some time ago- Marlin had limited support for G2 and G3 which caused filling the motion planner buffer with a lot of small linear moves. While geometrically such little moves were a good approximation of an arc and were definitely better than generating them as G-Code commands, this disrupted the look-ahead logic and caused unpleasant changes of speed. :)
Also, I remember theoretical discussions about doing 2D curve fitting on a single layer without considering the contiguous layers: you get a more curvilinear path on each given layer, but this may not guarantee that the resulting surface is still smooth. This is better achieved with surface fitting algorithms that transform meshes into NURBS.
Most algorithms used in a slicer can be implemented in ways that transfom 3D problems into 2D problems, which is fascinating from a geometric point of view. But there was no general agreement on curve fitting being one of those :)
The G2G3 document of Marlin still says:
“Arc moves actually generate several short straight-line moves, the length of which are determined by the configuration option MM_PER_ARC_SEGMENT (default 1mm).”
And i couldn’t find anything that would indicate that has changed.
How about doing this to G-Code for milling machines?
Pretty much any good CAM software is capable of doing this. I’ve used Mastercam and Featurecam, both had the capability.
All early gcode used g2/g3, and most of us still write it that way if we’re working by hand. A lot of cam programs do, too. It can be somewhat limiting: it only handles circular arcs, not ellipses, and some older movement controllers had huge errors if the segment was approximately 180 degrees.
But, yeah, most older machinists prefer arcs. Movement to lots of straight segments only came about with newer, very fast, controllers that could handle cutting a curve into a thousand little straight segments.
note that when reading gcode, g2/g3 are definitely significantly harder to calculate the results for than a whole bunch of x,y locations, especially if you haven’t spent a lot of time reading gcode.
Inkscape gcode plugin puts arcs wherever it can when approximating bezier curves.
I’m trying this octoprint plugin out right now from a pretty curvy print (thing:2031690). The retraction has been reduced a LOT, but the printer is moving at about 1/5th speed, causing bad melty spots from too much heat in the areas with a lot of arc. The non-arc areas are normal speed.
“[BUG] ARC moves slowing down”
https://github.com/MarlinFirmware/Marlin/issues/15295
Perhaps that explaines it? There’s a workaround to that problem: “setting #define MM_PER_ARC_SEGMENT to 0.0 in Configuration_adv.h”
As far as I understand it seems GRBL splits the arc commands in segments itself. So if I’m right this won’t make a difference. Are there other cheap options next to GRBL that would make a difference? now I have an arduino running grbl connected to separate stepper drivers.
firmware usually splits arcs into very small steps. 1mm or less depending on the options at build time. arcs are going to produce a better finish than that in almost all cases. but two other advantages: 1) significant file size reduction and as a result 2) reduced or eliminated stutter when spooling via USB/Serial since it won’t constantly be exhausting the buffer.
I’m in the process of adding this feature into Kiri:Moto right now. And the results are impressive. It will be live in the development version in a day or two.
A significant problem of curve fitting algorithm and later conversion back to linear segments by the firmware is that
1) The whole operation is not coherent between layers
2) Even if it was coherent, it could create worse discontinuity at the transition between the circular arcs than they were there on the triangular model.
IMHO a spline fitting makes sense, but only if
1) The splines are followed by the firmware as splines
2) The splines are fitted by the slicer in a layer coherent way