Printer timeouts after upgrading from 1.4.0 to 1.4.2

What is the problem?

I've been using OctoPi with no issues for years now and after upgrading from 1.4.0 to 1.4.2 my printer is timing out. No other changes. On a Rpi 3B+. Seems to always happen in pre-setup where the printer is calibrating and warming up. I literally printed 1 dozen things last week on 1.4.0 with the same setup and had no issues. I had added the OctoPod plugin for fun but have been troubleshooting with that disabled just to remove that variable from the equation.

serial.log shows:
2020-08-08 20:53:13,194 - Recv: ok
2020-08-08 20:53:13,203 - Send: N51 M204 S30081
2020-08-08 20:53:13,210 - Recv: ok
2020-08-08 20:53:13,217 - Send: N52 G29
37
2020-08-08 20:54:03,316 - No response from printer after 6 consecutive communication timeouts, considering it dead. Configure long
running commands or increase communication timeout if that happens regularly on specific commands or long moves.
2020-08-08 20:54:03,409 - Changing monitoring state from "Printing" to "Offline (Error: Too many consecutive timeouts, printer sti
ll connected and alive?)"

What did you already try to solve it?

Rebooted numerous times and updated the serial connection from 30->40secs after applying that was posted to fix the setting saving issue.

Complete Logs

octoprint.log (161.5 KB) plugin_pluginmanager_console.log (102 Bytes) plugin_softwareupdate_console.log (621.9 KB) serial.log (13.6 KB)

Additional information about your setup

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

OctoPi 1.4.2
Lulzbot Mini printer
chrome Version 84.0.4147.105 (Official Build) (64-bit)
MacOs Mojave 10.14.6 (18G6020)
Cura lulzbot edition 3.6.8
df -h:
Filesystem Size Used Avail Use% Mounted on
/dev/root 7.1G 1.9G 4.9G 28% /
devtmpfs 433M 0 433M 0% /dev
tmpfs 438M 0 438M 0% /dev/shm
tmpfs 438M 5.9M 432M 2% /run
tmpfs 5.0M 4.0K 5.0M 1% /run/lock
tmpfs 438M 0 438M 0% /sys/fs/cgroup
/dev/mmcblk0p1 253M 53M 200M 21% /boot
tmpfs 88M 0 88M 0% /run/user/1000

1 Like

Hello @jasontaylor190!

And at first great thanks for a proper issue report! :+1:

Have you checked that G29 appears in the list of Long Running Commands?

Hi @Ewald_Ikemann,

Thanks for the speedy reply!

Yes G29 is in Long Running Commands... Note I also printed a number of things just fine last week on 1.4.0 with no changes to settings.

Thx,
J

2020-08-08 20:53:13,217 - Send: N52 G29*37
2020-08-08 20:54:03,316 - No response from printer after 6 consecutive communication timeouts, considering it dead. Configure long running commands or increase communication timeout if that happens regularly on specific commands or long moves.

If we look at the timestamps, its approximately 50 seconds from the sending of the G29 to the "No response". A G29 on my LulzBot TAZ 6 takes longer than 50 seconds to complete. I'd try increasing the number of timeouts for long running commands from 5 to maybe 10 and see if that helps.

BTW, you claim that this is a LulzBot Mini but the firmware isn't what I'd expect for that printer.

@b-morgan thanks for the tip. Will try the setting change and report back.

I definitely have a Lulzbot Mini. Can you let me know what about the firmware looks off? I'll try that route next. Thanks!!

@b-morgan FYI, Upping the settings from 5->10 didn't help:

Send: N50 M109 R17090
Recv: ok
Send: N51 M204 S300
81
Recv: ok
Send: N52 G29*37
No response from printer after 11 consecutive communication timeouts, considering it dead. Configure long running commands or increase communication timeout if that happens regularly on specific commands or long moves.
Changing monitoring state from "Printing" to "Offline (Error: Too many consecutive timeouts, printer still connected and alive?)"
Connection closed, closing down monitor

Is the printer controller the original RAMBO board? If so, then I'd get either 1.1.9.34 from http://devel.lulzbot.com/software/Marlin/1.1.9.34/ or 2.0.x from https://github.com/marciot/drunken-octopus-marlin.

CuraLE can flash the firmware or there is an OctoPrint plugin, Firmware Updater I believe.

I just looked at your serial log again and your firmware appears to be the right one but it is ancient.

2020-08-08 20:48:39,885 - Recv: echo:Marlin1.0.0
2020-08-08 20:48:39,887 - Recv: echo: Last Updated: Aug 10 2015 11:05:36 | Author: (Aleph Objects Inc, Mini-2015Q1)
2020-08-08 20:48:39,892 - Recv: Compiled: Aug 10 2015

I was thrown off by:

2020-08-08 20:48:42,084 - Send: N1 M115*39
2020-08-08 20:48:42,167 - Recv: FIRMWARE_NAME:Marlin V1; Sprinter/grbl mashup for gen6 FIRMWARE_URL:https://github.com/ErikZalm/Marlin/ PROTOCOL_VERSION:1.0 MACHINE_TYPE:Mendel EXTRUDER_COUNT:1 UUID:00000000-0000-0000-0000-000000000000

@b-morgan Thanks so much! I just flashed the most recent firmware from the cura-lulzbot edition and I seem to be back in business!!!

Thanks a million!!!!

Is there a way to stay up to date via octopi? I usually leave the Rpi in the basement with Octopi connected to the printer and I only access it remotely through cura from my laptop upstairs. If there is a way to keep the firmware updated through octoprint/octopi maybe I can avoid this problem in the future of getting so far behind?

Thanks again for taking the time and finding my problem. I greatly appreciate it!!!
Thx,
Jason

I use the plugin Firmware Updater which you can install via the Plugin Manager. The firmware doesn't update that often. When CuraLE is updated, the most recent / compatible firmware is included. You can find the firmware in:
C:\Program Files (x86)\cura-lulzbot 3.6\resources\firmware so I just browse to there in the plugin.

If you don't mind switching the USB cable once in a while, you can dispense with the plugin and just flash new firmware direct from CuraLE.

I've wrote down the parameters I had configured in octoprint "Serial Connection" section and started to play with that Upsers