New Plugin: Anti Stutter - Need Testers

Plugins
1

I'm looking for technically inclined users who have experienced stuttering when using OctoPrint to help me test a new plugin. Preferably the stuttering is repeatable and causes noticeable print quality issues. My plugin reduces the number of gcodes per second, and will hopefully reduce or eliminate stuttering without noticable print quality impacts.

In order to help, your printer must support G2 and G3 commands. I don't think many (any) delta printers support these, but it's pretty easy to verify by sending some G2/G3 commands via the terminal.

Also, there may be some installation problems because the install is rather complex and the plugin is new, so be prepared for that.

If you are interested, reply and I'll send you a DM. Thanks!

Edit: I've added the code to Github now, so the whole DM thing is moot. Here is the link to the first second third fourth pre-release from github:

https://github.com/FormerLurker/ArcWelderPlugin/archive/0.1.0rc1.dev4.zip

You can install via the plugin manager using the Get More-> ... from URL option:

Important Note: The update routine was STILL not 100% correct, so you probably will not be notified via the software update plugin. Hopefully this latest version fixes that.

If you already have the old version installed, completely uninstall and clean the files. I'm hoping installation is better behaved now that it's pulling from GitHub, but please let me know if there are any issues. If there are, please send me your plugin_pluginmanager_console.log file.

Please make sure you verify the g90/g91 influences your extruder setting (likely true if you are using stock marlin 2.0 with the stock config, false for reprap firmware), and set an appropriate resolution (it's set to 50 microns now, or 0.05mm). Don't go above 0.1mm for sure. Absolute extrusion support is newish, so that may have some undiscovered bugs. Message me if you need help with any of that.

Any issues discovered from now on should be posted to the github repository to make things easier to track.

Thanks everyone! This has been great!

8 Likes
2

@hashashin, @cosmith, @devhammer, @reloxx13, @gcurtis79, @Ewald_Ikemann, @devildant, @Peter_Willard, @w6lsu, @Johnnie_Walker, @Andrea_Fioretti, @Foxabilo, @MagnusT, @salfter, @Quickdrawe, @DanSexton, @RickMcConney, @torsoreaper, @SapuSeven, @schleprocker, @DimaGorbenko, @augustus, @AlBravo, @lmcbmai, @unwohlpol, @Dean_Naidoo, @Buks_Potgieter, @ss220astro, @mu2004, @Ratschaka, @ashleycawley

1 Like
3

Sadly I have none of these problems these days...

4

Well, that's good! It's possible that there are other benefits, but I'm not sure yet. It definitely cuts down on the file size quite a bit. A 5.3MB benchy (gyroid infill) gets reduced to 2.9 at a resolution of 0.05mm.

Anyway, hoping it helps some people.

5

As I mentioned in my thread at that time I fixed my issue and never had problems again.
How does the plug-in cuts the file size by that much ? (you can be technical and go into details)
I mean how exactly does it reduce the gcode per second without sacrificing a lot fo the time?
But super nice idea :+1:t2:

6

Basically it tries to convert line segments into curves. I continually add extrusion points to a detector that looks for arcs whose circumference matches the segments within a specified resolution (0.05mm for my printer, so + or - 0.025mm). If they fit, it tries to add the next point. If it does not, it pulls the first point off and tries to create another arc. I will post details on how it works and what the results are, but here is an example before, after, and overlay (one on top of the other):

Before Compression:

Before Image of Benchy
Before Image of Benchy1035×471 99.4 KB

After Compression:

After Image of Benchy
After Image of Benchy1035×504 96.1 KB

Both Images together (manually sized, so there is some fudge there):

Both Images Together
Both Images Together1369×661 241 KB

Ignore that errant segment in the after image, that was an artifact of the viewer.

FYI, absolute extrusion isn't working at the moment (I am working on that), but relative extrusion seems to work fine.

7

I can confirm that is crunches down the gcode of cylindrical parts, for example. The audible sound of the print job while printing is much more organic/analog now versus the earlier choppy sounds of micromovements in both steppers (cartesion printer). What was once fifty or a hundred tiny line segments are now full, sweeping movements of G2 or G3 (depending upon the clockwise-ness of the arcs).

First-layer extrusion seems to be better on my unheated print bed. For me, it produced 100% identical parts before/after the plugin with no difference in the appearance or surface (but of course I didn't have blobbing). Print times for me were basically the same. Testing was done on a Raspberry Pi 3B with a only three plugins installed.

In my humble opinion, Cura and the rest of the slicer manufacturers should drive a dump truck full of money to FL's house and beg him to come work for them. The slicer should be doing this in the first place. But as a "downstream fix", this is a beautiful solution.

It will be necessary to add both G2 and G3 to OctoPrint's list of long-running commands. Settings -> Serial Connection -> Firmware & Protocol -> Advanced options -> Long running commands

For this to work, your firmware should respond favorably to the second command issued like this in OctoPrint's Terminal tab:

G0 X40 Y40
G2 X40 Y40 I20 J20 # CW circle with center X60/Y60 and radius 20
1 Like
8

Good call on the long running commands! Doing this now.

1 Like
9

Could not have said it better and that's why I wanted the explanation in technical terms that is an amazing feature which was requested by a lot of people in the open source community (a simple but effecient way to down-sample code)

10

Yeah, it's confusing to me why current modern day slicers don't have arc support out of the box. Count me in @FormerLurker I'd be happy to test this out and give feedback.

11

I would be interested in alpha/beta testing, once I finish with a series of parts for a massive build in progress now. I'm ass/u/ming my Marlin 2.0 firmware on the CR-10v2 can handle G2/G3?

12

Well, yeah... what FL said (with pictures). The "before" part was 910KB and the "after" part's gcode is 460KB for an approximate reduction of 50%.

Removing all lines which were just comments from both: 900KB versus 450KB for an exact reduction of 50%.

As with anything radically new, this will take radical testing.

13

As long as you didn't disable arc support, yes.

14

Convinced - I think, I give it a try

1 Like
16

seems to respond to a test of

G2 X125 Y32 I10.5 J10.5

Right off of the Marlin documentation list.

17

I get this error message:
grafik
The settings in PrusaSlicer are set that way, that DisplayLayerProgress has no problems:

;[layer_z]

What format does AntiStutter await?

18

Hmm. I need to preserve spaces.. Try ; [layer_z] (space after semicolon)

1 Like
19

I have an SKR Mini E3 on an Ender 5. Most of it is the default config, and it apparently doesn't have it enabled. I'm going to have to do that now. This looks awesome.

That said, will this cause any issues with parts that need to fit inside each other? Like if a part that needs to screw into another part, will it become a tighter fit? Or will it likely fit better?

20

Ok, I'll try that

21

That said, will this cause any issues with parts that need to fit inside each other?

If I did my job right there will be no difference since the tool paths should all be within the printer's resolution. It's not quite that perfect yet (I know of a few cases I need to deal with but haven't), but it won't be WAY off.. I'll be fixing the known issues before release.