ArcWelderPlugin
ArcWelderPlugin copied to clipboard
FormerLurker
[Feature] Produce arcs in spiral vase mode
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
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.
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
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.
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.
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.
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
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.
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..
@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!
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.
@NameOfTheDragon, nevermind, I went ahead and pushed to a new branch. Check this out:
https://github.com/FormerLurker/ArcWelderLib/actions/runs/375119041
Add one of the following parameters: -z or --allow-z-axis-changes
I have NOT printed one of these, but I have done quite a bit of analysis. Looks good from what I can tell.
Caveats: I had to search for a model that actually had a reasonable number of curves AND a decent resolution. Lots of them are made from low resolution STL files, which is no good. Here is one I found that works pretty good. I had to rotate it 90 degrees.
Here is the output for running that model with the default settings + the -z parameter:
C:\Temp>ArcWelder SpiralVaseTest_ORGANIC.gcode output.gcode --allow-z-axis-changes
2020-11-20 14:56:48.001 - arc_welder.gcode_conversion - INFO - Processing Gcode
Source File Path : SpiralVaseTest_ORGANIC.gcode
Target File File : output.gcode
Resolution : 0.0500mm (+-0.02500mm)
Path Tolerance : 5.000%
Maximum Arc Radius : 1000000mm
Allow Z-Axis Changes : True
G90/G91 Influences Extruder : False
Log Level : INFO
Hide Progress Updates : False
2020-11-20 14:56:48.003 - arc_welder.gcode_conversion - INFO - arc_welder::process - Parameters received: source_file_path: 'SpiralVaseTest_ORGANIC.gcode', target_file_path:'output.gcode', resolution_mm:0.05000mm (+-0.02500mm), path_tolerance_percent: 0.05000, max_radius_mm:1000000.00000, g90_91_influences_extruder: False, allow_z_axis_changes: True
Progress: percent_complete:100.00, seconds_elapsed:0.68, seconds_remaining:0.00, gcodes_processed: 162667, current_file_line: 165837, points_compressed: 157521, arcs_created: 12578, compression_ratio: 7.22, size_reduction: 86.14%
2020-11-20 14:56:49.688 - arc_welder.gcode_conversion - INFO -
Min Max Source Target Change
----------------------------------------------
0.000mm to 0.002mm 0 0 0.0%
0.002mm to 0.005mm 0 0 0.0%
0.005mm to 0.010mm 0 0 0.0%
0.010mm to 0.050mm 0 0 0.0%
0.050mm to 0.100mm 3 2 -33.3%
0.100mm to 0.500mm 7139 617 -91.4%
0.500mm to 1.000mm 51971 469 -99.1%
1.000mm to 5.000mm 99314 3717 -96.3%
5.000mm to 10.000mm 779 1700 118.2%
10.000mm to 20.000mm 57 1883 3203.5%
20.000mm to 50.000mm 502 6434 1181.7%
50.000mm to 100.000mm 327 327 0.0%
>= 100.000mm 5 5 0.0%
----------------------------------------------
Total distance:............249909.555mm
Total count source:..................160097
Total count target:...................15154
Total percent change:..................-90.5%
2020-11-20 14:56:49.690 - arc_welder.gcode_conversion - INFO - Arc Welder process completed successfully.
If you're interested in how this was accomplished, I had an insight that made it pretty darn easy to add: Spirals are just circles when you look at them from above. I just added some parameters to enable z axis change, and added a hypot to the arc length calculation if z changes are allowed. I also added a check to make sure the spirals can only travel < 360 degrees to prevent wonky behavior for true cylinders. After that it was pretty much off to the races. 👍
Anyway, let me know how it goes! I'm anticipating some bugs, fyi. There are bound to be some.
Oh, FYI, I forgot to mention another check I added. Not sure if it can be improved, but I basically check to make sure the slope of the arc is constant too. It currently is set to ensure the slope is equal within the gcode resolution (typically 0.001mm) Since the z steps are pretty small when printing in vase mode, this is probably adequate.
OK, I also had a chat with some marlin gurus. Looks like you were right @NameOfTheDragon, in that it's been supported for a long long time. I investigated my problem on my printer, and discovered it wasn't working due to a coding error I made in a firmware customization, lol! I renamed a bunch of stuff and just plain goofed and forgot about it. Anyway, I found and fixed that, though I don't feel any less stupid :)
I'll try to run a spiral test print on it tomorrow and will report back.
Lift off!
I printed this at 150% speed of the default Mk2.5 0.2mm profile, and it still looks great.
@FormerLurker Awesome! I've only just seen that you pushed a branch with this in. I'll try it out ASAP, I'm playing catch up at the moment so give me a day or two.
@FormerLurker My first impression is that this works spectacularly well. I made a 40x40x40 cylinder in Prusa Slicer and converted it to arcs from the command line. It reduced the file size by over 92% (1419 Kb to 177 Kb). I'm printing it now and it looks perfect. Next up, I'll try an actual spiral vase to give it a harder task.
OK I see a potential problem. Now this could be my understanding of the tool and I might not be using it correctly, but I see a sort of "seam" up one side of my cylinder, which is unexpected in a vase mode print. See photos taken under a microscope.
@NameOfTheDragon, maybe I can't see as well as you, but I haven't noticed this yet. Did you happen to use the 'firmware compensation' flags that were recently added? There was a bug in one version at least that caused the endpoints not to line up 100% depending on the settings for --mm-per-arc-segment and --min-arc-segments. I applied a patch (see the latest release, 1.0.0) that seemed to correct the issue, but I still need to do some investigations there.
If this is NOT related to the firmware compensation settings, then a more thorough investigation will be needed to figure out what's going on. I can run the code through my 'ArcStraightener' application to see what the firmware might be doing. I need to update ArcStraightener a bit so it has flags for different firmware versions, but it should give us some ideas.
Ok, maybe check out the latest release and retest? I changed the option name to --allow-3d-arcs or something like that since it sounded more intuitive.
OK I see a potential problem. Now this could be my understanding of the tool and I might not be using it correctly, but I see a sort of "seam" up one side of my cylinder, which is unexpected in a vase mode print. See photos taken under a microscope. ...
Good day. I too am testing this. Would you mind sharing the model and also the slicer you used? I'd like to try to replicate on my end (E3v2 running Marlin >2.0.6 with the arc support upgrades therein). I too have a microscope that would be a too of use here. Thanks, in advance.
-t
It should. I recommend printing a few layers though to make sure. Worst case the print fails rather quickly :)
@TylonHH, thanks for reporting back! Except for what seems to be some potential firmware issues with the endpoints, I think this feature is pretty well tested now.
@TylonHH, thanks for reporting back! Except for what seems to be some potential firmware issues with the endpoints, I think this feature is pretty well tested now.
So, why is this feature not implemented in the newest (big) update 1.0.0?
@TodWulff,
So, why is this feature not implemented in the newest (big) update 1.0.0?
I've been working on this build for like two years now, and was SO SO close to pushing it live in November, but I've been so slammed with actual work since then that I have had 0 time to continue. I thought originally it would be about 2-3 months like this, but it's turned out to be more like 6 months. We are in the deployment testing phase on this project now, and I anticipate the rollout will be next Thrs or Fri. Add one week for debugging production projects, and it is looking like I'll get back to this (as well as a big Octolapse update) by the middle of April.
Anyway, the code is available in this repo (devel is the latest I think, check the latest commit date to be sure) if you want to try it out. The console version got a huge overhaul as well. There are TONS of new features, better compression, better error detection and correction, and so on.
Hi @FormerLurker , I'm also interested in Arc Welder 3d feature for post processing Grashopper generated non-planar & spiralling Gcode. I'm new to octoprint (just installed it on RasPi) and landed on this discussion after seeing no arcs being generated no matter what resolution I set. So if I understand correctly, this is off by default? How can I enable it, I can't find it in the settings. I'm running [Arc Welder v1.0.0+u.bb71e8f], do I need to update?
@UnfoldAntwerp, you will need to install the latest release candidate of the plugin, then just look at the arcwelder settings and enable 3d arcs. Sorry for the delay (I've been having a lot of problems lately). Check here for update instructions, and when prompted, use this URL for installation (if you are reading this from the future, this url may be outdated): https://github.com/FormerLurker/ArcWelderPlugin/archive/refs/tags/1.1.0rc4.zip