Welcome to ArcWelderPlugin Discussions!

[FormerLurker]

👋 Welcome!

We’re using Discussions as a place to connect with other members of our community. We hope that you:

• Ask questions you’re wondering about.
• Share ideas.
• Engage with other community members.
• Welcome others and are open-minded. Remember that this is a community we
  build together 💪.

To get started, comment below with an introduction of yourself and tell us about what you do with this community.

[ETE-Design]

@FormerLurker Did you have time to look at the Non-Planner Compiling for Windows in VSCode yet? Not to stress you :-)

[FormerLurker]

You aren't stressing me :) I have been looking at it. I'm still trying to get Boost to build, or to find appropriate binaries. I think I'm over-complicating things a bit, but there is definitely a learning curve. I am pretty darn sure it can be done though.

[ETE-Design]

@FormerLurker Aha, totaly misunderstod dropped then :-) But nice that more and more people use your work :-) Soon I only need to find firmware for my 3D Printer who is cable of Filament Mixing, and at the same time can communicate with two or more boards... I Know Klipper can, but seems like noone have looked at the Mixing Filament part for it :-(

[FormerLurker]

Check this out for marlin: http://www.keep-art.co.uk/printhead.html

[ETE-Design]

@FormerLurker Know Marlin can handle Mixing Factor... Problem is that I need some firmware who can handle 2 Mainboards at the same time and communicate between them, and also handle Mixing Factor... Seems like Klipper / Marlin can't do both... And Kevin at Klipper seems like he going his own way now, and issies / requests and stuff he dosen't like to be on GitHub...

[ETE-Design]

@FormerLurker Sorry again, to many things not related to your great development :-D Should really find another place to disguess with you ;-)

[ETE-Design]

@FormerLurker It's me again... Time had gone, so mabye you had found some time to look at the non-plannar compiling for Windows? A Friend of mine have just made a special prototype heatblock for this purpose :-)
Best way would be find a way to grap the Non-Plannar code from https://github.com/Zip-o-mat/Slic3r/tree/nonplanar and merge it into something like https://github.com/supermerill/SuperSlicer cause SuperSlicer already compile for multiple OS'es

[thegigi]

@FormerLurker Excellent plugin, nice GUI, well documented. easy to use . I tried it on Octoprint and works perfectly. Are you using a curve (circle) fit algorithm or an interpolation algorithm ?

[FormerLurker]

I've tried it several different ways, but I got rather poor results from the various fitting algorithms I tried. However, there are some useful constraints on the arc that I've taken advantage of. The most important one is that the starting and ending points of the arc must lie exactly on the toolpath. Since the first and last points are not up to me, I just have to choose a point along the toolpath between the start and end point, and use algebra to find a circle that runs through all three points. Then, I just see how well the circle fits the other points on the arc. I find the maximum deviation between the given circle and all the points along the arc, and if it doesn't match the parameters, it is rejected. Recently, I've added another step, where I try to fit a circle to all of the remaining points to see if the new one can pass the maximum deviation tests. I search each point and find the one with the lowest maximum deviation (though I also tried least squares). In reality, this extra step only adds a few more percent compression, but it doesn't take too long, so I figured what the heck :)

[thegigi]

Some million years ago i worked an algorithm based on circle fitting (least squares) stable and that gave rather good results. I can share it if it helps (and if i find it :)).

[FormerLurker]

I can share it if it helps (and if i find it :)).

Only if it can guarantee the start and endpoint of the arc are 100% along the circle. Feel free to check out the source (segmented_arc and segmented_shape classes) to see how it's currently working. I actually think the fitting ATM is quite exceptional, though there definitely are always things that can be improved! Probably the weakest part of the current algorithm is that it requires the circle to pass directly through at least 3 points from the original gcode, when a slightly better fit might be found that only passes through 2 (the start and endpoint). However, the alternatives I've tried so far have not been worth the extra computational cost.

[thegigi]

hmm.. by definition the ends of a fitting curve are 100% on the curve but not necessarily belong to the set of input gcode points (however should be within the accepted error) unless the input set has only 3 points in which case yes the resulted circle should pass exactly through the 3 points.

[FormerLurker]

< but not necessarily belong to the set of input gcode points

This is what I meant. Just imagine walking through the points along the toolpath, and trying to move some of the points so that they line up with a fitted curve where no points line up exactly with the original toolpath. It introduces a whole new set of potential errors, even altering straight lines before and after the curve. What you say about 3 points is exactly right, so that's why I always use 3 points from the original toolpath, and use that to generate the curve, then test it to see if it fits within the specified resolution. Basically always using 3 points to generate the curve, and always including the initial and final point in that calculation makes everything simpler, and prevents modification of all but the replaced gcodes (the G1s that are being converted to G2/G3).

