New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Slic3r messing up on extruder order #3235

Open
RepRapMe opened this Issue Feb 9, 2016 · 3 comments

Comments

Projects
None yet
4 participants
@RepRapMe

RepRapMe commented Feb 9, 2016

Using Slic3r 1.2.9 when slicing files consisting of more than 10 extruders (Repetier-Firmware supports up to 16 virtual extruders for color mixing) via Repetier-Host then Slic3r sorts the toolpath as follows: 0, 1, 10, 12, 13, 14, 15, 2, 3, 4, 5, 6, 7, 8, 9 (and then in the next layer it's taking a shortcut to 9, 0, 1, 10, 11, 12, 13, 14, 15, 2, 3, 4, 5, 6, 7, 8)

The order should of course be 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15

Note this was not an issue with Slic3r 1.1.7

For comparison I have attached the gcode output from both version 1.1.7 and 1.2.9

Extruder order messup 1.1.7.gcode.txt
Extruder order messup 1.2.9.gcode.txt

@Virtox

This comment has been minimized.

Virtox commented Feb 20, 2016

Will try to test it later, but looks like it's using the default lexical sort.
If you run the perl version, change line 542 of lib/Slic3r/Print/Gcode.pm
my @extruders = sort keys %by_extruder;
to
my @extruders = sort {$a <=> $b} keys %by_extruder;

And to skip the toolchange shortcut , comment out lines 543 - 551:
# if (@extruders > 1) {
# my $last_extruder_id = $self->_gcodegen->writer->extruder->id;
# if (exists $by_extruder{$last_extruder_id}) {
# @extruders = (
# $last_extruder_id,
# grep $_ != $last_extruder_id, @extruders,
# );
# }
# }

@lordofhyphens

This comment has been minimized.

Member

lordofhyphens commented Mar 13, 2016

@RepRapMe Could you provide a config file and an STL/AMF so we can easily test this?

alranel added a commit that referenced this issue Mar 14, 2017

@alranel

This comment has been minimized.

Member

alranel commented Mar 14, 2017

@RepRapMe, thank you, I fixed this. The shortcut is actually there by design and it's a feature: it will save a toolchange. Can you share your use case and why the shortcut is unwanted?

@alranel alranel removed this from the 1.3.0 milestone Mar 14, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment