Keep in mind that the serial transfer and checksum comparison adds to the MCU load when transferring via USB.
This is because the lines are transferred one by one. This is a feature of Marlin, not OctoPrint.
You can have BFT with OctoPrint:
Keep in mind that the serial transfer and checksum comparison adds to the MCU load when transferring via USB.
This is because the lines are transferred one by one. This is a feature of Marlin, not OctoPrint.
You can have BFT with OctoPrint:
As I mentioned, BFT is pretty decent in speed. So that shows that the serial-over-USB is not the problem. The board also has a decent 32-bit STM processor, so the bit of parsing and checksum overload can't be the issue. I guess I'll just go Klipper. I've now been spending a couple of days trying to get things to a decent level, but nothing seems to help. I even tried going back to older Marlin FW and also tried going back to a BTT Maple-based build, but nothing helps. It's a pity, since I do like the option to use this Ender 3 Pro standalone with Marlin, but not at the cost of not being able to print from the Pi.
I'm just disappointed that on this topic time seems to have stood still for Marlin and OctoPrint. Getting the gcode over without stuttering should not be a topic in 2022 I feel ...
A short reminder:
This thread came up almost 4 years ago when 32 bit boards had been quite rare and most printer (almost every printer) had 8 bit boards.
As you stated BFT works fine, then I don't see what the problem is then, as there is a plugin that supports that transfer method available for OctoPrint. Otherwise, are you experiencing issues with stuttering/zitting printing from local OctoPrint storage rather than SD? Just trying to understand what the actual problem is specifically for you @MrK? I don't see how klipper is a relevant comparison here, because it uses a virtual SD card on the pi, similar to OctoPrint's local storage so it is not transferring to the SD card of the printer either.
I am having stuttering when printing via serial from OctoPrint. Uploading with BFT works fine (well, I don't find the mechanism very user-friendly, but that's a totally different thing). Printing from SD-CARD works great, no stuttering with the exact same piece of gcode that stutters like hell via serial.
Board is an SKR E3 Mini v2.0. Printer an Ender 3 Pro with Marlin bugfix-2.1.x branch, but as mentioned I have tried also older firmware which about a year ago seemed to work fine but now with my current OctoPrint versions also stutters. I haven't printed on this thing for quite some time, but regularly just updated OctoPrint and its plugins. So I have no idea what broke ... of course there's also a much newer Cura version now, OS updates, ... So I really have no clue what change or component would be playing a role here, but the old Marlin versions misbehaving seem to hint that Marlin isn't the changed factor here ...
same in safe mode?
Do you have the Resource Monitor plugin Version < 0.3.9 installed?
A short hint on this:
Won't be able to test anymore. Have Klipperized that printer too and first try with the same gcode on Klipper (running on the same Pi OctoPrint was on and with no change in cabling) worked flawlessly. I can still switch to Marlin by just reflashing it, but getting OctoPrint up again will be more work, so I will probably not be doing that ...
Do want to add that at the time I was testing with OctoPrint, all the plugins I had installed were up-to-date (as was OctoPrint itself). I do think I had a resource monitor plugin installed, but whether it was the exact plugin mentioned here and what exact version it then had, I cannot say ...
Anyway, I'm now tuning Klipper, which apparently has no problem at all with speedy communication between Pi and printer MCU, so I still consider it a pity that in the years this topic is open Marlin and OctoPrint (and others feeding gcode) have not agreed and implemented a decent communication mechanism instead of just adding hacks like MeatPack and ArcWelder (with all respect to the developers of those as they are impressive, just not attacking the problem at the core). I am also not a Klipper fan-boy. There are many inefficiencies in Klipper (starting with the use of Python) that I dislike and turn me towards Marlin, but in the end if prints suffer, the choice is getting made by that fact ...
Octoprint's USB comms have slowed down. Older versions work on an RPI model 1B but the latest versions stutter over USB unless I use an RPI0 W2 or better.