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.