[thegigi]

I think you are right, interpolation makes more sense than curve fit because the G1s were previously computed accurately by the slicer as points on a circle so if they don't fit this simply means that the circle ends there and the acceptable error should be just slicer rounding error. My problem at that time was to solve this for "clouds" of 2D points generated by scanning and affected by more or less random errors. Using curve fitting in your case deforms the shape and may also create inconsistencies with previous and next layer. Imho the only true solution is to have g2/g3 directly from slicer. Nevertheless congrats for the nice plugin created. If you have a particularly "stutter- stubborn" piece of gcode i can try to run it through my old algorithm (if i find it :) )to see how it works.

[seantapscott]

I would disagree on arc gcode generation in the slicer. Ideally the root source model and software that created the model would create a file format beyond stls which actually supports different shape types. Constraining by triangles will always give flat edges of varying dimensions.

…

On Fri, Feb 12, 2021, 5:53 PM thegigi ***@***.***> wrote: I think you are right, interpolation makes more sense than curve fit because your G1s were previously computed accurately by the slicer as points on a circle so if they don't fit this simply means that the circle ends there and the acceptable error should be just slicer rounding error. My problem at that time was to solve this for "clouds" of 2D points generated by scanning and affected by more or less random errors. Using curve fitting in your case deforms the shape and may also create inconsistencies with existing and next layer. Imho the only true solution is to have g2/g3 directly from slicer. Nevertheless congrats for the nice plugin created. If you have a particularly stutter "stubborn" piece of gcode i can try to run it through my old algorithm (if i find it :) to see how it works. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#131 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AE5J4UHFHTK3SJUSLJ3MAJTS6WWNDANCNFSM4WQWURTQ> .

[thegigi]

In principle I agree that the stl may not be the most accurate way to transport the shape but the (actual) slicers output complexity cannot be more than arcs (yet). Not to forget that, in principle, an end-device with Arduino has much less computing power and precision than a nowadays 64 bit CPU. This is pretty much like the dispute between bitmap and vector formats finally won (but increasing the end-device computing power needs) by the PDF.

[illusionmanager]

The next step to improve this even further would be support for spline curves in the firmware. This could remove the edges between the curves even more and get better compression for general smooth curves.

I do have a question. You say that it also (in some example) reduced the number of retractions and extrusion commands. But how does that work, when the end points are exactly the same?

[FormerLurker]

@illusionmanager, I'm looking into the Bezier curve implementation. See this issue in the ArcWelderLib repo (the core algorithm).

Regarding reducing the retraction/extrusion commands, it's not that your printer will perform fewer retractions total, or extrude less, but rather that fewer commands will be sent in total. For retractions, this really only will work if you are using a slicer that has a 'wipe' option enabled, since these wiping retracts can follow circular paths. Regarding the endpoints, they MUST be the same as the original gcode. One of the requirements of an arc command is that the generated arc is concluded at the target coordinates. Obviously the arc must start at the current position too, so the endpoints of the movement must always match, though the toolpath will vary slightly (controllable by the resolution).

Does that answer your question?

[illusionmanager]

yes thank you!

[illusionmanager]

I'm a first time user of the arc-welder plugin. I made this tiny cylinder and saved it both with and without arc-welder (in default settings).
Using arc welder, the file size went from 903kB to 519kB. However the print time more than tripled.
For some reason arc-welder goes very slowly on some parts of the infill as can be seen in the video. I don't think that is supposed to happen. Perhaps some of the default settings in arc-welder aren't correct.

MOV_0348_1.mp4

[illusionmanager]

btw this is send to a Snapmaker 2.0. Does that have firmware issues?

[FormerLurker]

I'm not sure if your firmware has any issues. I am building a development printer right now that is intended to allow me to swap boards and firmware rapidly (thanks sponsors and patrons!), so I hope to learn more about this soon. I'm maybe 50% complete, and expect to be up and running in a month or two.

Regarding the ArcWelder.exe version, yours does have a known issue. Please see this release, look at the bottom for the assets, download the appropriate asset for your OS, and replace the executable with the version you download (you may have to hunt through the zip to find it, should be in a bin folder or in the root depending on which one you download).

After you replace the exe, try printing that cylinder again. Consider posting all 3 versions of the gcode (an unwelded gcode file produced with arcwelder disabled, the old welded version that is running slow, and the new version you create from the new executable).

Please let me know how it goes!

