Why does Octoprint send M105 when M155 Autoreport active?

Get Help
1

What is the problem?
I have a CR10 Mini using an MKS Gen L board. It prints really well off the SD card but I get stutters when printing with OctoPrint.

Looking at the terminal out put I can see that there's a communication timeout followed by a checksum error and a resend request. These only happen when an M105 is sent to the printer. I don't see why Octoprint is polling for temperature when M155 Autoreport is active and working. Here's a snippet of the terminal output.

Send: N510 G1 X110.220 Y123.404 E19.4474109
Recv: T:215.47 /216.00 B:60.00 /60.00 @:77 B@:38
Recv: T:216.15 /216.00 B:60.00 /60.00 @:66 B@:37
Recv: T:216.25 /216.00 B:60.02 /60.00 @:64 B@:30
Recv: T:215.78 /216.00 B:59.95 /60.00 @:72 B@:51
Communication timeout while printing, trying to trigger response from printer. Configure long running commands or increase communication timeout if that happens regularly on specific commands or long moves.
Send: N511 M10534
Recv: Error:checksum mismatch, Last Line: 509
Recv: Resend: 510
Recv: ok
Send: N510 G1 X110.220 Y123.404 E19.4474109
Recv: ok
Send: N511 M10534
Recv: ok T:215.78 /216.00 B:59.95 /60.00 @:72 B@:51
Send: N512 G1 X132.185 Y101.440 E20.4392*102

What did you already try to solve it?

I have adjust the polling and autoreport intervals and can see that changing these can reduce the number of communications errors if the polling period is lengthened.

It seems that the printer is struggling to service the G1 command when it gets the M105, causing the timeout. The 'problem' would go away if the M105 wasn't sent when the M155 reports are active. I don't understand why this doesn't happen. Is there a way to turn off M105 requests?

Additional information about your setup (OctoPrint version, OctoPi version, printer, firmware, octoprint.log, serial.log or output on terminal tab, ...)

Octoprint 1.3.10
Marlin 2.0 bugfix with BLtouch and Linear Advance

2

timeouts
timeouts.png982×561 24.2 KB

Here are my current settings. I've bumped the comms timeout to 40s

3

Because it's a command that can be used to trigger a response from the printer in case of a communication timeout without side effects.

Looking at your log, the M105 isn't the problem. The problem is rather that for some reason the printer never got line 510, which is also why the printer never acknowledged it, so OctoPrint ran into a communication timeout, tried to trigger a response by sending an M105 with line number 511, which the printer did get and complain about then because it wasn't consecutive and thus requested a resend of 510 which resolved the problem.

So, M105 is not triggering these errors. Something else is and M105 is only making them visible, as would any command sent to the printer on communication timeout.

4

Thanks Gina,

Sounds like I was blaming the symptom not the cause!

I'm going to try turning of LINEAR_ADVANCE to see if that gives an indication of whether the Mega2560 is getting to it's limits on fast and short extrusions.