I just did a 6MB file that took about 8 sec.
Did you get the messages?
- blue: Starting to convert
- green: Converting complete.
You may have to refresh the file list
No. I didn’t get any messages. @FormerLurker I’m running OP on Ubuntu on a PC if that makes a difference.
Look at the settings in the anti-stutter plugin. There are two options: one to create a new file, and another to overwrite the existing file. You can download the file you uploaded and check for G2/G3s to confirm.
So, I've finished up with absolute extrusion, and have been debugging, and adding a cancel-able progress popup. Progress is good, but more of my hair is falling out every minute while working with the python->c++->python. It is just so incredibly painful. The good news is it has stopped crashing (with absolutely no information, I might add. faulthandler spits out useless and misleading garbage), and I now have a progress popup, hooray!
Still pretty bummed about that marlin setting. Does anybody have experience compiling prusa firmware from the source (mk2.5 w mmu 2.0)? I'd love to test a modification to that MM_PER_ARC_SEGMENT define, but it will be a while before I can get to that if I have to figure it out myself, and I'm sure to lose even more of my hair.
I have it set to create a new file. I used the defaults. The log for the plugin is blank.
Hmm. I will look into it. I'm working on that bit right now.
So, i have a progress indicator working finally.
I don't think I can get the cancel button working, since it looks like the pre-processing occurs on the main thread, with no way to get a message from the client to the server. I have all the code in there necessary to do it, if I could figure out how to get a message sent from the client.
Going to run some tests, then I'll post a new zip.
Hi would very much like to test out your plugin.
Running an ender 3 with an SKR mini e3 v1.2 so interested to see if it would benefit a 32bit board also.
SimplaApiPlugin mixin is the easiest way I've found to control stuff on the python side from the web interface. You'd probably have to run your code in it's own thread and then control the thread from the api calls.
So the issue with the file not converting is because I was sending it via Cura. When I upload it through the OctoPrint UI, it converts it. Not sure how hard it is to do this, but it may be a good idea to have a button on each file that lets you manually convert.
no, its just the small line (marked in picture), the other infill lines are printed in normal speed.
i will try changing the MM_PER_ARC_SEGMENT parameter. 
Edit:
changed MM_PER_ARC_SEGMENT to 0.1 and it resolved the issue 
2 Likes
Here are my first results. With test cube, GCODE before 2.5 MB, after 1.8 MB. And Antistutter has pretty the same results as printing original from SD.
I have Octopi on Raspberry Pi Zero W, conversion took several seconds, I didn't measure it, but was acceptable 
Here there results: left - original GCODE printed through OP, middle - antistutter GCODE through OP, right - original GCODE printed from SD.
You can see much more artifacts on the left compared to middle and right, which are pretty the same.
2 Likes
Try printing a Benchy. I had issues in specific areas with very short arcs, and would like to know if they are also affected.
I actually hadn't looked at the SimpleApiPlugin mixin before. I have been sticking to the BlueprintPlugin mixin, but will dig in a bit to see which is more appropriate for my situation.
You'd probably have to run your code in it's own thread and then control the thread from the api calls.
Yes, and I have tried running my code in a separate thread, but the pre-processing hook isn't made for it. I'd have to sacrifice the 'replace current file' option, or else find another way to make that work. The hook expects a file_object return value that contains info about the gcode file. In order to overwrite the existing file, I need to return a file object with a different source path. That's impossible if I run it in a separate thread unless I use a join, which defeats the purpose of the thread. Also, Octoprint will delete the source file once all preprocessing is finished, so I'd have to copy it, which isn't ideal (but is a viable solution I think). I may have to bypass the hook entirely, but then there are a host of other problems to deal with. It's a work in progress
To be honest, there don't appear to be a lot of external circles/arcs in the X/Y orientation for this printout. The corners are chamfered rather than filleted, for example.
Sorry, I should have marked the important parts, those the holes on the inside, they are internal circles And cubes are rotated for the purpose of the photo, to see the details better under the light. What's on top is actually side wall, and the one on the side pointing forwards is top face of the print.
1 Like
Ahhh. In that case, I think OctoPrint might have outperformed SD printing on the inside cylinder of that hole.
That's not what I see. The one of the left is Octoprint using serial, and it looks like all of the imperfections visible in the middle image and the right image are present, plus a few extra. Admittedly, it's difficult to see in the photo. I don't think a test cube is the ideal test object. I think Benchy does a much better job since it's a nice combination of large and small arcs and straight lines.
1 Like
I have a Benchy in progress right now, I'll post comparison photo later. But only with SD vs Anti-Stutter.
Thank you so much!
It would be excellent if you could include one using local octoprint storage also (serial streaming), since that's really what this plugin is trying to improve, but I'll take what I can get
1 Like