Feedback for V1.1.0rc2

[FormerLurker]

Thank you SO MUCH for stopping by to comment on this version of the Arc Welder OctoPrint Plugin! I want to promote this to a stable release as quickly as possible, since there has been a LOT of interest in Arc Welder over the last week. Please let me know if you installed it, and especially if you were able to successfully print.

As always, all feedback regarding v1.1.0rc2 is welcome here! I'm interested in what you love, what you hate, what you think is missing, or any general feedback, including just a message saying it installed properly and is working as expected.

I have NOT updated the Sponsor list yet, but will do that before 1.1.0 stable is released. Many of you have been extremely kind recently, as I've received several new patrons and sponsors. I so so appreciate it!

[Seri-]

Installed and working in combination with Meatpack on OctoPi 0.18 and Octoprint 1.5.3 on Pi3B+ with Marlin Bugfix 2.0.X dated 07.02.21 on a BTT SKR1.3.

Thank you for all your work ;)

[FormerLurker]

@Seri-, I am really excited to see what happens when meatpaker and arc welder join forces :) I would also love to add buffer buddy to the mix and see how fast we can print over serial with that combo!

[Seri-]

I would not even know how to max out the connection at the moment. Do you have an example of a model that tends to max out the printer at higher speeds? It might not look good but my printer can handle some insane movment speeds and accelerations if it has to.

[FormerLurker]

I would not even know how to max out the connection at the moment

I can create a progressive gcode file that generates more and more points per mm as it goes on. At some point I promise it would stall out the printer :) I think the hard part would be to figure out exactly when that happens. However, arc welder would just weld them all together (assuming a real world situation like a curve), so your printer wouldn't have problems. It should be easy to show that arc welder can improve meatpaker's performance, but the other way around would be more difficult. Maybe some micro arcs chained together with an increasing feedrate? This deserves some additional thought, and maybe a discussion (see the new discussions tab).

Chen.do has another neat fork of marlin that adds a gcode that can be used to monitor the planner and see if it gets drained, and for how long. I hope that gets added to marlin 2 at some point. Would be very useful here. I don't have enough data about real world performance ATM, and would love to have some.

[fnsign]

Thanks for that plugin and your work on this. I installed the rc2 yesterday to test and made a few prints without any issues. But I have only one thing: I use the UI customizer plugin and the AW information tab has somehow a problem with line breakes. Could you check this?

Thanks!

[greyhound3]

Just wanted to say that I printed around 7 pieces with rc01 without problem and 4 pieces with rc02 without problem aswell.

[FormerLurker]

@fnsign,

Thanks for providing feedback!

I use the UI customizer plugin and the AW information tab has somehow a problem with line breakes. Could you check this?

I'll take a look, but my guess is the width of span class was changed, which broke bootstrap. Using 12 columns (span4 + span 8) should never overflow like you are showing.

[FormerLurker]

@greyhound3, THANK YOU for reporting success, the most rare of feedback :)

[WarrenSchultz]

I've printed a number of things without issues on RC1. It's really nice for some large cylindrical-shaped objects that I've been printing with TPU. Doing a couple of PETG prints with a number of round shapes on RC2 currently. Minor request. If you can add the TZB firmware rev to the recognized versions, that'd be appreciated, but obviously minor, as long as I can override whatever is detected :) ( https://github.com/TheZeroBeast/TZB-MMU2S-Firmware )

[FormerLurker]

@WarrenSchultz, can you do me a favor? Add a feature request for the TZB firmware, then send an M115 to your printer and paste in the results? That will help me see what can be done about adding the firmware to the library and to keep from forgetting about this :)

[WarrenSchultz]

Send: M115
Recv: FIRMWARE_NAME:Prusa-Firmware TZB3.2.0 based on Marlin FIRMWARE_URL:https://github.com/prusa3d/Prusa-Firmware PROTOCOL_VERSION:1.0 MACHINE_TYPE:BondTech-PE-TZB MK3s EXTRUDER_COUNT:1 UUID:00000000-0000-0000-0000-000000000000
Recv: ok

