Arc Fitting does not work as well as Arc Welder

[breathless19]

OrcaSlicer Version

1.9.0

OS version

Windows 11

Additional system information

No response

Printer

Qidi X-Max 3

How to reproduce

I've noticed on a file that I used to print in Cura but now print in Orca Slicer that the outer edges have significantly more noticeable edges on the outside wall.

I'm doing small circular objects that as far as I knew up to this point were perfect circles. In Orca Slicer however, they are certainly not, even with Arc Fitting enabled they look more like octagons when viewed from the bottom, regardless of the resolution setting.

However, in following a fix outlined by another guy on Reddit, if you use Arc Welder lib to post process the gcode, there are significant improvements in file size, outer wall appearance, and even time reduction in the total print time. It took an hour off of a 12.45 hour print, and the file size was reduced by about 60%. The object that I'm printing is made from 3 separate primitive objects, however this improvement can seemingly be demonstrated with any print, but here is an example from that same person who posted about it on Reddit:

https://www.reddit.com/media?url=https%3A%2F%2Fpreview.redd.it%2F89bgcdmm19zb1.jpg%3Fwidth%3D4000%26format%3Dpjpg%26auto%3Dwebp%26s%3D2c7a5fdbb68acc4aa96750cde98d5987c4c706c0

Actual results

Expected results

Arc Fitting is not working as expected. Since Arc Fitting is based on Arc Welder, I would expect there to be similar results in both print appearance, print time, and file size reduction.

Project file & Debug log uploads

.

Checklist of files to include

• [ ] Log file
• [ ] Project file

[foreachthing]

I turned Arc Fitting off and put Arcwelder into post... much better results imho.

[ninja-]

I am investigating arcs functionality as well, as it would benefit my print greatly, and it's a total hit or miss.
Looking briefly at the source code, I can't find much common ground between Orca's Arc fitting source code and ArcWelder.
I thought it would just call the library.
I checked that there isn't anything upstream from BambooStudio that could be synced to improve it.

However, PrusaSlicer not only uses ArcWelder source code, they also made some logic fixes to it last year.
If we want to fix this, we probably should sync the code with Prusa.

[evilDave]

I have been messing with arcs too (as part of a side quest to get printing complex geometry models from octoprint without stuttering) and have found that arc fitting is indeed pretty hit and miss. If any gcode gets interleaved between G1 instructions the arc fitting code will not be able to make them into arcs. If the z height changes between instructions arc fitting is also out. This means it doesn't work in vase mode, and it doesn't work with anything that adjusts the flow rate between line segments.

Arc welder code has been improved (since the parts of it were copied into orca) to be able to deal with some of these issues, which is why it performs better when used for post processing.

