Enable ARC (G2, G3), possible as output filter

[ProfDrYoMan]

It would be nice to have a possibility to enable arc mode (G2, G3).

See https://github.com/prusa3d/PrusaSlicer/issues/24#issuecomment-466184640

It could be done with an output filter on the pre-final g-codes.

[Andrei-Pozolotin]

G2/G3 support is a must for high-speed printing, otherwise people are forced to use insane workarounds:

https://github.com/FormerLurker/ArcWelderPlugin

Arc Welder: Anti-Stutter
Converts G0/G1 commands to G2/G3 commands.

[plampix]

Indeed, I just discovered the plugin. There is a command-line version as well, which could be used as a post-processor. Just being able to visualize G2/G3 would be nice (prusa-gcodeviewer crashes on a file with G2/G3).

[bttguy]

+1 for arc support

[tcurdt]

Is there a way to run Arc Welder as a post-processor by running the cli command directly from the Slicer?

[treyd3]

One more call for arc support

[plampix]

Is there a way to run Arc Welder as a post-processor by running the cli command directly from the Slicer?

There might be an easy solution for that, are you running a Unix bases OS?

[tcurdt]

There might be an easy solution for that, are you running a Unix bases OS?

I am on macOS.

[plampix]

As a workaround you could use FUSE Using https://github.com/sholsapp/fusepy-base/blob/master/fusepybase/passthrough.py and the following script, I'm able to run the arcwelder command and upload the file to my octopi instance:

`

!/usr/bin/env python

from future import with_statement

import os import sys import errno import yaml

from fuse import FUSE, FuseOSError, Operations from passthrough import Passthrough from pathlib import Path

class ArcFS(Passthrough): def init(self, root): · super(ArcFS, self).init(root) · with open(self.root + '/.OctoPrint.yaml') as f: · · self.octoprintConfig = yaml.safe_load(f)

def release(self, path, fh):
·   if not os.path.basename(path).endswith('_aw.gcode'):
·   ·   os.system('ArcWelderConsole ' + self._full_path(path) + ' ' + self._full_path(path).replace('.gcode', '_aw.gcode'))
·   ·   self.unlink(path) 
·   ·   os.system("curl -k -H 'X-Api-Key: " + self.octoprintConfig['APIKey'] + "' -F 'select=true' -F 'print=true' -F 'file=@" + self._full_path(path).replace('.gcode', '_aw.gcode') + "' '" + self.octoprintConfig['URL'] + "'")
·   return os.close(fh)

def main(mountpoint, root): FUSE(ArcFS(root), mountpoint, nothreads=True, foreground=True)

if name == 'main': main(sys.argv[2], sys.argv[1]) ` You provide two arguments, the original directory, and the directory that does all the magic. You should provide an .OctoPrint.yaml file containing the keys 'APIKey' and 'URL' to access your octoprint instance, if you have one.

