True Arc Commands (G02 G03)

[chuyskywalker]

Quite a few 3D printers today support true arc commands which have some worthwhile benefits. These GCODE commands (G03 and G03) produce smooth arcs with significantly less GCODE which eliminates faceting on model surfaces during prints, makes for less machine jerking, and in some printers, helps with buffer overflow.

Some slicers today implement these movements either by accepting vector model files (step for example) or by utilizing ArcWelder and similar approaches to transform sets of 2D moves that look like arcs back into proper arc commands.

As a simple example of how this plays out, this draws 4 circles in a row (my example here was based around experiments for making FullControl parameterized battery pack cell holders):

from math import tau
steps = []
cell_diameter = 21.2
segments = 90
clockwise = True
for i in range(4):
  circle_center = fc.Point(x=50 + (cell_diameter*i), y=50, z=0)
  steps.extend(fc.travel_to(fc.geometry.polar_to_point(circle_center, cell_diameter/2, 0.25*tau)))
  steps.extend(fc.circleXY(
    circle_center, cell_diameter/2, 0.25*tau, segments, clockwise
  ))

fc.transform(steps, 'plot')

The GCODE produced from this, excluding all the printer start/prime/stop stuff, is something to the tune of 364 commands.

Here's the same result (minus E amount, I don't know how to calculate that):

G21 ; set units to millimeters
G91 ; relative positioning, makes the below coordinate movement easier
G0 X21.2 Y21.2
G2 I0 J-10.6
G0 X21.2 Y0
G2 I0 J-10.6
G0 X21.2 Y0
G2 I0 J-10.6
G0 X21.2 Y0
G2 I0 J-10.6

The end result of 4 printed circles is the same, but the G2 commands will produce much better print results.

[dicksondickson]

Keep up the awesome work!

[fullcontrol-xyz]

This is definitely possible. But first, here's some context to explain why it's not already in FullControl. It's not included in the current release in the interest of simplicity and versatility. E.g. The move() or move_polar() commands would need to be extended to assess whether you're design includes points only or points and G2/G3 commands - since the way they'd need to be modified for a 'move' is different. Similarly, the 'plot' result would need to convert the G2/G3 commands into some kind of plot-specific arc or several points anyway. As I understand it, printer firmware typically converts arc commands into straight segments anyway, according to settings in firmware about how many segments should make up an arc. But I'm not sure if there are still benefits in terms of buffering or whether it's mostly beneficial for reduction in GCode size. There are a few other benefits of representing the arcs as points (e.g. the ability to 'post-process' geometry, and the ease of creating paths with a vase-mode-like strategy). But I know they're a nice addition for sure. I'm not at a computer now but in a few days, I'll check out how quick it is to put together a demo adding G2/G3 options. But it'll be mostly a quick proof of concept. We intent to describe the FullControl source code in much more detail in the future so people can quickly add custom functionality for things like G2/G3 commands or many others, like beziers or helices, etc.

Any other thoughts about this would be welcome!

[fullcontrol-xyz]

added to roadmap - closing issue

[ES-Alexander]

@fullcontrol-xyz I was thinking a bit about the visualisation requirements for arc commands, and remembered having seen an Issue for supporting them, then was surprised to find this "closed".

Issues are generally a good place for discussions and tracking progress on a feature, so it seems odd to me for them to get closed (especially "closed as completed") when they've only been added to the roadmap, because it

1. makes the issues harder to find,
2. makes it seem like the feature might already exist, and also
3. dissuades further conversation and ideas towards them,

all of which might discourage external contributors from working on those features, which I imagine is not the intent.

I'd recommend re-opening those closed issues, and perhaps making a project for the roadmap that links to those issues, so features in different states (e.g. in progress, next, later, done) can be tracked and engaged with more intuitively.

---

The move() or move_polar() commands would need to be extended to assess whether you're design includes points only or points and G2/G3 commands - since the way they'd need to be modified for a 'move' is different.

I think this would make more sense to handle within the geometry objects themselves - e.g. each geometry object (Point, Arc, etc) could define its own translate and rotate methods, that higher level movement functions like move_polar could then make use of without needing to worry about the internal details. That also opens up the possibility of collection objects that handle iteration/broadcasting, in which case the higher level functions could just treat their inputs as singular (instead of needing special case handling of singular objects vs collections/sequences).

This is similar to (and could possibly even make use of) Python's operator overloading functionality, where, for example, you can have objects that overload the addition (+) operator (by defining an __add__(self, obj) method) or the in-place addition (+=) operator (by defining __iadd__(self, obj), to modify self by adding obj). These docs provide an example with some extra context.

As I understand it, printer firmware typically converts arc commands into straight segments anyway, according to settings in firmware about how many segments should make up an arc.