[illusionmanager]

unfortunately, it didn't help. The file size is a tiny bit different. but the printer seems to behave the same. The section of gcode that prints the infill is exactly the same for both versions.
included the various versions (renamed them with extension .txt otherwise I couldn't include them here)

arc-welder-1.1.1.gcode.txt
arc-welder-1.1.0.gcode.txt
no-arc-welder.gcode.txt

[FormerLurker]

Thanks! As mentioned in my other message, see if you can move those to an issue in the ArcWelderLib repo so I don't lose track.

[illusionmanager]

I'll try. I'm kind of new to github as well, and only read your other message after I posted the answer above.

[seantapscott]

I have the same version of arcWelder plugin. I'll ask FieldOfView if he was looking at updating the plugin. While viewing the -h command, I noticed there's a dynamic precision option. Is that on or off by default?

…

On Thu, Feb 25, 2021 at 10:26 AM FormerLurker ***@***.***> wrote: I'm not sure if your firmware has any issues. I am building a development printer right now that is intended to allow me to swap boards and firmware rapidly (thanks sponsors and patrons!), so I hope to learn more about this soon. I'm maybe 50% complete, and expect to be up and running in a month or two. Regarding the ArcWelder.exe version, yours does have a known issue. Please see this release <https://github.com/FormerLurker/ArcWelderLib/releases/tag/1.1.1>, look at the bottom for the assets, download the appropriate asset for your OS, and replace the executable with the version you download (you may have to hunt through the zip to find it, should be in a bin folder or in the root depending on which one you download). After you replace the exe, try printing that cylinder again. Consider posting all 3 versions of the gcode (an unwelded gcode file produced with arcwelder disabled, the old welded version that is running slow, and the new version you create from the new executable). Please let me know how it goes! — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#131 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AE5J4UEPVGZ25EIM62DO4VTTAZT27ANCNFSM4WQWURTQ> .

[FormerLurker]

@seantapscott, it is off by default. I received a few issues where users had insane precision in their gcode (usually hand typed start gcode) which caused the G2/G3 commands to become so large that they overran the max gcode length. It's funny, because I added dynamic precision due to a user request (the folks who brought you smoothieware). They were testing g2/g3 performance, and wanted to make sure everything was working properly.

You are probably OK to switch it on, but better yet just set the precision manually to what you want, that way you will never have a problem.

[illusionmanager]

I'm printing right now, but the section of the file printing the infill is exactly the same.
btw I think it would be nice if you mentioned the version number of arcwelder in the gcode file itself as a comment.

[FormerLurker]

Please send me before and after gcode please: sliced without arcwelder and sliced with using the new version. If you can indicate where the slowdowns occurred, that would be helpful. At this point I suggest creating an issue in the ArcWelderLib repository here, and attaching the files via gist.github.com, leaving a link within the issue. I'll probably be doing a lot of ArcWelder work tomorrow and saturday, so it's a good time.

[garyt72]

I have just a general question. I've seen lots of videos and articles that show the gcode visualized with the line segments and arcs separated by a point. Do you have a suggestion for how to do this? Just for curiosity I was wanting to take a look at a couple files to compare them side by side.

I'm using the OctoPrint plugin and downloading the files afterwards.

Here is an example of what I'm looking to replicate - the image at the top of this article:
https://hackaday.com/2020/11/03/this-gcode-post-processor-squeezes-lines-into-arcs/

[FormerLurker]

@garyt72, sure! I used ncviewer.com, making sure to enable the 'show toolpath points' option. Then I loaded a single layer of the orignal and welded gcode, removed any commands that were giving ncviewer.com issues (progress gcodes mess with it), and added any necessary commands to the top (M83 if I'm using relative extrusion). Now just render the code and try to align both windows, take a screenshot of each, and compare!

[Sterikemann]

I have two questions :)

If 'minimum arc segments' in Cura is set to default 12, do I have to change the min_arc_segments in Marlin to 12 too? (it's 24 by default)
Why does Marlin have this option? Does it recompute the arcs?

I'm printing on a CR-10 S5 with SKR mini e3 v2, slicing in cura 4.8 with the Arc Welder plugin, running the latest Marlin 2.0.bugfix, and using Octoprint to control the printer. I have the 'G90 influences extruder' box checked (because I'm running Marlin 2.0), but I don't know what it means. Also, should I have the 'G90/G91 overrides relative extruder mode' box in Octoprint/settings/features checked?

Thanks in advance, I'm really trying to understand what I'm doing haha. So far the plugin helped me get rid of stuttering and improved print quality by a lot!