Octoprint prints slowly compare to sd card


Octoprint prints slowly compare to sd card.

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.

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.


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.

Thank you for helping !


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.


In terminal I see such lines:

Recv: ok
Send: N297077 G1 X159.828 Y75.523 E1419.7956895
Recv: ok
Send: N297078 G1 X160.191 Y75.481 E1419.80784
Recv: ok
Send: N297079 G1 X160.475 Y75.309 E1419.8188885
Recv: ok
Send: N297080 G1 X160.598 Y75.292 E1419.82301
Recv: ok
Send: N297081 G1 X161.281 Y74.937 E1419.8486190
Recv: ok
Send: N297082 G1 X161.606 Y74.623 E1419.86364
Recv: ok
Send: N297083 G1 X161.775 Y74.502 E1419.8705580
Recv: ok
Send: N297084 G1 X161.862 Y74.546 E1419.8738
Recv: ok
Send: N297085 G1 X162.367 Y74.867 E1419.8937102
Recv: ok
Send: N297086 G1 X162.506 Y74.899 E1419.89844
Recv: ok
Send: N297087 G1 X162.545 Y74.894 E1419.8997581
Recv: ok
Send: N297088 G1 X162.762 Y74.941 E1419.90714
Recv: ok
Send: N297089 G1 X163.067 Y74.823 E1419.9180192
Recv: ok
Send: N297090 G1 X163.217 Y74.728 E1419.92392
Recv: ok
Send: N297091 G1 X163.632 Y74.558 E1419.9388493
Recv: ok
Send: N297092 G1 X164.031 Y74.665 E1419.95257
Recv: ok
Send: N297093 G1 X164.37 Y74.769 E1419.96437106
Recv: ok
Send: N297094 G1 X164.607 Y74.92 E1419.97372
Recv: ok
Send: N297095 G1 X164.872 Y75.03 E1419.98326102
Recv: ok
Send: N297096 G1 X165.34 Y75.116 E1419.99908
Recv: ok
Send: N297097 G1 X165.682 Y75.154 E1420.0105392
Recv: ok
Send: N297098 G1 X166.04 Y75.171 E1420.02245
Recv: ok

I mean I don't see re-send indications there


@foosel is probably your best bet here.

I suppose... I'd then try one print where I'd toggled off these two checkboxes under Settings -> Serial -> Behavior:

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.

There's not a ton that can be done about this.


I see, ok, thank you, I'll try these tomorrow.
Also I'll try few print speeds (60 and 120mm/sec) to see how it impacts on final print time.


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.


So that all basically means that octoprint needs more computing power which Raspberry 3 model B+ can provide, right ?

Hm.... Also there can be some printing speed (like 60mm/sec) at which... No, it depends on line distance (how fast printer executes command).

Yeah, its more complicated than i thought it is :slight_smile:


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:

  1. assign a line number and prefix it
  2. calculate the checksum of just the prefix
  3. 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.


That is exactly what I did :wink: and it didn't speed up things at all in my measurements (lines per second for a file steamed to sd, measured repeatedly)


I was just editing my last post, btw.


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.


And even if there are some milliseconds saved per line, the firmware has to back calculate the checksum to confirm the correct content of the line.


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 :wink: ).


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 ?

Thank you