I had a similar problem with Octoprint running on a Raspberry Pi (“OctoPi” image installed) connected to my Lulzbot Mini 1 with an standard head. I would get a “probe failed” error if the nozzle did not wipe clean, the printer would disconnect, and no further printer actions would occur. If instead I run Cura Lulzbot Edition on my Windows 10 laptop connected to the printer (i.e. no Octoprint), the bed-leveling sequence is interrupted, but the printer continues properly and retries wiping the nozzle.
The comment about timeouts makes me a little suspicious. A couple of months ago, my old laptop failed and I bought a new one. When I replaced the laptop with a new one, I reinstalled the latest version of Cura Lulzbot Edition. Since that time, I have seen two disconnects in the middle of long-running print jobs, and the head simply stops wherever it was. Before I replaced my laptop, I had never seen this happen.
I just replaced my standard printer head with an Aerostruder, so I anticipate that I won’t see as many probe failures. Still, I really don’t want to have to deal with the nuisance of reconnecting, homing the head, cleaning the nozzle manually, and losing the time needed to warm back up for another print job. I also want to continue to use Octoprint with the Raspberry Pi because it potentially eliminates the odd problem I had with disconnects from my laptop during long-running jobs and I don’t have to stay tethered to my laptop.
So if there is a variant of the above G-code for a Lulzbot Mini 1 with an Aerostruder head, I’d love to get my hands on it. I do have one specific question about the G-code posted. I don’t see commands in the above G-code for actually wiping the nozzle. Were they intentionally excluded? Does this G-code allow for multiple attempts at wiping the nozzle like Cura does?