Pinter timeout and disconnecting while mesh probing in progress [SOLVED]

[alexw22]

I am experiencing the same issue as described here in issue #370. My printer disconnects from octopi while doing the bed probing. I have a 5x5 mesh as its quite a large build plate I have.

I have verified that my G29 command is in the Long Running Command section of Firmware & protocol > Advanced Options as described there and my entries look just like the screenshot in #370.

What parameter setting in octoprint would be adjusting the timeout so that I can increase it. I have tried my luck however without success until now. (I have been increasing: Serial connection -> Intervals & timeouts -> Communication Timeout -> busy protocol support not detected to 300s however no luck until now) I am able to overcome the issue manually by toggling my part cooling fan on and off while probing in order for the probing finish and mesh to be generated properly.

I would highly appreciate any feedback on this :)

[jneilliii]

Jyers firmware?

[alexw22]

Marlin 2.0.7.2 I hope this is what you were asking for.

[jneilliii]

Yeah, there was a known issue with jyers fork of marlin with leveling that would cause problems like you describe. If you haven't installed that then probably not the issue. Do you know what type of auto bed leveling is enabled? Basically it's your printer that stops responding during the process, causing octoprint to think the printer is dead. Other possible causes is your firmware expects an sd card in the printer to save eeprom data. Only way to truly diagnose is enable serial logging in octoprint's settings and try the process again, then share your serial.log file. That will tell us for sure if it's firmware or not.

[alexw22]

To my knowledge I did not install jyers. I just installed Marlin of the official website and edited the config to fit my needs/printer. I am using a genuine BlTouch sensor. I added a serial log file below.

I enabled serial logging and re-ran the bed probing procedure. It disconnected while the bed was still heating up. I don't think however that it has anything to do with the heating/power. I'm expecting it to be just some timer that disconnects octoprint after a set amount of time. Im sure if i reran it now it would manage to heat up to 60 and start probing and disconnect while probing (what I was describing previously).

Hopefully this gives you enough information. I am happy to provide any other information if necessary. serial_log.txt

[jneilliii]

Can you do me a favor and try adding M75 at the beginning of your gcode commands in the plugin's settings and add M77 at the end of it?

[alexw22]

Have done that just dat. It however did not make a difference unfortunately. [Edit: I added all the contents of the plugin settings command] The GCODE commands for mesh update process looks like this now:

M75 ; Start the print job timer M140 S60 ; starting by heating the bed for nominal mesh accuracy M117 Homing all axes ; send message to printer display G28 ; home all axes M117 Heating the bed ; send message to printer display M190 S60 ; waiting until the bed is fully warmed up M300 S1000 P500 ; chirp to indicate bed mesh levels is initializing M117 Creating the bed mesh levels ; send message to printer display M155 S30 ; reduce temperature reporting rate to reduce output pollution @BEDLEVELVISUALIZER ; tell the plugin to watch for reported mesh G29 T ; run bilinear probing M155 S3 ; reset temperature reporting M140 S0 ; cooling down the bed M300 S440 P200 ; make calibration completed tones M300 S660 P250 M300 S880 P300 M117 Bed mesh levels completed ; send message to printer display M77 ; Stop the print job timer

[jneilliii]

And it disconnects during the heat up process? Does it do the same if you send those commands from the terminal tab? Try with just G29 instead of G29 T maybe.

[alexw22]

If the bed is cold yes. And it does not advance to probing the bed. I imagine because the disconnect happens before the bed probing GCODE is sent. Then If i reconnect and cancel and restart the bed probing process it warms up and starts probing and disconnects while probing. Finishes the probing process but does not display anything because while octoprint is already disconnected it never receives the bed probing data.

I did change the G29 T entry to G29 and it disconnected at 55 degrees on the bed. I imagine that the results is similar to what was happening before as the bed might have been slightly preheated as I am calibrating/dialing in slicer parameters and have printed something not too long ago.

Again I can help the probing process to finish successfully when toggling the part cooling fan on and off in frequent intervals under the control tab in Octoprint to help prevent the printer from disconnecting.

[alexw22]

I did receive this error message just now after finishing another calibration print:

Bed Visualizer Error Timeout occured before processing completed. Processing may still be running or there may be a configuration error. Consider increasing the Processing Timeout value in settings and restart OctoPrint.

Wondering what Processing Timeout value in settings it is referring to!

[jneilliii]

If octoprint disconnects before receiving the response from firmware the plugin will never work. But that timeout is the one on the collection tab if the plugin's settings. It will basically make the processing stuff go away.

[alexw22]

When I preheat before a print, it never disconnects though. I don't understand how this is different. I just checked that value and it is set to 1800 seconds (by default) so that would be 30 minutes. It definitely manages to heat up and probe within that amount of time.

[jneilliii]

Your previous serial log didn't even make it to temp, so what is reported manually running G29?

[alexw22]

While running G29 manually in the octoprint terminal tab, it does not disconnect.

[jneilliii]

And what does it return at the end of the process?

[alexw22]

It did return the bed matrix in the terminal after it finished. If you need the serial output I would have to re-run the command manually tomorrow. Please let me know if you would like me to do that.

So when running G29 manually it finishes without disconnects and appears to return the expected output in the terminal tab. When I run the GCODE sequence (I posed above) through the plugin it disconnects after some amount of time while heating the bed/probing.

[jneilliii]

That's what is confusing me. The way the plugin works is basically doing the same thing as sending the commands manually. Let's simplify your settings. Replace the collection commands with just the following.

G28
@BEDLEVELVISUALIZER
G29

Manually heat the bed to desired temp, and then attempt the mesh collection. Let's see where we get with that. Then we can slowly add in one command at a time to that to see what command is causing the issue.

[alexw22]

I changed the list of commands to the 3 commands above. The printer disconnected while heating up the bed manually! But I tired one more time and reconnected and continued to heat up the bed to 60 after which I started the probing with the 3 commands from above through the plugin. It again disconnected while probing. However what is interesting is that when starting a print file within octoprint through the web interface (which obviously heats up the bed before starting to print) it does not cause a disconnect while heating up the bed/printing. I am still very puzzled by what is going on.

[jneilliii]

My best guess is that some timeout is happening in firmware. I'm not 100% sure why, but this is obviously not a plugin problem if OctoPrint is disconnecting while heating up manually. Sorry I couldn't be more help, I suggest hitting up the forum or OctoPrint discord about the disconnect during heating.

[alexw22]

TLDR: Check your other plugins related to power management. In my case it was the "PSU Control" plugin that had its variables changed after a plugin update and was causing the disconnects but failed to shut the printer down. Again because a number of variables were off after the update.

I managed to narrow it down to what the issue here is. I am just including it here in case anyone is experiencing something similar. Exactly What you are saying. This lead me to believe it must be in the firmware because it seems like it is happening outside of the plugin. I checked all of the firmware line by line to look for any timeouts. I didn't find any but then it the idea came up that it could be another plugin that can cause the issue. So I checked the plugins that were installed earlier. I recently updated octoprint and all plugins. For some reason the "PSU control" plugin reset some values and caused the printer to disconnect after 2 minutes. Because it appears that more variables were changed after the update the PSU control did not manage to turn the printer off but did disconnect.

Thank you jneilliii for your support and efforts in troubleshooting this issue!