Force OctoPrint to continue after first firmware report

What is the problem?
Printer keeps reporting a firmware error on the first try.

What did you already try to solve it?

Logs (octoprint.log, serial.log or output on terminal tab, browser error console ...)

Recv: echo:busy: processing
Recv: Error:Probing failed
Changing monitoring state from "Printing" to "Error: Probing failed"
Changing monitoring state from "Error: Probing failed" to "Offline (Error: Probing failed)"
Connection closed, closing down monitor

Additional information about your setup (OctoPrint version, OctoPi version, printer, firmware, browser, operating system, ...)
Is there a way to force OctoPrint to continue after the 1st firmware error report? Some how my printer always fails on the fist bed leveling/wipe. Its getting to be come a irritant that I have to re-connect to my printer after each time.

Thank you.

If there is a problem with your printer, you should fix it...

1 Like

Far as I can tell there isn't... It's from it not sensing contact with the bed because it's not wiping good enough, so the printer sends a new command to wipe it again. That's where Octoprint disconnects. But yet it still passes the wipe. Then it just sits there because OctoPrint is already disconnected.


So there is an issue. You may fix that switch.
And at last,it's not an issue with OctoPrint: If your printer reports an error - whatever it is - OctoPrint denies to cooperate with the printer.

@AceSG1, we already talked about this, but I wanted to post this here for anyone else running into this problem.

The issue is that OctoPrint is seeing that 'error' response and is assuming (probably rightly) that there has been a critical error. It then automatically disconnects, even though your printer works to correct the error. Honestly you should probably contact the probe folks and have them change this in their firmware. However, you might be able to fix it by telling Octoprint to ignore those kinds of errors.

Try setting that to ignore. However, as the warning states, this could cause other critical errors to go undetected, so use at your own risk!

So, according to @foosel, there is a new hook that could be used to solve this issue the right way. With it you can add errors that should be treated as non-fatal. I will consider creating this, but have no way to test.

Here is a link to the docs for the hook.