Some limitations like transfer speed while uploading to SD card and problems with fast, detailed prints seem to be related to the serial interface. We could try to use SPI instead of serial to overcome this limitations. I could try to implement that for Marlin (SKR 1.4) if somebody would be willing to implement the octoprint side.
What do you think about this idea?
Hello @FotoFieber!
For the most printer controller boards are 8-bit based, the reason for slow reactions are to be searched there.
More on this topic you can find in this huge thread:
I think this might possible to do from an OctoPrint plugin, see the 'GPX' plugin that re-writes the communication, but currently unsure.
Otherwise, it would have to wait for a re-design of OctoPrint's comm layer, that would allow extending it to different protocols such as network or SPI as you mention. You might be able to find someone interested in writing the OctoPrint end, but I'm not sure if it is even technically possible yet
According to Serial baud rate | Marlin Firmware (marlinfw.org) we could use 1000000 BAUD. This would be four times faster than I use at the moment. Maybe this is easier to try.
@Ewald_Ikemann
Thx for the link to the thread. Very interesting. My only problem with speed is the file upload to the sd card. Printing from SD card is useful, if you have a power loss and want to continue...
Last I heard about the issue, it was not maxing out the baud rate, but instead the power of the microcontroller to process the commands. There are attempts to reduce the number of commands sent, for example Arc Welder. There's also BufferBuddy that was developed, to send the gcode asynchronously using the 'Advanced Ok' feature, which means it doesn't have to wait for every OK.
TLDR; last I heard the baud rate didn't make a difference.
115200 baud is still not being saturated last time someone did the math. Instead, throttling is in the processing itself.
File transfer to the printer's SD card will be slow also at 1000000 baud.
Each line is sent separately, with kine number and checksum. This has to be verified by the printer firmware and - in case of bad connection - a line maybe has to be resent.
Yeah BufferBuddy with ADVANCED_OK may actually improve that situation as well as @Charlie_Powell mentioned.
Thx for all the hints.
Have compiled ADVANCED_OK and will try BufferBuddy.