OctoPrint disconnects after printer asks to re-Wipe

Since updating to latest Marlin firmware my OctoPrint disconnects if the printer reports it needs to rewipe before printing. Octoprint will report a firmware error and disconnect. the printer will keep running the auto level sequence and after rewiping will touch all four corners and wait for more instructions from OctoPrint. Using Aerostruder tool head on Taz 6 Octoprint version latest 1.3.10…

Is anyone else experiencing this issue? Is there any work around? My bed is fine, washers clean, nozzle clean, nothing is loose, ground wire on bed is firm. I’m convinced this is firmware related as the bed levels itself the 2nd time nearly every time.

Also, since updating to new firmware, only one nozzle on my V3 will wipe on the pad, the right nozzle just grazes the outside edge.

Thank you! I was meaning to post this myself yesterday and wasn’t sure if I was going to get unlazy and post tonight, but I have exactly this problem!

I’m running the Taz 6 v3 head and I’m always getting this from every test I tried. EXTREMELY frustrating! I DID have 2 related workarounds that I’d been using until this weekend: first I deleted the autoleveling and moved it to a macro on the pi so I’d only level once and then run from there (this kills octolapse I just found out). Second there had been a workaround to increase the timeout before the pi considers the connection dead. It was working until this weekend on that macro, but doesn’t seem to be working anymore.

I’m also getting this odd/useless new thing poping up telling me to click on the Taz to continue. Think that’s interfering with some connections (it’s actually cool if useful for filament changes and other stuff mid print if there’s good documentation on how you code it).

This problem has led me to abandon cura and normal octoprint stuff until I can get some help like too! Can’t understand how they can’t work that out if they’re working on octoprint too.

Thanks if anyone can work on this and help!

Thought I’d follow up on this with my progress and with an email back from lulzbot. I’m still working on it, but this is where I’m at:

  1. Tuning the autoleveling to hopefully not need rewipes (and also get a nicer level) - cleaning and fixing some connections through email directions that may help
  2. Upping my timeout options on Octoprint - https://community.octoprint.org/t/octoprint-keeps-running-into-communication-errors-and-timeouts/227 is the centerpiece. (Note it’s now under intervals and timeouts tab in the updated Octoprint). The re-wiping is still part of the G29 probe sequence command, and should be part of the “long running commands” subset.

I’m just going to up the max consecutive timeouts while printing/long running commands as well. Alternatively, you could just set all to 0 and it should get rid of this timeout problem. I’m not sure if that’s a good idea, but if the printer is dropping out of communication from this timeout anyway, I’m not sure if there would be any difference between octoprint knowing it’s timedout and it just pinging away forever. Maybe I’ve just talked myself into disabling timeout things and not worrying since I don’t see a time that’s ever going to be useful for me anyway.

Same problem as the OP.

I can tell just before it disconnects because by the time it gets to the 3rd disc to “tap”, it stops short of the metal disc about 10mm, tries to tap but misses, by dropping below it… then disconnects.

I’m finding that after each print, I have to disconnect, and reconnect which forces the Taz 6 to restart. Then it prints. But if I print again right after one completes, it does the disconnect error.

I know it’s going to fail because I watch the extruder wipe, then move to the first pad and RAISE an additional cm. It doesn’t even try to lower down to the first pad. It goes upwards, instead, like it’s been sent a positive Z coordinate instead of a negative.

It happens with every subsequent print after a reset of the printer power and reconnect with Octoprint OR CURA Lulzbot Edition when connected by USB to my PC. I have power cycle, then auto-home, between every print job.

I had this problem as well. It is caused by older start gcode that doesn’t deal with the bed leveling commands properly.

Here is the sample gcode Lulzbot sent me. I updated my start gcode to use the new commands and the problems went away.

;This G-Code has been generated specifically for the LulzBot TAZ 6 with standard extruder
M73 P0 ; clear GLCD progress bar
M75 ; start GLCD timer
G26 ; clear potential 'probe fail' condition
M107 ; disable fans
M420 S0 ; disable previous leveling matrix
G90 ; absolute positioning
M82 ; set extruder to absolute mode
G92 E0 ; set extruder position to 0
M140 S{material_bed_temperature} ; start bed heating up
M109 R{material_soften_temperature} ; soften filament before homing Z
G28 ; Home all axis
G1 E-30 F100 ; retract filament
M109 R{material_wipe_temperature} ; wait for extruder to reach wiping temp

M109 R{material_probe_temperature} ; wait for extruder to reach probe temp
G1 X-9 Y-9 ; move above first probe point
M204 S100 ; set probing acceleration
G29 ; start auto-leveling sequence
M420 S1 ; activate bed level matrix
M425 Z	    ; use measured Z backlash for compensation
M425 Z F0	    ; turn off measured Z backlash compensation. (if activated in the quality settings, this command will automatically be ignored)
M204 S500 ; restore standard acceleration
G1 X0 Y0 Z15 F5000 ; move up off last probe point
G4 S1 ; pause
M400 ; wait for moves to finish
M117 Heating... ; progress indicator message on LCD
M109 R{material_print_temperature_layer_0} ; wait for extruder to reach printing temp
M190 S{material_bed_temperature_layer_0} ; wait for bed to reach printing temp
G1 Z2 E0 F75 ; prime tiny bit of filament into the nozzle
M117 TAZ 6 Printing... ; progress indicator message on LCD

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?

If it is disconnecting after a wipe failure, try changing the error handling to “cancel but stay connected” instead of “disconnect”.

Thanks for the response. I changed that setting, but unfortunately I can’t currently verify if that fixed it. My new Aerostruder tool head has jammed and I can’t print with it. I will have to get support from Lulzbot to fix that problem first.

I changed the behavior setting, but I haven’t seen a “probe failed” error in a couple of months.