What feature request are you asking that I submit? His code is pretty close to the original Prusa, except for the MMU handling functionality. (Once Prusa integrates your pull, TZB should follow fairly soon after.)

[FormerLurker]

I just ment add an issue to this repository asking for detection of TZB firmware to be added. That's how i track what needs to be done.

[fnsign]

I'll take a look, but my guess is the width of span class was changed, which broke bootstrap. Using 12 columns (span4 + span 8) should never overflow like you are showing.

Thanks! Forgot to mention, that I use a 3 column layout (2 + 7+ 2). The Tabs are in the middle and have a width of 7.

[printhefuture]

Hi - great work, hope this is some help.

///Background Ender-5, glass bed, stock extruder, fans. Melvi 8-bbit board, running TH3D 2.22 (Marlin 2.06 or 07 I think) OctoPrint 1.5.3 / OctoPi 0.18 on a Raspberry 3b. Cura 4.8.

Current 3d printing focussed on PLA-based components for astro-photography. Think GT2-50 gears, custom-design enclosures and mounts. gears are parametric-based generated by OpenSCAD, enclosures are designed on Fusion360.

Pre octo-pi, pre arc-weld, printed successfully GT2 gears approx 30mm diameter, with teeth 3mm, using a Marlin 1.x firmware and printing from SD card. The gcode file was pretty insane, at ~ 5MB, and countless G1 commands. Stepper drivers / motors coped, but never sounded exactly happy.

///SD-card & Marlin 1.0 vs Octoprint, Arcweld & Marlin 2.0.x Installed Octopi, quality dropped - some curves were clearly being approximated as polygons, and stuttering was leading to blobbing. Noticeably, the outer circumference of the gear was noticeably a polygon - a very many-side polygon, but def not a circle.

Firmware tweaked to support G2/G3, MM-PER-ARC-SEGMENT changed 1.0mm >> 0.1mm. Min-arc-segments set to 24. ArcWeld 1.0 installed. Meh. Less blobbing and stuttering, but quality didn't match printing raw gcode from SD Card / Marlin 1,x original.

Arcweld RC1.1 installed. much better output. Gear teeth all well defined, no blobbing or stringing. External circumference is still definitely a high-res polygon.

///Render unto Caesar... Looking at the Marlin code, G2_G3.cpp exposed (to me) a couple of points

• Arcweld isn't magically transforming gcode into arcs which are then perfectly drawn by the printer. Arcweld is converting line segments into arcs, which G2_G3 then reconverts back into line segments. The happy side effect is reducing traffic between octopi and printer.
• Marlin's G2_G3 code in v2.06 / TH3D 2.22 sucks*. The code appears to be under improvement in the bugfix-2.0.x branch.
• The suck-factor comes from a v basic rule-of-thumb to try to create a reasonable approximation of a curve, with no reference to specific spatial resolution of a specific printer, the desired resolution and the actual size of any curve.

I guess what I'm trying to say in a long-winded way is your RC1.1 plugin appears to do a better job than v1.0. It definitely reduces code size and traffic from OctoPi to Marlin. So far so good. The gotcha is that if Marlin's arc-drawing routine is giving me polygons when I want circles (eg the outer circumference of my GT2 gear) then it's a bit moot, and I might be as well off not worrying about arcs in the first place, just let the Melvi board grind through a bazillion G1 commands streamed from the SDCard.

I recognise you've stepped up to create a plug-in to fix one problem (comms overload) with a novel technique of almost-lossless compression at a geometric level, instead of the usual protocol level - and not signed up to improve Marlin code.

I'm still looking at the G2_G3.cpp code to work out options to improve it so it (a) generates proper arcs at all scales (b) doesn't try to over-fit beyond the resolution of the printer.

Thanks for all your work, let me know if there's anything I can do to help with . G

[FormerLurker]

@printhefuture, wow, thanks for all that feedback! Though I need to re-read it a few times still to absorb everything, let me give you a few recommendations that I think are appropriate given my current understanding:

1. Revert mm_per_arc_segment to between 0.5 and 1.0 mm. Taking this too low will strain your board.
2. Leave min_arc_segments to 24. It's a pretty good default.
3. Make sure you th3d firmware is really running a fork of at least 2.0.6+ (preferably even newer).

