Between upgrading to a 32-bit microcontroller (Re-ARM) and replacing the USB connection with a direct UART connection, I've not had stuttering issues in a while. Might still be interested to see what this does, though, especially as it looks like it'd clean up curves.
In Autodesk Fusion 360, it's rare when I don't add fillet to edges. The default mode for these is single-variable radius, a simple symmetric arc segment. When these occur in the XY plane (as oriented in your slicer) this will equate to smoother movements after optimization with this plugin.
Hit me up, lots of time and i'm an EE and coder too.
So I just enabled this in my Marlin. And this isn’t any issue with the plugin, but appears to be just with my printer. And I’m having a big problem with the command. It makes a weird grinding noise. I took a video of it.
Here’s what I do:
- Home x and y axis
- Issue the second G2 command in the example above. This is where it makes the grinding noise.
- issue that same command again and it goes in a circle in the exact spot it’s at. It appears to work.
If I Home again, the issue happens one time and then starts working. Although it never draws the circle in the exact spot it’s supposed to. It just does it right where it’s standing.
Any ideas?
You have to use both commands. The start and end points must both be along the arc, or things will not go well.....
So, home, then travel, then draw arc. Both the starting AND the end points are important. The behavior of G2 G3 is undefined if both points aren't along the radius.
If you needed to home and then run the test:
G28 X Y # Home the X/Y axes
G92 X0 Y0 # Tell your firmware that this is the home position
G90 # Set absolute mode for the steppers
G0 X40 Y40 # Move to the place where the circle should start
G2 X40 Y40 I20 J20 # CW circle with center X60/Y60 and radius 20
1 Like
Your test code is brilliant 
. It will work if the origin is front left OR center, and I'm going to include it in the readme.md with attribution if you aren't opposed.
No attribution needed, dude. It's basic reprap.
This isn't related to testing, but if anyone has any thoughts about what I should call this plugin, I am all ears. It should ideally be both catchy and descriptive. It was intended to reduce stutter, but it does a bit more than that. I have a few (generally bad and unoriginal) ideas, but would like to hear your take. I need to nail the name down before creating a GitHub repo.
Smooth.... I listened to the whole song, though I prefer old school Santana 
. I was thinking Archimedes Anti Stutter, ARCane, GCurve, ARCurve (like archive), Smoother (great minds think alike), GCompression, and Stutter Butter (I'll admit that is a stretch).
So I've gotten a few brave souls to try this out, and for that I am extremely greatful. I'll be anxiously awaiting the results while i solve the last couple curve fitting problems (any geometry heads out there willing to help me figure out how to calculate the maximum distance between a circle and a line segment?) as well as fixing absolute extrusion (I have confirmed there are issues). If anyone else wants in on this, hit me up. Bless this community!
1 Like
It’s working after using both lines. User error. I thought both commands were independent of each other so I just tried the second by itself. Using both works. Looking forward to using the plugin for my next print.
Printing my first Benchy now. Reviewing the gcode in the GCode preview tab indicate a couple of potential artifacts.
I'm unable to verify in any other viewer I typically do (Cura or Ideamaker), because it seems they don't support Arc commands ad comes out all weird. Might want to mention that.
Looks good, ship it!
Post the before and after gcode and I will analyze it. This is exact the kind of thing I was hoping for!! Better to find things now, right?
Of course, here you go. Sliced with Cura, sent to OctoPrint via Connect Plugin without UFP Plugin enabled (straight gcode upload vs ufp file format and extracted by my plugin). I do want to verify it still works with my UFP plugin enabled as well.
AS_CCR10_3DBenchy.gcode (1.3 MB) CCR10_3DBenchy.gcode (2.8 MB)
So, I don't see those artifacts when I analyze in Simplify 3D (it seems like it has the best arc support of everything I have tested). Here are the first layers I looked at from the anti-stutter algorithm:
It does look like the infill overlaps more than I would expect. However, when I looked at the original, they overlapped there too, so I suspect it's a slicer setting:
I found this online analyzer that has some features no other viewer has. It isn't perfect, but I find myself using it quite often. It is especially good for looking at a single layer, since it can show the individual points between gcodes.
I think the next step is to print both the modified and original version and compare them. What do you think?
Arc commands are odd. I didn't understand them fully until I started messing around. It's a bit strange that your printer even attempted to create the arc rather than just ignoring the command. However, since the behavior is undefined, I guess there is no wrong to handle an invalid command like this.
Looking forward to using the plugin for my next print.
I can't wait to hear how it turns out! Now back to this awful absolute extrusion audit.. It's like pulling teeth. My own..