Lulzbot Taz 6 fails when starting a print - beeps after homing

What is the problem?

Lulzbot Taz 6 3D printer, at start of a print, machine homes X and Y then beeps until print canceled.

I've checked the usual suspects. The machine can home on all axis's without issue. I am observing a lot of disconnections in Octoprint and trying to determine if I have an issue within Octoprint or the Taz 6.

I am also noticing the same issue printing from the SD Card. And USB via Cura LE.

I don't suspect this is Octoprint but the serial log is showing some question mark characters which I can't decipher.

What did you already try to solve it?

Made sure Octoprint is at the latest version.

Tested the Taz 6 can home XYZ, heat up nozzle and bed.

Have you tried running in safe mode?


Did running in safe mode solve the problem?

Did not try

Systeminfo Bundle

You can download this in OctoPrint's System Information dialog ... no bundle, no support!)

Attached Serial and Octoprint log files

Additional information about your setup

OctoPrint version, OctoPi version, printer, firmware, browser, operating system, ... as much data as possible

Windows 11 PC, Chrome Version 120.0.6099.216 (Official Build) (64-bit)

(upload:// (37.8 KB)
serial failed print start.log (17.3 KB)
octoprint.log (12.4 KB)

The complete Systeminfo bundle would have done the trick.

It appears that you have a quite bad USB connection:

2024-01-11 00:43:54,429 - Send: N0 M110 N0*125
2024-01-11 00:43:57,290 - Handshake attempt #2 with timeout 2.0s
2024-01-11 00:43:57,303 - Send: N0 M110 N0*125
2024-01-11 00:43:58,289 - Recv: ánHnJj5®Y<H.]‹ˆJ=j=><y„Myxñ^«h&ŠHŠXñJsÐ^ˆj@V³-“7·¨{æ'*àd6}P| a@(‹þg*À_D]p| '`(V«þ'j
2024-01-11 00:43:58,291 - WARNThe received line contains at least one null byte character at position 69, this hints at some data corruption going on
2024-01-11 00:44:00,306 - Handshake attempt #3 with timeout 2.0s
2024-01-11 00:44:00,327 - Send: N0 M110 N0*125
2024-01-11 00:44:02,791 - Trying port /dev/ttyACM0, baudrate 250000
2024-01-11 00:44:02,804 - Handshake attempt #1 with timeout 2.0s
2024-01-11 00:44:02,810 - Send: N0 M110 N0*125
2024-01-11 00:44:02,947 - Recv: á^ƒ;V7jOÌJŠYŠáÊ5æ'Zƒ&ƒøecho:busy: processing
2024-01-11 00:44:04,946 - Recv: echo:busy: processing
2024-01-11 00:44:04,950 - Printer seems to support the busy protocol, will adjust timeouts and set busy interval accordingly
2024-01-11 00:44:05,664 - Recv: X:-18.10 Y:303.50 Z:15.00 E:0.00 Count X:-2010 Y:30350 Z:24000
2024-01-11 00:44:05,673 - Recv: ok P13 B2
2024-01-11 00:44:05,691 - Changing monitoring state from "Detecting serial connection" to "Operational"
2024-01-11 00:44:05,709 - Send: N0 M110 N0*125
2024-01-11 00:44:05,838 - Recv: echo:Unknown command: "˜€ø˜"
2024-01-11 00:44:05,841 - Recv: ok P13 B2
2024-01-11 00:44:05,849 - Send: N1 M115*39
2024-01-11 00:44:05,850 - Recv: ok N0 P13 B3
2024-01-11 00:44:05,856 - Send: N2 M21*18
2024-01-11 00:44:05,868 - Recv: ok N0 P13 B3

I thought that was attached? Here it is.

I have tried 2 different USB cables. (39.3 KB)

The issues with the connection you have is mostly a result of EMI.

This can be caused by high power devices near by and/or on the same power line.
Also a high quality USB cable is recommanded - and as short as possible.


You may also read this:

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.