Page MenuHomeAleph Objects Inc

Extrusion from T1 while T1 disabled on Dual v3
Closed, ResolvedPublic

Description

When printing using dual v3 on TAZ6 printer moves in coordinates of T0 but extrude from T1. There is no switches to T1 in gcode. Firmware version: 1.1.5.70

Related Objects

Mentioned Here
T1: Test task

Event Timeline

TKostennov created this object with visibility "Cura LulzBot Edition (Project)".
TKostennov created this object with edit policy "Cura LulzBot Edition (Project)".

Printing using Octoprint. Reproduced at different layers.

karrad moved this task from Backlog to Stable release (v2.6) on the Cura LulzBot Edition board.
karrad added a subscriber: karrad.

@TKostennov I was able to produce gcode on TAZ 6 v3 dual extruder on 2.6.70 and 3.2.5


Before merging models, did you select each extruder to slice with a different too heal? (right click, select extruder for each model. Than select both models, right click, merge)


karrad reassigned this task from marcio to TKostennov.Feb 20 2018, 7:41 AM
karrad added a subscriber: marcio.

@karrad, second extruder is not used in this print, only one model loaded and assigned to first hot end, but while printing, it extrude from second hot end while it moves all toolhead correctly in coordinates of first hot end. Problem is not in gcode generation, it seems like bug in firmware, because it replicates every time on different layers. The result of this - skipped layers and broken print.

alexei changed the visibility from "Cura LulzBot Edition (Project)" to "Public (No Login Required)".Feb 21 2018, 5:27 PM
marcio added a comment.Mar 8 2018, 2:08 PM

@victor_larchenko : I'm wondering if T1 was selected from a previous print? Unless T0 is at the start of the print, the printer will remember whatever extruder was last used. The default toolhead could also be changed if a user performs a manual operation from the LCD. So Cura should always start a print by setting the toolhead to whatever it needs to be.

@marcio, Printer was power-cycled before print. Also this bug happens in middle of print on random(?) layers.

@lansky have you had any reports of this in the field?

@karrad No, we had a V2 user with the same issue but it was caused by the firmware being incorrect.

karrad closed this task as Resolved.Mar 28 2018, 11:46 AM

We have not heard of any other reports of this in the field, and am going to close it down. If this happens again on the 3.2 branch, we can re-open the ticket