New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enable ARC (G2, G3), possible as output filter #4352
Comments
G2/G3 support is a must for high-speed printing, https://github.com/FormerLurker/ArcWelderPlugin
|
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). |
+1 for arc support |
Is there a way to run Arc Welder as a post-processor by running the cli command directly from the Slicer? |
One more call for arc support |
There might be an easy solution for that, are you running a Unix bases OS? |
I am on macOS. |
As a workaround you could use FUSE ` from future import with_statement import os from fuse import FUSE, FuseOSError, Operations class ArcFS(Passthrough):
def main(mountpoint, root): if name == 'main': Maybe this could help in the meantime (I'm not a python programmer btw) |
@plampix thanks for the suggestion - but that's a bit too much of a hack for me :) |
Ehm, just adding a post-processing script in printsettings should also work. Didn't think of that... |
Wasn't aware of that option either :-D |
+1 for direct arc support within Prusa slicer |
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. |
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? |
Unfortunately, Arcwelder requires some changes to the firmware. Perhaps Arcwelder could be integrated directly into slicer? See the following related issues: |
+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 |
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 :) |
@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. |
The g2/g3 conversion function is only an external tool call. However, it is even necessary in some cases. Hope to achieve. |
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. |
@FormerLurker BTW bits of your arc fitting code were integrated into Bambu Studio without accreditation. |
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!! |
So Prusa guys? We are waiting for this feature, you can copy-paste the orcaslicer arc fitting. tnx to @FormerLurker |
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. 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. |
@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. |
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:
This is true as real arc commands can be used, and that is great! However:
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.
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.
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. |
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:
Overall, 4 lossy operations: The first two cannot be avoided, but the last two are kind of superfluous |
@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.
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.
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.
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. 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. |
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. |
|
Implemented in PrusaSlicer 2.7.0-alpha1. Closing. @FormerLurker Thanks again for the effort you have put into it. |
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
<#4352 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABMPSI67ZKC2PLPOBHMC2ALYANOVPAVCNFSM4NTKDUTKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCNZXGM3DQMZWGMYA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Just want to confirm, if I set "Arc fitting" to |
@rubin110 Exactly, the G2/3 G-codes are generated without any postprocessing. |
It would be nice to have a possibility to enable arc mode (G2, G3).
See #24 (comment)
It could be done with an output filter on the pre-final g-codes.
The text was updated successfully, but these errors were encountered: