I have MKS Gen 1.4 board and MKS TFT 2.4 panel (also have MKS mini panel, which works with same speed).
Printing from MKS TFT 2.4 goes much faster than from Octoprint.
I tried to print simple model and to print one layer Octoprint takes 19 seconds, and MKS takes 12.
I've noticed that octoprint slows down while printing circles, while straight lines were printed with the same speed (octoprint and MKS).
my PC connected to printer by USB cable prints with the same speed as MKS.
Details:
OctoPrint 1.3.9 running on OctoPi 0.15.1 running on Raspberry PI 3B+
Connection speed is 250,000.
If it were me, I'd make sure that my serial cable had a metallic sheath/shielding inside or it had one or two ferrite cores.
You might want to check and/or provide your serial log (having turned that on in the Settings -> Logging area). If it's losing some of the communications due to electrical noise, it will choke a bit when it has to resend a previous command.
Hi,
the cable has metallic shielding, and it's 35cm long (almost 1 feet).
I had much longed cable (1 meter) with ferrite cores on it, and the speed of printing was the same.
The serial logging is off for now, and the octopi is printing... once it finishes I'll check that logs.
In the logs and by watching the Terminal tab output, you're looking for any instances where OctoPrint is forced to resend commands because the printer didn't indicate ok for a particular command. This then jams up the queue.
But it's probably not that. There's a way of just driving-on-without-waiting-for-ok which I can't find in the settings at the moment. I think I'd suggest trying a print with that to see if this is the reason.
Circles means lots of tiny very short line segments. How short depends on your slicer's settings. The shorter they are, the more data OctoPrint must push over the serial line in the same time. There are hard limits here, and certain plugins can slow things down further (constant GCODE checks for example).
Printing over serial (which means first pushing the data to the printer over a serial connection via a suboptimal protocol with ping pong communications) will always be slower than printing directly from SD (where the printer can read the next line as fast as the SD IO allows). OctoPrint has to do some computations (line number calculation and such) that limits achievable speeds. Some plugins add additional overhead (intentionally or unintentionally). With GCODE with sensible line length that usually will not cause any issues. If you print models with loads of curves with very short segments however, you'll start to notice differences.
Yeah, that totally makes sense.
I was just thinking of decreasing amount of computing taken by octoprint while sending commands to printer's motherboard.
One thing definitely causing quite some overhead is the calculation of the checksum. You can disable that, but IF you then run into communication errors, the firmware won't be able to detect them.
What if... someone were to write a plugin or a GCODE processing script to add checksums to each line?
Not that you'd want my Go language code, but I've managed to do the checksum calculation. Would it be useful to have a GCODE file which doesn't contain comments and comes pre-loaded with line numbers and checksums...? I guess not since you'd need to add the user-defined gcode scripts. Bummer.
Yep. Experimented with that a couple weeks ago (slightly different than what you described but same basic idea). No observable speed gain since you can't precalculate the checksum for the line number until right before sending.
:laugh: But you could pre-calculate everything minus the "Nd " prefix and then:
assign a line number and prefix it
calculate the checksum of just the prefix
XOR that with the pre-calculated one and update
(Not that I'd do it.)
Can a reprap printer accept negative line numbers? If so, the before-start gcode script can be precalculated with ascending negative line numbers.
N-3 M106*36
N-2 G28*18
N-1 M107*39
Prepending them to a precalculated gcode script then would work out just fine. You'd still have to calculate the after-job gcode scripts but that doesn't significantly affect the job, right?
And then, the question: are gaps allowed in the sequencing?
If so, then one could precalculate the gcode file starting with N1000. You'd see a big gap but maybe that would still work out.
No negative numbers (even if some variants supported that, we need to be compatible to all) and no gaps. Gaps would kinda defeat the purpose of the numbers, the point is to detect missing ones.
Which it btw also doesn't need to do when printing from SD - no line numbers to check, no checksums to check. So way less overhead on both sides.
Could be fixed by a different protocol. But this is not going to happen (and I better not dive into explaining why because that will only make me angry again ).
Sounds like Marlin refuses to make a world of printing a little bit better.
I did some testing by disabling as much plugins as possible (I didn't have much), and the results are expected: one minute ahead on circular model (sd card "printed' in 4:50).
Have another one question: how to disable checksums ? Is it possible form the Settings ?
and it didn't speed up things at all in my measurements (lines per second for a file steamed to sd, measured repeatedly)