[Feature] Produce arcs in spiral vase mode

[NameOfTheDragon]

Arc Welder doesn't appear to process arcs when spiral vase mode is used. For example, a simple cylinder printed in vase mode will produce arcs in the skirt and initial solid infill layers, but none at all in the spiral perimeter. That's a shame, because vase mode is potentially where some big wins could be achieved.

Perhaps the Z offset of each extrusion id causing confusion, or exceeding the resolution settings, but couldn't the Z offset be ignored for ArcWelder's purposes?

Attached are two GCode files produced in Prusa Slicer and downloaded from OctoPrint, using a simple cylinder in vase mode.
Prusa-Slicer-Cylinder-Vase-Mode.zip

[FormerLurker]

Unfortunately creating an arc with an end point at another Z location is not possible. At least I'm not aware of this if it is supported by any firmware. See the RepRap Gcode Specification here for G2/G3.

[girrrrrrr2]

It looks like in the latest version of marlin you can use arc in different planes.

Config_adv.h Line 1802-ish
//#define CNC_WORKSPACE_PLANES // Allow G2/G3 to operate in XY, ZX, or YZ planes

But it does look like it doesnt work in a way that would be helpful for this, unless im understanding it wrong, it looks like it converts your full planes of movement into the XY YZ XZ planes and doesnt arc between XYZ.

https://marlinfw.org/docs/gcode/G002-G003.html - Arc Support
https://marlinfw.org/docs/gcode/G017-G019.html - CNC Planes

[NameOfTheDragon]

Unfortunately creating an arc with an end point at another Z location is not possible. At least I'm not aware of this if it is supported by any firmware. See the RepRap Gcode Specification here for G2/G3.

This is most certainly possible in Klipper, as demonstrated in the unit tests and in this video of my printer printing a spiral arc.

The Marlin documentation also documents this as possible, and looking at the source code for both Marlin and Klipper, they certainly do support it. In Marlin's case, the default situation is that CNC planes are disabled in which case it simply assumes that Z is the up/down axis (it refers to it as l_axis in the code).

From the Marlin code, the arc appears to be planned in 2D and then the Z movement simply divided equally along each arc segment, although it does take Z into account when computing the total distance moved (hence the amount of filament to extrude).

I am sure this would complicated arc detection somewhat, but I feel that it is something worth pursuing because vase mode prints are likely to be one of the most compelling use-cases for Arc Welder.

[FormerLurker]

I also learned smoothieware supports z-interpolation, but I don't think marlin's cnc planes actually work for this. I will keep looking into it.

[FormerLurker]

Fyi, including the z axis will slow things down, but I agree that it would be great, and could maybe even be detected and turned on only if a spiral vase is printing. Will look into this after I finish threading the conversion routine.

[FormerLurker]

So, the marlin docs suggest that only one plane can be active at a time, but arcs would require x y and z. I don't think it would be difficult to include (I did notice z interpolation is in the g2/g3 code, but it doesn't look like the any z parameters are fed in)

Edit: link to docs

[NameOfTheDragon]

So, the marlin docs suggest that only one plane can be active at a time

I think CNC planes are a confusing distraction and we don't need to consider them for this use case. All CNC planes do is allow you to rotate the coordinate system, i.e. to specify which axis is "up". That feature is not normally enabled in Marlin (not for 3D printers) and "up" is always Z.

With CNC planes feature normally disabled, Marlin still supports 3D arcs but it defaults to the normal 3D printer orientation (Z up). Both the docs and the code confirm that arcs can have a Z component. If you look at the G2/G3 documentation page and scroll down to the argument list, you can see that it includes a Z position (the Z coordinate of the end of the arc). There is no requirement for CNC planes given.

If we look at the code (BugFix 2.0 branch, file G2_G3.cpp):

void plan_arc(
  const xyze_pos_t &cart,   // Destination position
  const ab_float_t &offset, // Center of rotation relative to current_position
  const bool clockwise,     // Clockwise?
  const uint8_t circles     // Take the scenic route
)

Method takes a position with XYZE components. Not conclusive on its own, but...

 {
  #if ENABLED(CNC_WORKSPACE_PLANES)
    AxisEnum p_axis, q_axis, l_axis;
    switch (gcode.workspace_plane) {
      default:
      case GcodeSuite::PLANE_XY: p_axis = X_AXIS; q_axis = Y_AXIS; l_axis = Z_AXIS; break;
      case GcodeSuite::PLANE_YZ: p_axis = Y_AXIS; q_axis = Z_AXIS; l_axis = X_AXIS; break;
      case GcodeSuite::PLANE_ZX: p_axis = Z_AXIS; q_axis = X_AXIS; l_axis = Y_AXIS; break;
    }
  #else
    constexpr AxisEnum p_axis = X_AXIS, q_axis = Y_AXIS, l_axis = Z_AXIS;
  #endif

If CNC planes are enabled, then you can specify which planes you want to work in, otherwise it just defaults to the XY (normal 3D printer) plane in the #else section.

The key variables are a bit unintuitively named. The key names are linear_travel (Z offset, computed line 99) and linear_per_segment (amount of Z offset per arc segment, computed line 168). This is used starting at line 226 to 'loft' the arc into the Z plane, and at line 119 where it uses the segment length and the Z travel as 2 sides of a right triangle, and computes the hypotenuse to get the extrusion length.

So for a 3D printer (i.e. ignoring CNC planes) Marlin creates the arc vertices in the XY plane, but then later it lofts them into the Z plane by distributing the Z offset equally to each arc segment. It also uses Pythagoras to compute the hypotenuse travel distance which sets the amount of extrusion.

It's all there. I can't conclusively prove it because I am not running Marlin, but if that's what it takes to convince you, I'm willing to re-flash my printer with Marlin and film it doing it ;-) But hopefully my video of my printer inscribing a 3D arc under Klipper will be convincing enough.

[FormerLurker]

I am running a fork of marlin and will retry it. I have worked on that interpolation code (see the inverse processor app in the arcwelderlib repo), and saw the z interpolation, but z parameters are ignored in my firmware. I've been trying to flash marlin 2 to test (i have an mmu2, so it is a bit of a hassle). Anyway it is beside the point because I can just make it work for firmware that definitely supports it. I will post in the marlin discord and maybe @thinkyhead can give us a rundown on using the z coordinate with g2/g3.

That being said, it will be a bit of a pain to program this without firmware that supports it, but still possible. The smoothieware folks just sent me a board, so as soon I can get hold of some cheap printer to put it on I should be good to go.

Also, if some firmware doesn't support this, I can indicate that in my new firmware checker (check out the latest devel branch) and either warn the user or just disable the feature.

Your klipper proof was good. There is nothing like seeing something with your own eyes. Klipper (at least the newest version) seems to slay arcs. I've always wanted to try it, but am hesitant to mess with my only printer too much. One day though..

[FormerLurker]

@NameOfTheDragon, btw, I checked out your site. Super cool. Astronomy is a bit of a hobby of mine, and I've always thought it would be a great area to apply some programming skills. Kudos, and thanks for your work extending our knowledge of the universe!

[NameOfTheDragon]

If you do get around to doing this, and you still don’t have firmware support, then as the feature requestor I will accept responsibility to help as much as I can with testing. Just let me know.

[FormerLurker]

@NameOfTheDragon, you can be 100% assured I will bug you to test, lol

[FormerLurker]

@NameOfTheDragon, What OS are you using right now?