That should result in very accurate geometry. The actual segment length with those settings will be 0.5-1mm MAX, and will decrease as the arc angles decrease. This will reduce strain on your board except when necessary (arcs where the radius is between 0-5mm approx). The only thing missing is a min_mm_per_segment to keep boards from stalling out if the arc radius is small, and the printer's accuracy can't deal with the detail anyway.

If you have a link to the firmware you are running, I should be able to tell what version of Marlin it was forked from. In the worst case scenario, there is a setting called 'firmware compensation' that can deal with arcs of a small radius at the cost of compression, but I don't think you will need it. You could, as a test, give it a go if you want.

Thanks! I may respond more later when I have a bit more time.

[printhefuture]

@FormerLurker thanks, will do.

[GhostlyCrowd]

V1.1 working great here with Meatpack and Bufferbuddy plugins. I've made several 12+ hour prints with it and it has improved print quality greatly, I used to run into buffer issues on very complex models that would cause zits about 6-12 hours in.

How is 3d ARC support determined? I'm assuming its supported but the plugin cannot deduce this.

[FormerLurker]

@GhostlyCrowd, they probably are, but the bugfix branch doesn't provide an accurate version number, hence the warnings. Just enable it and try a vase mode print. Be sure to watch through the second or third layer to make sure it is working properly.

[xrunner]

Got this release installed today, along with MeatPack. I have tested it on several calibration models and I don't see any problems at all. Ender3 Pro with SKR mini. Running Marlin 2.0.9.1.

[greyhound3]

Well, I printed many things with this, since month now. Now even tested with octoprint 1.7 and klipper 0.10 Works very well.

[GhostlyCrowd]

Well, I printed many things with this, since month now. Now even tested with octoprint 1.7 and klipper 0.10 Works very well.

I, too, have been using it on klipper and marlin based printers fine for months. Although i keep getting told by Klipper people its useless to use on Klipper @FormerLurker is this true? they say it provides no benefit at all as klipper "converts it back to G0/1"

I understand that all firmware convert G2/3 into segments, but My understanding is that the segments would be constrained to the arc that G2/3 creates and with in the defined resolution. SO It should still have a benefit of a smoother arc and tool path on klipper no?

[seantapscott]

Marlin also converts arcs back into straight line segments. Most of the firmwares are currently doing that, as far as I know. The primary benefits of arcs are more user-readable gcode and more compact size for long term storage. BTW, there is a firmware configuration setting (in Marlin, at least) that allows you to modify how long the interpolated arcs are. I don't know what the Marlin defaults are, but FormerLurker might.

Sean Just an ArcWelder-interested peer

On Mon, Nov 1, 2021 at 12:29 PM GhostlyCrowd @.***> wrote:

Well, I printed many things with this, since month now. Now even tested with octoprint 1.7 and klipper 0.10 Works very well.

I, too, have been using it on klipper and marlin based printers fine for months. Although i keep getting told by Klipper people its useless to use on Klipper @FormerLurker https://github.com/FormerLurker is this true? they say it provides no benefit at all as klipper "converts it back to G0/1"

I understand that all firmware convert G2/3 into segments, but My understanding is that the segments would be constrained to the arc that G2/3 creates and with in the defined resolution. SO It should still have a benefit of a smoother arc and tool path on klipper no?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/FormerLurker/ArcWelderPlugin/issues/145#issuecomment-956384694, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE5J4UEMUCF7NFHUELBBF2LUJ2543ANCNFSM4XH2TG7Q . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[johny-mnemonic]

@GhostlyCrowd they are missing the point then, as the benefits of ArcWelder are in the fact, that it reduces not only the size of the gcode file, but more importantly it reduces the amount of commands you need to send to the firmware over the serial line.

For example Octoprint running on RPi3 feeding my Ender 3 was really struggling to print some rounded shapes as it couldn't sent gcode commands fast enough over the serial line to the printer, so the printer was stuttering. With ArcWelder serial line is no longer the bottleneck as it reduced number of commands that are needed to be send to the printer. Problem solved ;-)