G2/G3 Arc Movements
-
tl;dr: the "DefaultArcSegmentLength" in Configuration.h is set to 0.2 (I assume this is mm). Is that a function of the nozzle diameter (0.4mm / 2 = 0.2mm)? For using smaller nozzles, would I then set this to be a fraction of that for smother arcs in G2/G3 commands? How feasible is it to code true arc movements in the firmware?
Longer version: I spent three days printing a Saturn V model and was a little disappointed by the surface finish (using a Ultibots D300VS-PLUS, so circles should be easier). I've read up on the inherent issues with slicing STLs (even high-res ones). And I was toying with writing a processor for OpenSCAD or comparable to get better prints from geometric shapes. But reading the firmware code, it just seems to slice the arcs into a bunch of 0.2mm segments anyway.
Long term, I can see plenty of use-cases for G2/G3 commands (once curved triangle supports / slicing from CAD files directly / etc is a thing). In the interim, I'm wondering about whether it makes sense to just write my own gcode from scratch for some of my projects (e.g. small, high detail stamps for wax sealing). I have 0.15, 0.25, and 0.3mm nozzles. Would it make sense to change the DefaultArcSegmentLength to a smaller increment for the smaller nozzles?
Thanks!
-
I guess that with a 0.15mm you might just get visible segments when they are 0.2mm long; but with larger nozzles, I doubt it.
-
Do you think true arc motion planning (instead of a bunch of line segments) would be analogous to 16 vs 32 vs … 256 micro-stepping? My gut tells me it'd be similar: progressively quieter due to smoother operations but insignificant gains in accuracy? Wouldn't smoother tool moves make for fewer / diminished acceleration-caused print artifacts?
-
True arc planning would probably be impossible to do except at low speeds because it would require arcsin and arccos functions to be computed on every step. I doubt that there would be a noticeable improvement in smoothness or quietness, because with 0.2mm segments the change in direction would be very small unless the arc being printed has a very small radius.
However, I could look at making the segment length decrease automatically at low printing speeds.
All this is rather academic for 3D printing, because slicers do not generate arc moves.
-
That's more than fair. I was trying to decide if I wanted to write the slicing part myself so I could get G2&G3 movements from a CAD format. I knew I didn't have the free time for STLs (and apparently neither does anyone else). But I figured if I had a file format that had geometry I could slice it into gcode with Perl. I hadn't thought the problem through past cylinders and spheres before I realized it'd be pointless if the firmwares my printers run don't support true arc movement. Higher polygon count is the solution that makes the most sense if arcs are turned into line segments anyway. I'll put on my TODO list writing a gcode file that builds a simple cylinder (say 25mm radius, 10mm high) and compare that to the same printed from a cylinder of similar dimensions in CAD, exported to STL, and printed. I think you'll be proven right, but what the hell.
-
Including G2/G3 moves in the GCode output from slicers would reduce the size of GCode files, potentially allow higher printing speeds for arcs, and allow the arc segment length to be determined by the printer based on its processor performance and the printing speed. So a good thing IMO.
-
Maybe this is obvious to others, but is the G2/G3 support in latest firmware solid? The gcode wiki page (https://duet3d.dozuki.com/Wiki/Gcode) indicates it is beta.
I found some code (https://gcodeutils.readthedocs.io/en/latest/gcode_optimize_arcs.html) that purports to do gcode conversion to arc moves, and thought I would play around with it. Maybe I'm wasting my time?
Thanks as usual for the help/discussion.
-
What the wiki actually means is that it was first introduced in firmware version 1.17beta. I believe it is solid, but it has been exercised a lot less than the code for straight moves.
-
Ok thanks for the clarification.
-
Btw until the latest RC firmware, there was no axis limit checking during arc moves, only for the end point.
-
Following up: I'm still on 1.20, but using the python code referenced above, I've been successfully playing around with the arc moves. Seem to work just fine, can result in significantly smaller gcode files as expected. Thanks again.
-
I tried milling a rather simple 3D shape (half a sphere, 6mm radius) using a GCode file produced by CamBam from an STL file, with 1800mm/min feedrate. I ended up trying for the rest of the day to figure out what is wrong with WorkBee as it made really terrible noises and kept loosing steps on X axis.
Only late at night I rewired GRBL and tried the same file (well, re-generated for GRBL) and all OK. So it is a problem with the G2/G3 algorithm when there are a lot of small arcs. I rechecked with Duet3D reducing the feedrate to half and then it also worked.
I did another try with a differently generated GCode, based on controlled slope contour milling. That produces a lot smaller file, with fewer larger arcs. That is working as expected with Duet3D as well.
Maybe unrelated problem - for G2/G3 I had to force CamBam to always include X and Y coordinates. Situations when one of the coordinates didn't change, and there are plenty of when doing high-speed machining, were ending with error messages. In the end, having a coordinate value to be reused should skip the conversion from text (GCode info) to floating point, thus reducing the CPU usage a little bit.
P.S. All these have been tested with firmware 1.21.
-
Thanks for your report. I can change G2/G3 so that X and/or Y need not be specified.
When you had the problem with small arcs, did you try increasing the X and Y maximum speed change values in M566?
-
M566 has 900 for X, Y and U and 60 for Z.
The machine is pretty heavy, with the spindle weighing 1.7kg. The whole "effector" is over 4kg with the whole Z-axis mechanics, 86mm long NEMA 23 stepper, drag chain etc. The complete X axis should be way over 10kg. The WorkBee vibrates when doing high speed machining, thus I would avoid increasing accelerations and speed change values beyond the current settings.
On the other hand, the GCode file produced from STL had sudden changes between climb and conventional milling (in my situation that translates to milling CW vs CCW around the material) while the "good" GCode has only climb milling commands. Being a rather small piece, it is impossible to tell if the "bumps" happen when changing direction or at different position in the file. I will try to set M566 values to much lower because of the weight of the machine.
As for the missing X or Y, the NIST standard specifies that at least one of X or Y must be present and, also, at least one of I or J must be present. Missing coordinate is interpreted as the same coordinate value and missing I or J is interpreted as 0. Of course, going to more flexibility, like allowing missing both X and Y to have a full circle with a known center, should be OK. Also, G2/G3 missing both I and J could be simply ignored but that would be just one wasted line of GCode!
The above comment for G2/G3 is true when working in XY plane, like the RepRap firmware works right now! But that will be another discussion.
-
It is even worse… trying to do a 2400mm/min machining is again showing lost steps. Everything points to a maximum number of steps per second during G2/G3 below that limit. Going to try at 1800mm/min that seemed to work.
Again, for reference, WorkBee CNC with 400 steps/mm at 16 microstepping.
-
Did the test… at 1800mm/min the same file worked like a charm!
-
What steps/mm and microstepping does your Duet powered machine use?
-
400steps/mm with 16 microsteps. I also did the math - 1800mm/min -> 30mm/sec -> 12000steps/sec.
-
After trying to machine some small Aluminum parts, I had problems even at 1200mm/min. In the end, after doing a lot of tests and studying the problem, the CAM processor is the main culprit. I use a lot of trochoidal milling as it produces much better results on a not-so-rigid machine. The CAM software produces some sudden direction changes in specific situations, so specific that many times they do not happen at all.
I have found a pattern that easily reproduces the problem. In the end it was the maximum jerk being too high! 900mm/min instantaneous speed change for an 10kg gantry is anything but normal. Maximum feedrate of the WorkBee is 2500mm/min!