While that must be the case for machines with linear motion systems, it might not be for other machines (like #45, or a multi-axis robot arm), which could efficiently perform some arc commands with angular control of a single motor.

[fullcontrol-xyz]

Yeh, the intention was that things on the roadmap would be completed in a few days/weeks, but that it difficult to keep up, so I think it is a good plan to reactivate them even if they've been 'added to roadmap'

And thanks for the link to projects. I'll look into it.

In the next couple of weeks, I'll go through the roadmap and knock out the long overdue ones! Then any that are going to take longer than that, I'll reopen the associated issue.

My understanding was that an issue that has been resolved in the code is best to be closed. Otherwise, it seems like there are lots of open issues, which people may consider to mean the project is abandoned. I can also see an argument for keeping all issues open that relate to aspects that may evolve in the future, to help give context and discussion. I'll continue to think on it when I read into projects, but am open for suggestions about rules/common-practice for issues.

I know some repos only want issues to be problems, not discussions. But I'm happy for this repo to have a very open definition of 'issue', also for questions/advice/etc.

[ES-Alexander]

Just came across a youtube video where @kennetek mentioned they've implemented G2/G3 support in their modified version of FullControl 😃

I've asked if they're interested in upstreaming the changes, but their project is a copied inclusion rather than a fork, so it's a bit more involved than just creating a direct pull request. If someone comes along in the meantime and wants access to their work within the main FullControl¹ then it should be possible to do a diff to see the code changes by checking out the state at a8ff21d (the last commit here before their repo was created) and then copying the files over from the modified fullcontrol folder to see which ones are new/modified.

---

@fullcontrol-xyz if this is a problem that's being actively worked on, it seems like this Issue should be reopened for discovery/clarity purposes, and to encourage discussion as relevant :-)

Footnotes

1. License-wise there are no concerns with bringing their repo code in as relevant, because GPL subsumes MIT (which is what the GridFinity part of their project is licensed under). That said, appropriate author attribution should of course be provided if a contributor is merging in someone else's code. ↩

[kennetek]

Yeah, sorry that it wasn't forked, I had no intention of modifying the library when I started my little project. Its somewhat hack-y, I only verified that functions would work in my very specific use cases. For instance, I never used move_polar on an Arc, and reflectXY does not behave as expected for silly reasons (its more of a rotation since that was less work at the time). Visualization was done by having the new arc object create an arc composed of linear steps and visualizing that. A proper implementation would require more of an overhaul. Right now its more like the quick demo discussed above. I have the same concern mentioned before, I don't know if G2/G3 actually did anything to make the print better, other than reducing the G-code file size, which doesn't really matter all that much. Otherwise, I guess I would be interested in helping implement, since I'll probably be doing more projects like this in the future.

[fullcontrol-xyz]

So exciting to see this! I'd love to have a whole host of gridfinity examples!

I see the gridfinity demo and the G2 feature addition as two completely separate things in my mind. Am I right in thinking your python code would all work fine if all arc objects were replaced with fc.arcXY objects (assuming print quality is unaffected)... they'd just result in more gcode lines?

I'm v happy you implemented the visualise and gcode versions of Arc and added the class to the combination script that merges both. I was never fully happy with that implementation but it worked well enough so I never improved it. As someone coming to the repo new, did that workflow make sense?

Getting Arc into FullControl has a fair few knock-on effects (adding complexity/incompatibility to the geometry functions like move/CONVEX/move_polar/etc.) but could be cool to add with a warning to say don't try to combine it with geometry functions that are based around fc.Points.

On the other topic... it'd be great to get a gridfinity section in fullcontrol and that could easily go on www.fullcontrol.xyz - are you planning to make any further models?

[fullcontrol-xyz]

p.s. with a bit of back-and-forth iteration, I think we'd be able to take the nice benefits you've got in your design and supplement them with some other cool benefits (speed, seam, etc.). One thing I love is fat vase-mode - I've done 1mm wide walls with a regular 0.4 nozzle before. Already have a few other ideas after watching your video. V nice video btw!!! And thanks for such nice attribution 🤩 obviously any addition to FullControl should make the link to you super clearly too

[kennetek]

Oh that would be fun to have a Gridfinity section on the site. The current code would work fine with linear interpolated arcs, it was originally made that way and could be fairly easily converted back I think, with a little refactoring. From experience the amount of features is bottomless, so I don't really want to try to implement too much, its a slippery slope. I suppose that the bare minimum would be having more than just one-wide bins (so a 2D base grids), since printers can totally bridge more than 40mm. Also the thin baseplates would probably be a good idea, and not too hard since their geometry is not that complex.

If I was being ambitious, it would be cool to do scarf seams.

[kennetek]

And as for the visualization and gcode versions being separate, I'm not exactly the greatest Python user so it confused me a little, I mostly got through it by copying the existing Point class.

[eeverman]

Any movement on this?

I'm trying to build something with a circular shape and tangent lines meeting that circular profile - It's nearly impossible to make intersecting circular shapes because it's very difficult to calculate where a segmented circle intersects a tangential line.