Quality, PrusaLink v. Octoprint
I have been using Octoprint since I got my first Prusa Mk2 years ago and love it. I just upgraded from a Mk3S+ to a CoreONE and did some test prints using Octoprint and PrusaLink and there is a noticeable difference in the kinematics and the quality printing the same stl using the different platforms. PL prints quieter, faster and more accurately, while Octoprint is noisy and not as precise.
As an example, using PLA and following the directions for this model -> https://thangs.com/designer/Multiboard/3d-model/Ironing%2520Stack%2520-%2520Test%2520Print%2520-%2520Key%2520Chain-977033
the two pieces come apart when printed using PL, but are inseparable with the same file using OP using the same stl, slicer settings and filament on the same coreone printer. I have tried both straight G-code and the binary version and I get the same results.
Are there communication tweaks or other settings or gcodes that should be used on the OP side, or am I missing something else here?
Best Answer by cyrusjk:
SOLVED: It was one or more plugins that were slowing things down. Running in safe mode worked fine, and after a cleanup of plugins I do not use it seems to work better. I recommend the faster baud rate as well just to make sure the coms can keep up on high-detail/short-g-code commands with a faster system.
RE: Quality, PrusaLink v. Octoprint
You can also check the display of the "resend ratio" for your printer. It should be "0" or very close to zero during a print. Otherwise there is a problem with the communication between OctoPrint and the printer.
Also you can check the settings for the serial communication and increase the baud rate. The baud rate recommended by Prusa (115200) for the MK4 series is the rate that was valid for the MK3 series. I my experience the newer xBuddy mainboards can handle double that value. I have been using those settings on my MK4 for over one year now without any issues. This will not make the printer print faster, but it reduces the chance of a potential bottleneck and the printer's buffer going empty.
RE: Quality, PrusaLink v. Octoprint
"customizing G-code scripts" is not helpful. It would be appreciated if you have examples of what that means specific to this issue.
RE: Quality, PrusaLink v. Octoprint
There definitely seems to be a lot of small pauses while printing, and I suspect that the command buffer is too small for OP to keep up, but I'll take a look at the baud rate
RE: Quality, PrusaLink v. Octoprint
Please ignore "Lauren075Keyser". I am pretty sure that's an AI-generated response from an account which has just been set up to post link spam in the future. We had a similar post yesterday, where the ChatGPT style was much more obvious and which used a similar user name pattern ("richard396thompson").
RE: Quality, PrusaLink v. Octoprint
See the section "Step 13" on this page: https://help.prusa3d.com/guide/octoprint-setup-on-mk4-s-mk3-9-s-mk3-5-s-xl_646395
RE: Quality, PrusaLink v. Octoprint
Yes, those G-codes were already added; I followed that guide for lack of a CoreONE one considering they are the same systems underneath.
RE: Quality, PrusaLink v. Octoprint
SOLVED: It was one or more plugins that were slowing things down. Running in safe mode worked fine, and after a cleanup of plugins I do not use it seems to work better. I recommend the faster baud rate as well just to make sure the coms can keep up on high-detail/short-g-code commands with a faster system.
RE: Quality, PrusaLink v. Octoprint
Thank you for providing the cause hopefully it helps others in the future and I'm glad you got it figured out.
RE: Quality, PrusaLink v. Octoprint
Do you have any idea which plugin(s) were the culprit? Or a list of all the ones you disabled? I'm seeing similar issues with my Core One, where Octoprint quality is much worse than printing directly from the printer itself (or via Prusa Link). If you have any pointers that would be fantastic - might save me from a lot of trial and error 🙂
RE: Quality, PrusaLink v. Octoprint
I would disable all plugins and check the print quality. If the quality is okay without the plugins, then I would enable the plugins I want one by one until the quality changes. Some plugins can put a big load on the Pi. Enabling "Arc fitting" in PrusaSlicer and/or using the ArcWelder plugin in OctoPrint can speed up things as well by compressing many single short linear moves into longer arc moves that use less gcode.
RE: Quality, PrusaLink v. Octoprint
Thanks Walter! That's a good thought - I will try a print with no plugins enabled and see what happens.
I've already got arcs enabled in PrusaSlicer, so shouldn't really need ArcWelder as I understand it - sounds like ArcWelder isn't likely to result in additional compression on top of what the slicer should be doing.
I've observed very brief pauses/stuttering while printing round objects from Octoprint - as if the buffer is emptying out and it's stuck waiting for the next instruction. That seems to really mess up the surface finish, adding little blobs/zits. I've been using the highest serial rate (250k) so if that's the bottleneck I don't know what I could do to help there. As you suggest, maybe the problem is the Pi4 not feeding commands fast enough due to plugins slowing it down.
RE: Quality, PrusaLink v. Octoprint
ArcWelder still adds a little more compression to the file if you use it on top of the setting in PrusaSlicer, but I don't think the difference will be significant.
From what I have heard on the OctoPrint forum, some plugins for remote access can slow things down quite a bit. I am not sure about the plugin names, I have never used one of those.