Maybe this could help in the meantime (I'm not a python programmer btw)

[tcurdt]

@plampix thanks for the suggestion - but that's a bit too much of a hack for me :) Plus FUSE is unfortunately a little problematic on macOS these days. One could also create a folder that is watched, then gets transformed and then uploaded the octopi. So no FUSE needed. But even that is - meh.

[plampix]

Ehm, just adding a post-processing script in printsettings should also work. Didn't think of that...

[tcurdt]

Didn't think of that...

Wasn't aware of that option either :-D

[giuliandenicola1]

+1 for direct arc support within Prusa slicer

[amoose136]

I think something like this would be a fantastic addition that significantly improves print times and quality. Additionally if you have a means of recognizing arcs, you may be able to use that to make smarter placement of modifier meshes. Eg: I use a bunch of brass threaded inserts. The inserts work better with 3 or 4 walls rather than 2 so I frequently add a modifier mesh to increase the number of wall lines around the threaded inserts. This must be manually aligned currently. If you can detect arcs in a mesh, you could have a tool that would snap a modifier mesh’s center (or axis if a cylinder) to that of a detected arc. Of course this would only work if the insert is in the Z direction unless the algorithm worked prior to the gcode generation phase.

[batata004]

Would be a really nice addition to this software. Any of you managed to make the integration of PS with Arcwelder inside PS software? Or the only option so far is export the PS gcode, save in a temporary location, load that file to Arcwelder, generate the new GCODES and save the final GCODE to the permanent location? Is this the most efficient way doing so using PS? Or is there a button/plugin integration that I can apply to PS in order to make it post-process the GCODE all inside PS?

[sslupsky]

Unfortunately, Arcwelder requires some changes to the firmware. Perhaps Arcwelder could be integrated directly into slicer?

See the following related issues:

https://github.com/prusa3d/Prusa-Firmware/pull/2657 https://github.com/prusa3d/Prusa-Firmware/issues/1406

[gdeconto]

+1 for adding ability to view G2/G3 in prusaslicer, as well as ability to output G2/G3, as there are versions of marlin that already support them

[FormerLurker]

You can use the built in post processor to call ArcWelder for the time being. See instructions here. Please note that arcs are not fully compatible with the current MK2/Mk3 firmware, as it fails to produce accurate geometry for arcs of a small radius (between 0-5mm approx). Please read about the firmware compensation workaround, which will produce accurate geometry at the cost of some compression.

FYI, I agree this is a workaround for native arc support, but it's not particularly insane IMHO :)

[sslupsky]

@FormerLurker This good work you are doing is great and definitely not insane ... goodness, the matter of poor gcode generation has been ignored for many years. I suppose to root of a lot of the related problems with poor gcode began with the development of the early slicers that used a mesh geometry as input instead of a 3D solid geometry. Now they are entrenched and inertia just keeps them going. Native support for STEP files in PrusaSlicer would go a long way to improve the gcode. Though, it needs to be done properly. For instance, avoid what OpenSCAD does with the approximation of curves with straight segments.

[jack9603301]

The g2/g3 conversion function is only an external tool call. However, it is even necessary in some cases. Hope to achieve.

[gudvinr]

bambulab added support for generating arcs/circles and have a support for STEP which also covers #4989

[karl-nilsson]

I've also been working on an experimental slicer with STEP and arc support. I use CavalierContours, rather than clipper for polyline clipping/offsetting, which may be relevant for arc support in PrusaSlicer.

https://github.com/karl-nilsson/sse

[bubnikv]

@FormerLurker BTW bits of your arc fitting code were integrated into Bambu Studio without accreditation.

[FormerLurker]

It is actually in the about page, but links to the wrong repo. I will submit an issue eventually. Thank you so much for looking out for me!!

[insane78]

So Prusa guys? We are waiting for this feature, you can copy-paste the orcaslicer arc fitting. tnx to @FormerLurker

[gudvinr]

We are waiting for this feature

What for?

Arc fitting is more or less pointless for models that actually have real arcs (i.e. imported from STEP) because those parts need to be accurate and arc fitting is opposite of accurate.
Artistic models don't need that and those usually will be printed printed on resin printer anyway. When these parts are big and printed with FDM, slicing resolution likely won't be that high to benefit from arcs too.

Modern printers also don't really have issues with bandwidth for streaming gcode too, so savings are negligible and more or less irrelevant for e.g. Klipper. And for Marlin you can have MEATPACK enabled if you print from octoprint and really need those extra bits per second.

What would be really useful is arc generation from STEP geometry so you don't need to depend on mesh resolution if you already use STEP.

[neclimdul]

@gudvinr Are you supporting preserving arcs should be pursued, fitting arcs shouldn't? If so that makes a lot of sense. At least separating the features with preservation being a more promising improvement.

I think people get excited about fitting from the place the arcwelder plugin comes from, trying to compensate for the lack of arc use so fixing the underlying problem is always better

That said, fitting as a modifier also sounds like a cool feature that could try to clean up old STL's floating around.

[FormerLurker]

@gudvinr,

I have no skin in this really, especially since ArcWelder can already be added as a post processor. However, I feel it's important to mention a few things about your post:

Arc fitting is more or less pointless for models that actually have real arcs (i.e. imported from STEP) because those parts need to be accurate and arc fitting is opposite of accurate.

This is true as real arc commands can be used, and that is great! However:

arc fitting is opposite of accurate

This isn't exactly true. The fitting algorithm has definable accuracy, so it is exactly as accurate as you want it to be. All modern machines have tolerances, etc, and unlimited accuracy is impossible. The default resolution is +- 0.025mm, which is pretty good. Need more? Just dial it down and get less compression OR slice with a higher resolution and get BETTER accuracy. Arc welder can compress more the more resolution there is in the source gocde file, though it takes longer to run.

Modern printers also don't really have issues with bandwidth for streaming gcode too

This is based on your gocde file, slicing settings, and a million other factory. Arc welder was written exactly due to many complaints about gcode streaming issues. The fact is many people stream gcode. Lots of them don't even know they are having bandwidth issues and spend tons of unnecessary time attempting to tune their gcode. Even cura's default resolution was turned down due to the issues, which results in less accurate geometries.

And for Marlin you can have MEATPACK enabled if you print from octoprint and really need those extra bits per second.

This is apples and oranges. MEATPACK reduces the bandwidth per gocde and arcwelder reduces the number of gcodes. Several people have looked into the bandwidth reductions, and these two items are complementary. The results are entirely based on your exact gcodes.

Anyway, my view of arcwelder is that it is a lossy (but tunable) compression algorithm for gcode. Compression is useful, but not always needed. If used correctly, you will get identical results with fewer streaming issues and a smaller file size.

[Sineos]

IMO Arcs make absolute sense for reducing streamed Gcode bandwidth but (unless someone can prove me otherwise), I'd consider the accuracy argument a myth:

1. When exporting from CAD to STL the first approximation is done (Typically around 0.1 mm and called "Deviation", "Surface Deviation" or "Chord Height", depending on the CAD system and settings)
2. The slicer then takes the next approximation by turning the STL into Gcode (Precision depending on slicer and / or settings)
3. Arc-welder then approximates the distinct Gcode segments back into an arc (Precision depending on settings)
4. The printer firmware then approximates the arc back into distinct segments (Precision depending on settings)

Overall, 4 lossy operations: The first two cannot be avoided, but the last two are kind of superfluous

[gudvinr]

@FormerLurker, I was only meant that integrating arc fitting as built-in post-processor is somewhat hacky workaround rather than the solution to a problem.

The fitting algorithm has definable accuracy, so it is exactly as accurate as you want it to be. All modern machines have tolerances, etc, and unlimited accuracy is impossible.

As @Sineos pointed out, slicing process basically piles up errors by using multiple post processors between expected geometry and actual printer moves. Ideally, STEP arcs to gcode arcs should be translated without going STEP > Mesh > gcode > another gcode.

If there's no STEP, that's different question.

This is based on your gocde file, slicing settings, and a million other factory. Arc welder was written exactly due to many complaints about gcode streaming issues. The fact is many people stream gcode. Lots of them don't even know they are having bandwidth issues and spend tons of unnecessary time attempting to tune their gcode. Even cura's default resolution was turned down due to the issues, which results in less accurate geometries.

Sure, but back in the days a lot of printers still had AVR boards which now replaced with more powerful 32-bit boards pretty much by everyone. Baud rate sometimes also increased, e.g. I had 250000 set in stock firmware on 2020 printer.

Moreover, even if you have a lot of gcode but your printer is slow, baud rate won't matter that much because printer will consume gcode slower than it receives is. Of course it depends on slicing settings, speed, actual part geometry, yadayadayada. More important thing here that most "balls to the wall fast" guys nowadays use klipper where gcode isn't streamed over serial, thus makes this issue less relevant for them.

Also parts that will benefit from arc fitting most most likely aren't mechanical parts because even when those have significant amount of curves, those usually printed slower for strength anyway.

Several people have looked into the bandwidth reductions, and these two items are complementary.

Sure, it isn't even questionable. My point was that even if you have bandwidth issues, there are options that might help you with that without using gcode post processing. Drawback here is that I believe it's off in most pre-built firmwares.

So, basically, if proper arc generation will ever be implemented, AW will only be useful for people who print parts with lots of curvature from mesh through octoprint and do it relatively fast while not using klipper.
It's not bad nor useless, I just don't think it makes sense to implement that if proper arc generation exist.

Although, now that MK4 with IS exists I wonder if octoprint users will hit its limits given that prusa still uses 115200 baud in their config last time I checked.

[FormerLurker]

@gudvinr,

I get it. This is a thread about adding a post processor to prusa slicer. I am not here to say that should or should not happen. I will leave that up to you all. I just wanted to clear up some subtleties regarding what arcwelder does, nothing more. I appreciate everyone's thoughtful responses, and I have enjoyed the thread, which is obviously full of passionate users and developers of both projects.

[osmanoney]

selam. prusaslicer de son versiyon 1.2.0 indirdim bu g-code içinde "Postprocessed by ArcWelder" altı çizili değil. bu kod aktif mi ? sosyal mediada youtube videolarında altı çizgili __olması lazım diyorlar size sormak istedim

[lukasmatena]

Implemented in PrusaSlicer 2.7.0-alpha1. Closing.

@FormerLurker Thanks again for the effort you have put into it.

[bubnikv]

arc fitting is opposite of accurate

There is a difference in post processing a G-code vs. doing the arc fitting on raw slices.

All slicers do decimate raw tool paths, otherwise the G-code would be too dense. Arc welder integrated into slicer merges arc fitting with raw tool path decimation, thus the resolution of the G-code with arches should NOT be worse than with arc welder disabled.

so 21. 10. 2023 v 7:47 odesílatel Lukáš Matěna @.***> napsal:

Implemented in PrusaSlicer 2.7.0-alpha1 https://github.com/prusa3d/PrusaSlicer/releases/tag/version_2.7.0-alpha1. Closing.

@FormerLurker https://github.com/FormerLurker Thanks again for the effort you have put into it.

— Reply to this email directly, view it on GitHub https://github.com/prusa3d/PrusaSlicer/issues/4352#issuecomment-1773683630, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABMPSI67ZKC2PLPOBHMC2ALYANOVPAVCNFSM4NTKDUTKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCNZXGM3DQMZWGMYA . You are receiving this because you commented.Message ID: @.***>

[rubin110]

Just want to confirm, if I set "Arc fitting" to Enabled: G2/3 I J that I no longer need to run the arcwelder binary as part of post processing?

[lukasmatena]

@rubin110 Exactly, the G2/3 G-codes are generated without any postprocessing.