It would be nice to see arcwelder lib get used directly if possible (rather than copying the functions). As I mentioned in the feature request (to add the new arc welder "3d arcs" code to orca https://github.com/SoftFever/OrcaSlicer/issues/3465) I'm interested in working on that, but I'm just waiting for time, and waiting to see if anyone else is already working it.

[ninja-]

I looked deeper, and looks like G2/G3 instructions are not recommended for modern klipper-based printers, since it does very little, and klipper unwinds that back to G1 instructions with less-than-ideal algorithm. It's better to ignore larger file size, and let Orca create G1 instructions with user-specified resolution.

If you do print G2/G3 make sure you use printer.cfg

[gcode_arcs] resolution: 0.1

but it will crash of CPU usage on less-powerful device like Nebula Pad, with 0.2 working fine.

I've read somewhere that using G2/G3 instructions creates very precise motor movements that's not possible with G1? Well, that must have been not true at all, at least with Klipper.

I recommend you try slicing at max resolution with no Arc Fitting with Orca and see your print quality. Personally I use 0,001 slice gap closing and 0,012 resolution, and I should have a first print tomorrow...

[ninja-]

ah, one downside of NOT using Arc Fitting - worse print time? I don't even know if the estimates are even real. Estimates could be false, but even if they are true, you should be able to match the lower print times by manipulating resolution

[ninja-]

See the klipper code for G2/G3. It's just a few lines of code that converts it into series of G1, simple algorithm, that's probably not hard to match or beat by a good slicer.

https://github.com/Klipper3d/klipper/blob/7a74888b43a7e640a32fd18ae69d9dbdeaf55719/klippy/extras/gcode_arcs.py#L4

and regarding file size, I think modern klipper-based printers don't suffer from bandwith issues with streaming gcode at high speed

[ninja-]

I have been messing with arcs too (as part of a side quest to get printing complex geometry models from octoprint without stuttering) and have found that arc fitting is indeed pretty hit and miss. If any gcode gets interleaved between G1 instructions the arc fitting code will not be able to make them into arcs. If the z height changes between instructions arc fitting is also out. This means it doesn't work in vase mode, and it doesn't work with anything that adjusts the flow rate between line segments.

if you're hitting bandwith limits, what's your hardware and printer?

[evilDave]

yeah, i have an ender 3 v2 neo and I am using mriscoc firmware, and the raspberry pi is a pi4 8G. Apparently the marlin base code does a good job of changing the G2/G3 back to "straight line" stepper moves but it can do this at a very high resolution. Apparently, it's a "rule of thumb" in CNC hardware design that you make the high resolution linear calculations at the last possible moment, ie "closest to the hardware".

i was testing with a 100mm cylinder sliced at high resolution with feed rate of 100mm/s. octoprint sending the file to the printer would overwhelm the pi CPU and not be able to send enough commands in time (the problem was exacerbated by my leaving the pi in GUI mode rather than CLI mode) so the printer would lag every couple of seconds

I still feel there will be some limit to the resolution you can use if you send G1 to the printer that could be alleviated by using G2/G3 I also get the niggling feeling that "something" is getting lost in the curve to line to curve to line back and forth caused by the workflow onshape>orca>firmware>hardware which give you "actual curves"->fit mesh stl->extrapolate curves G2/G3->quantise linear stepper moves

[evilDave]

yet another "interesting thing" - as the resolution setting is used in the arc algorithm to determine if the arc is close enough to the "jagged straight lines" of the stl (which it is assuming is what you want: i.e. it is trying to fit an arc that is "not too different" from the faceted line segments you have given it), as you increase the resolution, to basically disable the arc fitting for any other curves. (this is another reason i'd love to see slicers support real geometry as input rather than only mesh data)

[ninja-]

yeah, i have an ender 3 v2 neo and I am using mriscoc firmware, and the raspberry pi is a pi4 8G. Apparently the marlin base code does a good job of changing the G2/G3 back to "straight line" stepper moves but it can do this at a very high resolution. Apparently, it's a "rule of thumb" in CNC hardware design that you make the high resolution linear calculations at the last possible moment, ie "closest to the hardware".

right, so for marlin the use case will be different, for klipper it's probably best to stay with G1

yet another "interesting thing" - as the resolution setting is used in the arc algorithm to determine if the arc is close enough to the "jagged straight lines" of the stl (which it is assuming is what you want: i.e. it is trying to fit an arc that is "not too different" from the faceted line segments you have given it), as you increase the resolution, to basically disable the arc fitting for any other curves. (this is another reason i'd love to see slicers support real geometry as input rather than only mesh data)

make sure you are importing raw .step files. some people say it's the same result as importing .stl, because Orca tesselates internally, but I don't think that's true - I haven't found any open source tool which can produce quality stl that slices without artefacts, and Orca tesselates step files perfectly for some reason

and if you really have to use an STL, make sure to use fusion360 to refine the raw model, because I found that all open source tools like FreeCAD fail to properly tesselate 2D and 3D arcs even at highest resolution, while fusion always understood them perfectly

[ninja-]

I've done two prints for comparison, and the G1 sliced at max resolution(0,0001 actually - processing time was not terrible) was just as good, and printing time was even faster than Orca estimation. So with my Klipper printer, I'll stay with no use of arc fitting.

[foreachthing]

@ninja- , we have an old Ultimaker 2; I noticed that when I print any round shapes, it struggles around bends. Unless I use low res STLs. It's like it prints a line, then another and then another - very "forced" motion. But when printing arcs (G2/G3) the motion is smooth as silk and it seams much faster (not tested!) and the printer makes a totally different noise. I'm just curious if you can make the same observations.

[evilDave]

I would agree that you will want totally different things if you are using klipper to marlin... I have been using onshape, and in fine mode the stl mesh produced seems very good.

When you sliced at 0.0001 resolution, look at the gcode after - how many arcs are generated (vs say 0.01)? When I bump up the resolution like that there are very few arcs generated. For example, a single layer of a 100mm cylinder might be 100 G1 commands, with arc fitting at 0.01 resolution the same layer will be 5 or 10 G1s and 4 or 5 G2/G3s, set the resolution to 0.001 and it will be 95 G1s and 1 G2 - at that resolution the arc is not a good enough match to the angled lines in the source mesh. Orca definitely tesselates internally (the processing code from what I can see only operates on line segments as input), but perhaps it does a better job than the open source tools you have tried?

@foreachthing that is very much how I would describe what happens on my ender when I print a "very detailed" cylinder without arc fitting - the number of gcode commands to pass to the printer just is overwhelming.

[ninja-]

So we know about Klipper, we know about Marlin, but we don't know much about Bamboo printers. I just noticed these are the only profils with Arc Fitting enabled by default. We don't know exactly how they convert these gcodes on printer side, if it's beneficial.

When you sliced at 0.0001 resolution, look at the gcode after - how many arcs are generated (vs say 0.01)? When I bump up the resolution like that there are very few arcs generated. For example, a single layer of a 100mm cylinder might be 100 G1 commands, with arc fitting at 0.01 resolution the same layer will be 5 or 10 G1s and 4 or 5 G2/G3s, set the resolution to 0.001 and it will be 95 G1s and 1 G2 - at that resolution the arc is not a good enough match to the angled lines in the source mesh. Orca definitely tesselates internally (the processing code from what I can see only operates on line segments as input), but perhaps it does a better job than the open source tools you have tried?

I think at default resolution it finds all the arcs properly, so without false G1s in the middle. Maybe I was overly cautious, and slicing at lower resolution than default only generates gcodes that are beyond printer precision and thus don't change anything on the print - but I don't want to test that theory with a few hour print at the moment.

But one surprising thing is, it finds all the arcs on inner wall, but absolutely zero arcs on outer wall which is just offset from it. This looks like a bug

[evilDave]

@ninja- is there anything that is causing extra gcode between G1 command on the outer wall? I am thinking like “slow down for overhangs” or “precise walls”. If there is anything between the G1 command the arc fitting won’t be able to convert any of those G1s into o arcs.

[ninja-]

I tried all mixes of precise walls, inner/outer/inner etc. etc. disabling and enabling, and none of them made all arcs be detected properly. I actually I found that it varies by layer, on some it will find the inner, on other the outer (the arcs vary slightly in size on different layers). If outer wall is printed with G1, and inner with G2, I would be quite skeptical in using Arc Fitting, as that could introduce rounding errors reducing print quality...

[ninja-]

@evilDave Slow down for overhang was actually the key, thank you! so I verified it layer by layer that it perfectly catches all the oval arcs now! and gcode dropped from 365k lines to 347k lines. Time estimation just briefly, from 2h53m to 2h51m but it's usually an hour off anyway...

Maybe the pipeline could change a bit to slow down these arcs using a macro before G2/G3 without breaking arc fitting in the future? My overhangs are not big, but quite significant compared to line width, so on some layers they were dropping into >25% auto-slowdown range, it seems.

I was able to keep Arachne, Inner/Outer/Inner and Precise Wall without affecting the arcs.

[ninja-]

https://github.com/bambulab/BambuStudio/issues/2040 https://github.com/bambulab/BambuStudio/issues/2846

upstream reports

[evilDave]

Just to double back here with some more info:

I ran into an example where the arc fitting just would not work. My usual workflow is to export from onshape as a fine stl, then arc fitting in orca. Well, this one model just would not convert G1s around the outer perimeter to arcs, it did in a few places but not everywhere. So I took the output gcode that orca had done its best on, and ran it through ArcWelder CLI: 27174 moves down to 26436 - basically all of the walls are now arcs.

I've suspected that due to the resolution value being used to check for arc fitting, the higher resolution you go, the less it is able to fit arcs. IMHO these setting need to be two different values. But anyway, I remembered that someone suggested that importing STEP files is able to do better than even fine stl mode... so I gave it a go...

WOW. Orca is now able to do a pretty good job of making arcs, 15200 moves for the same model, however, arcwelder is still able to do better, post processing the file to 10269!

So I wondered if arcwelder was being further hampered by what orca was trying to do, so i sliced a step file without arc fitting and then ran it through arcwelder: 21573 moves becomes 10710 in about 3 seconds (long) - and though that is more moves, the file size is 2.9MB rather than 3.6MB.

The print time estimate was about 2:45 for the original file, and it 2:35 now - I will run both prints to check the time and quality for any differences.

I am feeling like arc fitting in orca/babmu/etc.etc. is a bit of a bust. It doesn' do as good of a job as ArcWelderLib can do.

I think my new process will be: export step files from onshape into orca, slice with arc fitting off, process with arcwelder (via octoprint acrwelder plugin). One downside that I can see with that is that the initial gcode file size (12MB vs the final arcwelded 2.9MB) will be large but I don't see that making a difference... the place where filesize matters is transferring over serial to the (mriscoc/marlin firmware) printer.

[DARKFiB3R]

I think my new process will be: export step files from onshape into orca, slice with arc fitting off, process with arcwelder (via octoprint acrwelder plugin).

Can you please go into a little more detail about the steps taken to do that?

I have a P1S now, and no longer have my Ender 3 up and running (or the RPi/Octoprint).

Thanks.

[evilDave]

I am assuming you are asking about the arc welder step? Without octoprint there are two options: use the CLI version of arcwelder (good instructions in that repo: https://github.com/FormerLurker/ArcWelderLib) on the gcode output from orca, then upload the resulting gcode to the printer; or you can set that up as a post processing script in orca (I have not done that, so you’d need to check that docs)

I will also add that orca does “okay” with the step files, but you can do even better with higher quality exported stl files from your cad software.

[DARKFiB3R]

Thanks :)

[CodeMasterCody3D]

I've copied setting from my ender over to orca slicer using Bambu x1c profile I then modified the gcode to not perform some actions due to it not being a bambu printer so I see the gcode for G2 commands show up on the chimney of the 3d benchy on bambu profile but with my orca slicer profile that's for the ender doesn't show G2 arc command for the chimney. I can't add octoprint server information on the bambu profile side so I'm stuck importing then uploading manually to octoprint server and starting it manually. I'd like to figure out why arc fitting isn't working properly on the ender profile but works fine on the bambu profile modified for the ender. (First of all I had to enable ARC_SUPPORT, ARC_P_CIRCLES, & CNC_WORKSPACE_PLANES to get spiral ZHOP to actually work now I'm realizing the first time I tried bambu code on the ender it didn't print circles, it's because the arc support wasn't on. So now I want to perfect a profile for the ender to print wonderfully using orca but can't seem too. Hope this will help someone.

[CodeMasterCody3D]

Trying out arc welder on my octoprint now

[inspectionsbybob]

Different Question arc-welder in 2.0 Orca...

My "enable arc-welder" is greyed out... so something else is enabled that disables arc-welder... any ideas?

[evilDave]

do you mean "arc fitting" checkbox? As far as I know there is no "enable arc-welder" in orca, just the custom/similar implementation. And I just had a play around and I don't see that checkbox greyed out ever.

[CCS86]

Different Question arc-welder in 2.0 Orca...

My "enable arc-welder" is greyed out... so something else is enabled that disables arc-welder... any ideas?

For some reason "extrusion rate smoothing" disabled arc fitting.

[inspectionsbybob]

Thats it... sorry

---

Need a quick answer? Call our booking line at (301) 208-8289, or book your inspection on our website 24/7. Don't wait for a response as someone else may get the spot you want... call Today!

Bob Sisson, ACI, BVI Inspections by Bob, LLC www.inspectionsbybob.com @.*** MD Lic#29666; ASHI Member #212016

On Sat, Apr 6, 2024 at 11:48 AM CCS86 @.***> wrote:

Different Question arc-welder in 2.0 Orca...

My "enable arc-welder" is greyed out... so something else is enabled that disables arc-welder... any ideas?

For some reason "extrusion rate smoothing" disabled arc fitting.

— Reply to this email directly, view it on GitHub https://github.com/SoftFever/OrcaSlicer/issues/3521#issuecomment-2041122824, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFJ2GY2CBC6LN3ONLER2TBTY4AKNXAVCNFSM6AAAAABBP3NAAWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBRGEZDEOBSGQ . You are receiving this because you commented.Message ID: @.***>

[github-actions[bot]]

Orca bot: this issue is stale because it has been open for 90 days with no activity.

[github-actions[bot]]

Orca bot: This issue was closed because it has been inactive for 7 days since being marked as stale.