Curaengine: [3.6.0] Slicing for second extruder does not work like before.

Created on 12 Dec 2018  路  10Comments  路  Source: Ultimaker/CuraEngine

Application Version
3.6.0

Platform
Mac OS X - Darwin

Qt
Official Ultimaker website

PyQt
Official Ultimaker website

Display Driver
Intel Iris Pro 1536 MB graphics

Steps to Reproduce
CuraEngine slice -j dual_extruder_printer.def.json -s adhesion_extruder_nr=1 -e1 -l 'file.stl' -o 'output.gcode'

Actual Results
output.gcode is printing on T0 extruder

Expected results
output.gcode is printing on T1 extruder

Additional Information
Slicing on second extruder was working fine on version 3.5.1. I can create repository with example dual_extruder_printer.def.json if needed. I suppose there were changes regarding extruders_enabled_count and probably some more values that I should consider in my def.json? The worst part is that it's not failing, but it proceeds to generate gcode with print on T0 silently.

Most helpful comment

Hi @ipepe Thanks for the effort. I can see that in the machine_start_gcode value hardcodes values for T, the tool-switch command. We give a T command _before_ the start-gcode, so that the start-gcode can run on the selected extruder.

In general, at this moment, we don't really support hard-coding extruder-switch commands, though someting like this can be realized with T{initial_extruder_nr}\n. You can't select the 'off' extruder this way though, since there might be more than 2 extruders.

See also this, a related issue.

All 10 comments

There is an incorrect value in the fuction "sliceNext()".It seems always use the setting of extruder 0 to slice.
try to use
if (!loadMeshIntoMeshGroup(&slice.scene.mesh_groups[mesh_group_index], argument.c_str(), transformation, *last_settings))

instead of

if (!loadMeshIntoMeshGroup(&slice.scene.mesh_groups[mesh_group_index], argument.c_str(), transformation, last_extruder.settings)

Well that sounds great... But that also means that I should compile Windows, Linux and Mac version of library. And that does not sound so great...

If You are aware of this issue, then why it's not merged?

_Possible_ duplicate of (frontend) issue, in which case it was fixed already (see #974, will be in the _second_ 4.0-BETA, which isn't out yet).

@ipepe, Please note that @WinstonMao isn't part of the team and can't merge anything into our repo here.

Thanks for information. I will compile latest version from 4.0 and confirm if is it fixed or not.

Today I tried slicing on extruder T1 with supports and adhesion on T1 and I could not generate a satisfactory gcode file no matter what switches I used.

Hi @ipepe, Could you send dual_extruder_printer.def.json and the input .stl? You can post them here if you rename the files to have a .zip extension, so you don't have to make an entire repository just for a bug-report.

Hi @rburema.
I created https://github.com/ipepe/CuraEngine-second-extruder-slicing for You to look into.

Hi @ipepe Thanks for the effort. I can see that in the machine_start_gcode value hardcodes values for T, the tool-switch command. We give a T command _before_ the start-gcode, so that the start-gcode can run on the selected extruder.

In general, at this moment, we don't really support hard-coding extruder-switch commands, though someting like this can be realized with T{initial_extruder_nr}\n. You can't select the 'off' extruder this way though, since there might be more than 2 extruders.

See also this, a related issue.

@rburema Thanks for explanation

@rburema Wierd thing is that when sliced using same start/end gcode using Full Cura (Desktop GUI) it manages to set T1 just after starting Layer -6

Was this page helpful?
0 / 5 - 0 ratings

Related issues

CCS86 picture CCS86  路  13Comments

Timocop picture Timocop  路  3Comments

smartavionics picture smartavionics  路  13Comments

ghost picture ghost  路  13Comments

ghamrawyk picture ghamrawyk  路  5Comments