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.
Logs (octoprint.log, serial.log or output on terminal tab at a minimum, browser error console if UI issue ... no logs, no support!)
serial.log (592 Bytes)
octoprint 2020-01-08.log (464.6 KB)
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
Hello @5280_Things!
The serial.log is quite empty. You may have to enable something. (See the log)
Two things I have found in the octoprint.log:
- The firmware complains an unknown command in the startup sequence
- The probing fails.
You may try again in safemode to exclude an issue caused by a plugin.
1 Like
| Send: N12 M113 S2*82
| Recv: ok N12 P15 B4
| Send: N13 G28*33
| Recv: echo:Unknown command: ""
Something doesn't look right here. OP sends line 12 and the printer indicates "ok" followed by the wrong line 12 response. Also, there's a generic serial error message. Treat this as a serial cable that doesn't have internal metallic shielding or a ferrite core... or undervoltage.
Also, it looks like you have something polling the printer status externally that has the wrong or an absent API key.
1 Like
Thank you both for the quick replies. I was able to successfully print a few objects but it happened again while watching so was able to grab the log right away.
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
I am noticing the probing fail part which is the main issue, but instead of reattempting the printer crashes. Would seeing the GCode help?
You might try to comment-out the probing command (G29?) to see if things try to work past that point.
EDIT: I seem to have solved the underlying issue. The probing is failing because the nozzle tip has too much surface area. I have noted previously that various nozzles work much better than others, if they have a aggressive cone with no or little flat at the tip. The nozzle on the volcano has a pretty big flat. Some very careful dremeling (with a painter's tape mask to keep bronze powder out of things) of the nozzle has solved the probing issue, so the crash issue is no longer triggered.
This isn't really a solution to this particular issue, more of a solution to the overall problem. It'd still be nice to see some better development of the TAZ firmware.
====Original response====
Hi there, I'm experiencing pretty much the same symptoms. The only difference in my case is that I'm using an aftermarket extruder designed to use the moarstruder firmware. (it's basically a e3d volcano on an aerostruder more or less). I have no reason to suspect the toolhead yet, but I'll be checking that with a multimeter etc just to be sure.
I get exactly the same weird thing in the logs, that Outsourcedguru noted, so I don't think it's a serial transmission issue, but instead something going very wrong in firmware.
I note that it's pushing a bit too much on the first corner during the bed level process then dies with the KILLED message on the LCD.
My current plan is to refresh the firmware just in case, check continuity of the nozzle to the pin connector to make sure I don't have a bad contact circuit, and then start delving into marlin firmware, but since I'm not really a coder I'm hoping somebody else manages to locate/kill the bug while I'm doing all that...
I'll grab a fresh log to post at some point in the process if I can, but when I first looked at this it was exactly the same. (and of course I can't find wherever I put the original log file since it's been two weeks).
Hope the data point helps though.
When my TAZ 6 pushes a corner too hard, 99% of the time I fix it by cleaning the nozzle (I also give the corner washers an alcohol rub). I do not have a MOARstruder but I do have several Single Extruders (V2.1), an Aerostruder, and a Dual Extruder V3.