Ugh, well firmware updated and no change. Beeps at start of a print and fails.
octoprint (1).log (19.6 KB)
Okay, this is the serial log and one thing I can sort out is the question mark that appears in it?
Started print, then it started beeping after homing, then disconnected.
Maybe someone can translate this?
serial failed print start.log (17.3 KB)
I asked the same question over at Octoprint
The first reply thinks a bad cable. But I have I even swapped out to another. I have many othersâŚbut I donât know if thatâs entirely the issue.
But - thatâs the latest.
Can you try with a different computer with a clean install of Cura and do a basic test print? Could be a USB/COM port change on your system⌠but that really shouldnât matter since you said SD card is resulting in the same error.
Really just trying to exhaust the cheap/free options before blaming the board.
Right? It canât hurt.
I know a lot of things work great - until a Windows Update!
Different PC
New install Cura LE
New USB Cord
I got the same disconnection via Octoprint
serial.log (23.9 KB)
Connected USB directly to PC
Fired up Simplify 3D and used the Machine Tool interface to connect. No disconnects while there for 5 minutes.
Closed S3D, fired up Cura LE
Updated firmware.
On Taz 6 made sure 1.2mm HS Tool head was set and made sure esteps and offsets were OK.
Sliced print to SD Card, got the beep after homing X and Y.
Tried to print via USB connection, homed X then Y âŚsolid beep again.
Iâm completely stumped. It appears the Taz 6 somehow bricked itself?
Looking forward to your next video about how you upgraded your Taz 6 to an Archim 2!
Ok, something is up.
I see other posts about connection issues with Miniâs and it is identical to my issue.
I scrolled through the SD card for a print I did a year ago, probably with Cura 3.6 something. THAT IS PRINTING.
I donât know who to tag at Lulzbot but something you changed is causing prints not be able to be printed.
Post the startup portion of the GCODE from the old file so we can compare it to the cube_T6-HS+.gcode you posted earlier.
Itâs possible the old code is forcing a feedrate/acceleration factor that is low enough that the board isnât screwing it up.
Sure. Hereâs some that ran earlier
Cat_Food_Bowl_Holder10cm_T6-HS+.gcode (4.7 MB)
LTAZ6_WB_hotbox_feet_no_mount x3.gcode (3.5 MB)
Start gcode from Cat Food Bowl Holder print
;FLAVOR:Marlin
;TIME:22970
;Filament used: 38.0484m
;Layer height: 0.6
;MINX:53.217
;MINY:49.818
;MINZ:0.7
;MAXX:226.783
;MAXY:230.195
;MAXZ:145.3
;Generated with Cura_SteamEngine 4.13.0-BETAv2.12PATCHED
M82 ;absolute extrusion mode
;This G-Code has been generated specifically for the LulzBot TAZ 6 with a Universal Tool Head
;
;The following lines can be uncommented for printer specific fine tuning
;More information can be found at Gcode | Marlin Firmware
;
;M92 E420 ;Set Axis Steps-per-unit
;M301 P21.0 I1.78 D61.93 ;Set Hotend PID
;M906 E160 ;Digipot Motor Current ((875mA-750)/5+135) = 160
;M206 Y0 ;Set Home Offsets (default:0)
;
M73 P0 ; clear GLCD progress bar
M75 ; start GLCD timer
G26 ; clear potential âprobe failâ condition
M107 ; disable fans
M420 S0 ; disable leveling matrix
M900 K0.05 ; set linear advance
G90 ; absolute positioning
M82 ; set extruder to absolute mode
G92 E0 ; set extruder position to 0
M140 S65 ; start bed heating up
G28 XY ; home X and Y
G1 X-19 Y258 F1000 ; move to safe homing position
M109 R180 ; soften filament before homing Z
G28 Z ; home Z
G1 E-15 F100 ; retract filament
M109 R180 ; wait for extruder to reach wiping temp
;M206 X0 Y0 Z0 ; uncomment to adjust wipe position (+X ~ nozzle moves left)(+Y ~ nozzle moves forward)(+Z ~ nozzle moves down)
G12 ; wiping sequence
M206 X0 Y0 Z0 ; reseting stock nozzle position ### CAUTION: changing this line can affect print quality ###
M109 R160 ; wait for extruder to reach probe temp
G1 X-10 Y293 F4000 ; move above first probe point
M204 S100 ; set probing acceleration
G29 ; start auto-leveling sequence
M420 S1 ; enable leveling matrix
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 R225 ; wait for extruder to reach printing temp
M190 R65 ; 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
G92 E0
G92 E0
G1 F900 E-2
;LAYER_COUNT:243
;LAYER:0
M107
G1 F180 Z2.2
G0 F6000 X73.38 Y55.711 Z2.2
;TYPE:SKIRT
I suspect the M109 callout
@LulzMeister can you take a peek at the Start GCODE being generated with the Taz 6 profile in the latest version of Cura LE?
As best I can tell that generated start gcode shouldnât be giving you any problems, that should all work. Everything looks to be generating the way itâs intended.
Iâve actually run both your older non-problematic gcode and the newer one that youâve said gave you issues on a stock TAZ 6 we have in the office here and both of them made it through that part of the starting gcode just fine, so I am led to believe it may very well be a hardware issue of some kind, though the fact that different gcode files would work while others wouldnât is incredibly puzzlingâŚ
Iâm really suspicious of that comment from my original post.
Can you install the same tool head and try? HS 1.2mm
Is there something about it that youâre suspicious of? In the generated gcode that line has been correctly updated to
M109 R180 ; soften filament before homing Z
which is just requesting the machine wait until the hot end reaches 180C (soften/wipe temp) and should be identical to previous versions. That particular portion of the start gcode has not been touched since our 3.6 versions.
I donât know - I am just unsatisfied with the findings. This machine worked great a month ago, I did my YouTube video documenting the upgrades and good prints it was producing. Now, a few weeks later, upgrading the firmware and running the new Cura LE, itâs failing. But old gcode works - yet Octoprinnt still canât maintain a connection. Another thread has a same issue with Octoprint. Iâve tried 3 different new USB data cables - not chargers.
Something is up and I find it hard to believe it is the printer.
Any updates from the Firmware team about why Octoprint is failing to maintain a connection?
EMI is one possible cause. If you turn on serial logging in OctoPrint you should capture the communication failure. Looking at that could provide some insight.
Sorry I took a while replying.
After talking with other folks here who are more familiar with this type of issue than myself, weâre really not seeing anything that would be explained by the firmware or gcode file itself, especially since weâve been effectively unable to reproduce the issue in-house using a TAZ 6 w/ HS+ with the same firmware version and using the problematic gcode file youâve provided. Weâre a bit stumped on it to be honest.
The part that confuses me the most is the fact that older gcode files apparently still work for you, which shouldnât be the case if it was a firmware problem, and if the start gcode was the issue we should be able to reproduce the issue fairly easily in-house and would probably be getting swamped with reports of it since we do still have a very dedicated user base running TAZ 6s.
On b-morganâs suggestion, looking at those octoprint logs the board appears to be responding with some very jumbled text, so seeing that youâve already tried multiple different USB cables and this hadnât been a problem for you before I really am wondering if unfortunately the board has just gone bad, which again would also make it strange that youâve apparently been able to print older gcode files⌠or it could point to a poor firmware flash but youâve already re-flashed it so that doesnât really make sense either.
One thing that does keep coming to my mind is the SD card. When you save the slice from Cura LE did you save it directly to your internal drive or did you save it directly to the SD card? It could be the case that somehow youâre running with a corrupted gcode file if the SD card is going bad but⌠that also would seem odd that the one that you posted here runs fine for me! I really am just about out of ideas on this one to be quite honest with you.
H
For the files, they are saved to local drive then uploaded to Raspberry Pi/Octoprint. For SD card, they are saved directly to the SD card
Given how rare 8gb drives are, can the Taz see a 32gb SD card? I have many of those but was t sure if any special formatting needed to be done.