How to "Configure long running commands or increase communication timeout"?

Context: I built myself a button box, tactile buttons, d1 mini, mqtt. Then there's a daemon subscribed to that topic, adding the actual button actions. Lot's of fun with it, OctoPrint is so open for that.
Lighting and job controls were easy, now bed level measurement.
I really like the GCODE I have for that in the bed visualizer plugin so I copied that lines and send them to the api as commands
Works like a charm, really feels like the printer+octoPrint+the remote and programing are a robot. I click a button and the printer turns on, Octoprint connects to it, my program gets all the info about printer state and job state, sends the list of GCODEs , everything get's executed, fine. But!

What is the problem?

After all is successfully done OctoPrint's UI gives me an ugly box with red text top right regarding timeouts and considering the printer dead and advising me to configure long running scripts.

I'm a bit surprised, it's the very same sequence of GCode whether I run it through the blv's 'update mesh now' or from the GCODE sent by my script to octoPrint. M155 S90 and all. G29 takes ages to complete, true. Do I have to configure OctoPrint for it, and where?

Looking at the serial.log it's like green checks all the way down, one or two yellow TBD and then a fat red cross at the last line.


What did you already try to solve it?

Scratch my head, mostly. Searched the site and got recommendations to tape the 5V etc., not the problem I have. I know how to avoid the effect but I wonder why it happens.

Have you tried running in safe mode?

no, doesn't apply

Did running in safe mode solve the problem?


Systeminfo Bundle

You can download this in OctoPrint's System Information dialog ... no bundle, no support!)


Additional information about your setup

OctoPrint version, OctoPi version, printer, firmware, browser, operating system, ... as much data as possible

The piece of code that starts the measurement is:

def doStartLeveling(param):
    print("doStartLeveling called")

    dJson =   {
  "commands": [
    "M117 Prepare the bed level measuring", 
    "M140 S60" ,
    "M117 Homing all axes",
    "M117 Heating the bed ",
    "M190 S60",
#    "M155 S90",
    "M117 Start the dance",
    "G29 T",
    "M140 S0",
    "M117 fertig!"
    payload = json.dumps(dJson)
    command = 'curl -s -X POST  -H "Content-Type: application/json" -H "X-Api-Key":"ABCDEFGHIJKLMNO" -d \'{}\' http://kiwi.intern/api/printer/command'.format(payload)
    stream = os.popen(command)

When I set a comment in front of "M155 S90", the error does not happen.
But why does that line (and the significantly less temperature reportings) irritate octoPrint when it passed that via the api while it stays relaxed when the call came from the plugin?

Even you set the M155 interval to 90 seconds, the messages come every minute:

2021-09-01 21:40:54,114 - Recv: echo:busy: processing
2021-09-01 21:40:56,040 - Recv:  T:25.43 /0.00 B:58.48 /60.00 @:0 B@:0
2021-09-01 21:41:56,044 - Recv:  T:25.45 /0.00 B:61.41 /60.00 @:0 B@:0
2021-09-01 21:42:56,045 - Recv:  T:25.45 /0.00 B:60.03 /60.00 @:0 B@:127
2021-09-01 21:43:56,048 - Recv:  T:25.45 /0.00 B:59.00 /60.00 @:0 B@:0
2021-09-01 21:43:57,664 - Recv: echo:busy: processing

Have you tried another value for M155 (e.g. 45) or another position in the script?

Thanks for looking into it!
You are right, just checked and the same thing happens when I call it through the plugin. Without diving into Marlin I guess it's some hard coded minimum over there.
The other thing is that the whole procedure runs ok with "M155 S90" commented out and I believe plugin author recommended it out an abundance of caution. Serial traffic might interfere with the measurements.
I set it to M155 S30 and that gave me temp. reports every 30sec. But the final error message came as well.

2021-09-02 11:08:36,159 - Recv:  T:25.45 /0.00 B:58.63 /60.00 @:0 B@:0
2021-09-02 11:08:36,402 - Recv: echo:busy: processing
2021-09-02 11:09:06,159 - Recv:  T:25.45 /0.00 B:60.68 /60.00 @:0 B@:0
2021-09-02 11:09:23,875 - Recv: //action:notification Printing...
2021-09-02 11:09:24,482 - Recv: echo:busy: processing
2021-09-02 11:09:26,048 - Recv: Bilinear Leveling Grid:
2021-09-02 11:09:26,057 - Recv:       0      1      2      3
2021-09-02 11:09:26,060 - Recv:  0 -0.041 -0.018 +0.037 +0.067
2021-09-02 11:09:26,065 - Recv:  1 +0.040 -0.001 +0.024 +0.074
2021-09-02 11:09:26,071 - Recv:  2 +0.047 -0.001 +0.050 +0.045
2021-09-02 11:09:26,077 - Recv:  3 -0.065 -0.051 +0.016 +0.084
2021-09-02 11:09:26,080 - Recv: 
2021-09-02 11:09:26,088 - Recv: X:235.00 Y:235.00 Z:12.67 E:0.00 Count X:18800 Y:18800 Z:5068
2021-09-02 11:09:26,097 - Recv: ok
2021-09-02 11:09:26,104 - Send: M500
2021-09-02 11:09:26,125 - Recv: echo:Settings Stored (649 bytes; crc 27305)
2021-09-02 11:09:26,243 - Recv: //action:notification Settings Stored
2021-09-02 11:09:26,248 - Recv: ok
2021-09-02 11:09:26,251 - Send: M140 S0
2021-09-02 11:09:26,280 - Recv: //action:notification Bed Cooling...
2021-09-02 11:09:26,298 - Recv: //action:notification 2021-08-25_1 toko SKR-min-E3_V1.2 Ready.
2021-09-02 11:09:26,323 - Recv: ok
2021-09-02 11:09:26,330 - Send: M117 fertig!
2021-09-02 11:09:26,372 - Recv: //action:notification fertig!
2021-09-02 11:09:26,380 - Recv: ok
2021-09-02 11:09:26,382 - Send: M113 S2
2021-09-02 11:09:26,398 - Recv: ok
2021-09-02 11:09:35,426 - No response from printer after 3 consecutive communication timeouts, considering it dead. Configure long running commands or increase communication timeout if that happens regularly on specific commands or long moves.
2021-09-02 11:09:35,483 - Changing monitoring state from "Operational" to "Offline after error"
2021-09-02 11:09:35,508 - Connection closed, closing down monitor

I did experiment then, adding a M113 S2 after the M155 S30. No change.
Tried to disable the timeout checking with maxTimeoutsLong=0. No change.

There is a gap between the Recv: ok and the error message of about 9 seconds where the printer firmware did not send any message to OctoPrint.
So the culprit is to be assumed within the firmware.

1 Like

Yes, thanks for that. I simply had to M155 S2 after the measurement is done.

1 Like

This probably occured because you changed the timeout manually over the serial connection - OctoPrint expects the printer to report whenever it told it to originally.

That said, I thought communication timeouts sometimes sent commands to try and wake up the printer. Maybe there's some specific conditions - I haven't dug into the communication layer much.