Skip to content
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
Open

Slic3r messing up on extruder order #3235

RepRapMe opened this issue Feb 9, 2016 · 3 comments
Labels

Comments

@RepRapMe
Copy link

@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
Copy link

@Virtox 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
Copy link
Member

@lordofhyphens 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
Copy link
Member

@alranel 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
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants