Taz 6 Crashes w/ OctoPrint when probing fails (rewipe nozzle)

General LulzBot TAZ
1

What is the problem?

Taz 6 running MOARstruder crashes when asked for nozzle reclean.

Killed. Printer Halter. Please Restart

Thank you in advance.

What did you already try to solve it?
I have checked the start up GCode to the best of my abilities and have tried replicating the issue while printing from a computer. Only happens when printing through OctoPrint/Pi.

Simultaneously posting with Lulzbot community to see if there have been other similar issues and have compared gcode to the ones I found.

Additional information about your setup (OctoPrint version, OctoPi version, printer, firmware, browser, operating system, … as much data as possible )

OctoPrint: 1.3.12
OctoPi: 0.17.0 on RPi 4
Printer: Lulzbot Taz 6 (Marlin 1.1.9.34)
Browser: Chrome
OS: Windows 10
Slicer: Cura LE 3.6.20

2020-01-10 03:52:43,709 - octoprint.filemanager.analysis - INFO - Starting analysis of local:LTAZ6M_IdHolder.gcode
2020-01-10 03:52:43,712 - octoprint.filemanager.analysis - INFO - Invoking analysis command: /home/pi/oprint/bin/python2 -m octoprint analysis gcode --speed-x=6000 --speed-y=6000 --max-t=10 --throttle=0.0 --throttle-lines=100 /home/pi/.octoprint/uploads/LTAZ6M_IdHolder.gcode
2020-01-10 03:52:43,735 - octoprint.printer.standard.job - INFO - Print job selected - origin: local, path: LTAZ6M_IdHolder.gcode, owner: _api, user: _api
2020-01-10 03:52:43,744 - octoprint.util.comm - INFO - Changing monitoring state from “Operational” to “Starting”
2020-01-10 03:52:43,748 - octoprint.printer.standard.job - INFO - Print job started - origin: local, path: LTAZ6M_IdHolder.gcode, owner: _api, user: _api
2020-01-10 03:52:43,752 - octoprint.util.comm - INFO - M110 detected, setting current line number to 0
2020-01-10 03:52:43,764 - octoprint.util.comm - INFO - Changing monitoring state from “Starting” to “Printing”
2020-01-10 03:55:38,569 - octoprint.util.comm - WARNING - Received an error from the printer’s firmware: Probing failed
| Last lines in terminal:
| Recv: echo:busy: processing
| Recv: T:141.17 /140.00 B:60.05 /60.00 @:0 B@:32
| Recv: echo:busy: processing
| Recv: T:141.18 /140.00 B:60.00 /60.00 @:0 B@:38
| Recv: echo:busy: processing
| Recv: T:141.02 /140.00 B:60.03 /60.00 @:1 B@:32
| Recv: echo:busy: processing
| Recv: T:140.69 /140.00 B:60.01 /60.00 @:9 B@:35
| Recv: echo:busy: processing
| Recv: T:140.21 /140.00 B:60.06 /60.00 @:24 B@:27
| Recv: echo:busy: processing
| Recv: T:139.84 /140.00 B:60.04 /60.00 @:35 B@:30
| Recv: echo:busy: processing
| Recv: T:139.54 /140.00 B:60.08 /60.00 @:45 B@:23
| Recv: echo:busy: processing
| Recv: T:139.30 /140.00 B:60.04 /60.00 @:55 B@:28
| Recv: echo:busy: processing
| Recv: T:139.26 /140.00 B:60.02 /60.00 @:57 B@:30
| Recv: echo:busy: processing
| Recv: Error:Probing failed
2020-01-10 03:55:38,572 - octoprint.util.comm - INFO - Changing monitoring state from “Printing” to “Error: Probing failed”
2020-01-10 03:55:38,579 - octoprint.filemanager.analysis - INFO - Starting analysis of local:LTAZ6M_IdHolder.gcode
2020-01-10 03:55:38,579 - octoprint.util.comm - INFO - Force-sending M112 to the printer
2020-01-10 03:55:38,586 - octoprint.filemanager.analysis - INFO - Invoking analysis command: /home/pi/oprint/bin/python2 -m octoprint analysis gcode --speed-x=6000 --speed-y=6000 --max-t=10 --throttle=0.0 --throttle-lines=100 /home/pi/.octoprint/uploads/LTAZ6M_IdHolder.gcode
2020-01-10 03:55:38,634 - octoprint.util.comm - INFO - Changing monitoring state from “Error: Probing failed” to “Offline (Error: Probing failed)”
2020-01-10 03:55:39,020 - tornado.access - WARNING - 409 GET /api/printer (::ffff:192.168.1.124) 6.00ms
2020-01-10 03:55:39,036 - tornado.access - WARNING - 409 GET /api/printer (::ffff:192.168.1.124) 5.00ms
2020-01-10 03:55:40,000 - octoprint.filemanager.analysis - INFO - Analysis of entry local:LTAZ6M_IdHolder.gcode finished, needed 1.42s
2020-01-10 03:55:41,028 - tornado.access - WARNING - 409 GET /api/printer (::ffff:192.168.1.124) 9.16ms
2020-01-10 03:55:41,058 - tornado.access - WARNING - 409 GET /api/printer (::ffff:192.168.1.124) 10.57ms

2

I tried to submit this fix to Lulzbot but it didn’t get picked up. If you can build your own firmware it is an easy fix:

And maybe someone at Lulzbot will notice it here and get it submitted…

3

Is your nozzle clean as well as all of the leveling disks?

4

I have cleaned everything and have gotten the Taz to print but if there it needs to rewipe it crashes instantly instead of going to 170 and wiping (pla).

5

I had the same thing happened scared me to death first but took me a few days to figure it out . Change your printer head setting to Moarstruder Check and record nozzle Offset . Write it down. Update firmware for the printer head. If I remember right it should ask you in a popup box say yes. After firmware is updated go back to Offset and be sure nothing changed. If it did just reenter the number you wrote down. You must do this every time you change heads. Hope this helps.

6

I had and have had the same problem, posted about it a few years ago. I have a work around that kinda works, but isn’t the end all be all.

Basically octoprint can’t handle the probing sequence if a point fails. Even upping the response time after sending commands, it won’t work. So the probing needs to work every time - sorta. Clean and do all the suggestions on checking wiring, tuning, etc.

What I did is offloaded the startup macro to an octoprint macro. It will do all the bed leveling once, then stays leveled for a while. If it fails, you reprobe it until it works.

There are good and bad parts to it, but since I do a bunch of parts that can fail early on, it saves me a redo of a leveling sequence that can fail each time.

I think I or others posted the gcode for that, though lulzbot may have updated the start sequence since then. It’s pretty easy to just cut the start gcode almost completely and then paste it to an octoprint button (though maybe I used some addon to paste into a nice button, but it’s harder to edit it).

The one downside is you need to do a few small workarounds with octolapse because it wants to be zeroed each time - though I think he instituted a solution that works for me now if you care on that (straying from the topic).